Re: Proposal unify back our release schedules

[David Edmundson]

> As a result I'll rescind my idea to slow down Frameworks feature
> releases.

Then I'll take over and fight for it!

>that having a fast Frameworks release cycle allows
> people developing apps with features in Frameworks to not have to live
> on master like we do in Plasma.

That was the motivation for the change. And it's simply a bad motivation.

The most important stakeholder of our release cycle is not app
developers. It's the end-user.

We've seen this in practice over the last 10 years that the user
experience suffers with the short release cycle. Less than a month is
not enough for any meaningful testing, especially for API that we
commit to for years and years.  We've seen last minute respins and
panics on so many 5.x releases.That trumps any other developer-centric
argument by far as the most important thing for developers is their
apps to work well with the libraries they use.

I am 100% certain we would have better products with a different
branch policy on frameworks than the current optimistic policy of
master always being perfect and not having bugfix releases.

How branch policy changes how we do releases still has many many
options, but I would like to see something change and this proposal
does fix that.

David

Re: Proposal unify back our release schedules

[David Edmundson]

>> in that event I'd like for us to put it
>> to a formal KDE e.V. vote


> Is this an eV topic?

Yes and no.

The original decision had a big impact, changing things again will
have a big impact. It's not something that should be decided by a few
people, nor is it something that should be decided or squashed by a
"who can talk for longest" on a mailing list.

Should it be discussed behind closed doors on the eV mailing list? No.
Is an eV vote the only way to get something that's fair and
representative and reach a binary conclusion? I can't think of
anything better

I think it's a resource we should use more often.

David

Re: APIs for persistent remote access and headless/hybrid sessions

[David Edmundson]

Hello,

Thanks for reaching out and keeping us in the loop. It's better now
than after something has been implemented.

We are definitely interested in working in this area. We have a lot of
the proposed core infrastructure that's listed in that proposed
specification; pipewire, creation of virtual screens, libei access is
coming soon. It's "just" a case of gluing everything together.

The current portal API is expanding with a concept of tokens to allow
creation of streams without user prompts and access. I was hoping this
would suffice if it was coupled with some mechanism to get these
tokens ahead of time?

Does Chrome Remote Desktop provide the server part that runs on the
client computer? Or is it using some network API to connect to talk to
the existing gnome/kde remote-desktop server?

David

Re: revisiting the sycoca

[David Edmundson]

> All in all I am not convinced we still need the sycoca

As you noted it's 3 different things. I suggest we tackle it as 3
different tasks.
The mime apps part we should be able to drop silently without any issue.

The menu and desktop files are still needed by krunner and plasmashell
and xdg-desktop-portal.
I don't think an external cache is problematic here, it works. It
could be done differently, but we're just moving the problem about and
I don't think there's any immediate savings here.

What we should be looking at as a first step is splitting "what
applications need" from "what do system services need" and making sure
these are separate and covering the right things.
Apps seem to mostly use serviceByDesktopName that doesn't need to be
backed by a cache, at worst we have to stat 4 or 5 folders.  I propose
we replace that with a lighter desktop file wrapper higher up in the
stack (Kconfig?)  and port those instances in apps.  Or maybe it
should be backed by some relevant portal call.

David

Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion

[David Edmundson]

On Mon, Sep 18, 2023 at 5:45 AM Neal Gompa  wrote:
me of them, I've got ideas, others less so.
>
> The first thing that came up was that KiCad seems to need help and has
> had a bad experience interfacing with some folks over resolving their
> issues moving into a Wayland world.

Given I'm quoted, I said we shouldn't rush clients to not be on Xwayland.
These are just Kicad's known issues, it'll be longer to fix all the
issues that come up after they're ported.
That's what Xwayland is for, and we've put a lot of effort into it.

David

Frameworks / Plasma/ Gear Release Schedule Plan

[David Edmundson]

Following on from the last Akademy we checked where we were with our
development progress in a meeting and settled on the following plan
for all 3 major parts:

 - In KDE Gear master will be open for Qt6 code to land for those
ready to move. Not all apps need to port.

 - The KDE Gear release will move by 2 months to allow for the extra
time needed for testing initial Qt6 changes

 - An Alpha will be made in November  (a soft freeze in Plasma terms)

 - Betas/RCs will be made throughout December and January (3 releases,
3 weeks apart)

 - Final release of all 3 major parts in sync in February

Due to the delay of KDE Gear by an additional patch release of 23.08
will be made.

David Edmundson

Frameworks / Plasma/ Gear Release Schedule Plan

[David Edmundson]

Following on from the last Akademy we checked where we were with our
development progress in a meeting and settled on the following plan
for all 3 major parts:

 - In KDE Gear master will be open for Qt6 code to land for those
ready to move. Not all apps need to port.

 - The KDE Gear release will move by 2 months to allow for the extra
time needed for testing initial Qt6 changes

 - An Alpha will be made in November  (a soft freeze in Plasma terms)

 - Betas/RCs will be made throughout December and January (3 releases,
3 weeks apart)

 - Final release of all 3 major parts in sync in February

Due to the delay of KDE Gear by an additional patch release of 23.08
will be made.

David Edmundson

Re: Planning the final 6 release timeframes

[David Edmundson]

As a reminder this meeting is tonight in 3 hours.

David

Re: Planning the final 6 release timeframes

[David Edmundson]

As a reminder this meeting is tonight in 3 hours.

David

Re: Planning the final 6 release timeframes

[David Edmundson]

Video call at https://meet.kde.org/b/ada-mi8-aem

Re: Planning the final 6 release timeframes

[David Edmundson]

Video call at https://meet.kde.org/b/ada-mi8-aem

Re: Planning the final 6 release timeframes

[David Edmundson]

A time has been chosen on the poll with a clear winner:
4th September 18:00 CEST

See you all there

David Edmundson

Re: Planning the final 6 release timeframes

[David Edmundson]

A time has been chosen on the poll with a clear winner:
4th September 18:00 CEST

See you all there

David Edmundson

Planning the final 6 release timeframes

[David Edmundson]

As discussed at Akademy we need to finalize the release of KF6 /
Applications with 6 and Plasma 6.

Applications can't release without Plasma (for Breeze + Plasma Integration)
Plasma is weakened without kio-extras
Both depend on Frameworks which needs a final release.

We want to be fairly synced which means a release together. Multiple
alternative options to releasing in sync are possible, but general
consensus at Akademy was that it made things more complex. Plasma was
targeting to be ready "at end of the year", but that doesn't quite
line up with having betas in November.

We need to come up with a plan that works for KDE Gear application
authors, Plasma team and Frameworks dev.

A doodle poll is available at: https://nuudel.digitalcourage.de/qqpRbUMFIQdLP1ZP

At the end of the meeting there must be a decision made. If there's no
consensus we'll have to have a vote with multiple rounds of
elimination.

Open discussion ahead of time is available at:
https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/55

David Edmundson

Planning the final 6 release timeframes

[David Edmundson]

As discussed at Akademy we need to finalize the release of KF6 /
Applications with 6 and Plasma 6.

Applications can't release without Plasma (for Breeze + Plasma Integration)
Plasma is weakened without kio-extras
Both depend on Frameworks which needs a final release.

We want to be fairly synced which means a release together. Multiple
alternative options to releasing in sync are possible, but general
consensus at Akademy was that it made things more complex. Plasma was
targeting to be ready "at end of the year", but that doesn't quite
line up with having betas in November.

We need to come up with a plan that works for KDE Gear application
authors, Plasma team and Frameworks dev.

A doodle poll is available at: https://nuudel.digitalcourage.de/qqpRbUMFIQdLP1ZP

At the end of the meeting there must be a decision made. If there's no
consensus we'll have to have a vote with multiple rounds of
elimination.

Open discussion ahead of time is available at:
https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/55

David Edmundson

Re: Porting aid place for Plasma stuff?

[David Edmundson]

For kwayland I would suggest to keep it in it's own repo kept being
called kwayland

Dialog is in Plasma-framework which is moving to workspace anyway. I'm
not sure of the status of that move is.

I would put suggest putting D stuff in plasma-framework (or whatever
it ends up being called)

Re: Minutes from the porting BOF

[David Edmundson]

Updates on this topic after the plasma BOF.

There's some concerns (by me mostly) about Plasma being committed to a
rigid schedule. As such the following was somewhat agreed upon.

We can probably delay the .12 release of KDE Gear if it's needed. The
Qt 6 transition is a special case.
If we want to delay more than 2 months, then we may as well just wait for 24.04.

At the start of September, we'll do a big online meeting with all
stakeholders and make an executive decision.

David

Minutes from the porting BOF

[David Edmundson]

They're in a short format, ping if there's any questions.

# Timelines

KDE Gear 0.8 will be Qt5 ONLY
KDE Gear .12 should be Qt5 and Qt6

Will REQUIRE plasma to be out (for themes and stuff).
Plasma timing discussion is tomorrow, so that maybe throws things out.

Apps should keep master as Qt5 and develop in a branch. Only make
master Qt6 only when it's clear things are on target.

This would mean a KF6 release in November.

We should do betas and RCs working backwards. That put things very soon :/

We do not expect to keep dual-building libs and apps forever! As soon
as they switch to master, go to them.

If you do dual build, don't use QT_VERSIONLESS_TARGETS, instead use
QT_MAJOR_VERSION everywhere.

# Blockers

No Qt blockers!
We do depend on Qt5Compat but that's fine.

# Flatpak

We will get 2 flatpak runtimes, one for 6. We have a Qt6 runtime
already, just without KF6.

We could benefit from a beta runtime with nightlies /weeklies.

# Thumbnailers

We need Qt5 apps to read Qt6 thumbnailers, and vice-versa.

General consensus is "lets port quickly and get things out all at once".

But maybe it's an opportunity to fix more universally. BOF on Thursday

# Specific issues:

## QML and ifdefs

It's been an issue
There won't be an ifdef in QML in future
/maybe/ a constexpr logic might be allowed, but we need to think about tooling.

## QPaletes

We can't access propreties for colours. The C++ implementation returns
a brush not a colour.

Changing QtBase so it has properties which return a colour would be horrible.

Having a setter on controls which accepts a variant might be a land-able option.

## Shader tools:

Action item: Arjen had some issues, to file bugs with the relevant Qt person.

Re: sentry evaluation

[David Edmundson]

>Did you like it?

When we had an initial influx of reports after you first blogged it
was amazing. We were getting reports in places I hadn't seen before on
bugzilla.
It did a really good job of implicitly showing which things were the
most relevant needing fixing, and what's just noise we can just
ignore, and whether a crash has just gone away on it's own.

Now it's dead, but that's a chicken and egg situation.

>What could be improved?

I'm not sure the teams and groups really work out right now. Do we
need to request access to groups and have that approved? I don't want
people to have an excuse to not fix crashes!
There was also a minor issue that a plasma bug might have a frameworks
or Qt fix, but I couldn't reliably say "fixed in next version", it's
not a case which sentry had a good infra for. (bugzilla also isn't
amazing at that)

>Should we move ahead with a more permanent setup?

100% has my vote. Can we do things on a per-project basis? We can
surface things in the Plasma UI right now, and there's still a while
before release to pivot if needed.

David

Re: kf6 deconflictor progress

[David Edmundson]

On Fri, Apr 28, 2023 at 5:59 PM Jonathan Riddell  wrote:
>
> The deconflictor job we run in neon still has a bunch of files overlapping 
> between kf5 and kf6
>
> https://build.neon.kde.org/job/test_kf6_deconflictor/
>
> https://build.neon.kde.org/job/test_kf6_deconflictor/9/artifact/conflict-report.json/*view*/
>
> Is there any progress being made in fixing this?

Any, yes.
Obviously it's not done yet.

I'm not sure this report is up to date:

"/usr/kf6/bin/kglobalaccel5",
"/usr/bin/kglobalaccel5"

I can't see us installing that.

> We'd like to move the neon packages into /usr which would break our 
> deconflicting report job.

You know how to make progress faster :)

> Jonathan
>

Re: kitemmodels kf6 build failure

[David Edmundson]

Please ensure you are building with
-DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.91.0

KF5 branches

[David Edmundson]

There is now a "kf5" branch in all frameworks repos as discussed last
frameworks meeting.

Starting now any commits that are also wanted in the next KF5 should
be cherry-picked after landing.

This does *not* mean master is fully open for going into KF6 dev mode.
Now the kf5 branches exist, we'll set up tooling and infrastructure
and make sure that is all stable. Only after that is all sorted should
master start getting any Qt6-exclusive dev work and version bumps.

Regards

David

Re: How long with the kde-qt5.15 repo be kept updated?

[David Edmundson]

I can't see our KDE patch collection going away whilst we still have
Qt5 apps shipping.
We have patches that Qt haven't backported that we deemed important
and it'd be more work to get distros to swap back again. It doesn't
cost anything to keep it there.

It will probably get fewer and fewer backports until it's just
security fixes, but that's not necessarily a bad thing.

David

Re: Copying po/docbook files to repositories nightly

[David Edmundson]

>Opinions? Comments?

So our releases will end up a 1:1 with a git tag? That would be
super-duper amazing for many cleanup things, including the security
aspect  +1

What's the plan for stable branches?
We'll either need to port all active stable branches at the same time
or we will have to make sure releaseme either has multiple branches or
a runtime toggle.

>My plan would be to enable this scripts over Akademy

FYI:
Plasma beta is tagged Thu 2022-09-22
Plasma 5.26 is tagged Thu 2022-10-06

Akademy is in the middle of those.
I don't see how there can be too much fall-out so it's probably fine,
but if we are expecting lots of fixes to be needed that's not the best
timing from our side.

David

Plasma 6 Planning sprint starts tomorrow!

[David Edmundson]

I'm sure everyone is excited:

Full schedule and joining instructions available at:
https://invent.kde.org/plasma/plasma-workspace/-/issues/32

Looking forward to seeing your all

David

Re: KQuickChatComponents in kdereview

[David Edmundson]

# Overall:
How is LTR meant to work? You're using it for internal layouting
purposes so any genuine LTR would now be quite broken, I suspect it
will all appear aligned to one side. At a minimum we would need to
inverse the logic inside ChatBubble::tailBase and it needs some
testing

# ChatBubble:

property alias inlineFooterContent: _row.data
property alias inlineFooter: _row

Either one makes sense, but I'm not sold on having both. What if
someone set inlineFooter to a null? then used inlineFooterContent

---
Why do we have Kirigami.ShadowedRectangle if the whole thing is in a
DropShadow effect?

# TextBubble:
readonly property string textPadding: "
".repeat(Math.ceil(bubble.bubble.inlineFooter.width /
dummy.implicitWidth)) + "⠀"

textPadding will affect implicitWidth, basing an implicitWidth off any
current widths is a path to binding loops. using
bubble.bubble.inlineFooter.implicitWidth would be ok.

# Timestamp:
There's some maths on the sizes, do they need rounding?

Re: KQuickChatComponents in kdereview

[David Edmundson]

All of 
https://invent.kde.org/libraries/kquickchatcomponents/-/blob/master/src/controls/
appear to be missing API docs

David

Re: Developer setups for user D-Bus service files?

[David Edmundson]

> This triggered yet another idea with me, and I came across
> https://www.freedesktop.org/software/systemd/man/environment.d.html
> upon which I tried to add a file
> /home/mydevuser/.config/environment.d/60-test.conf
> with the content
> --- 8< ---
> XDG_DATA_DIRS=/home/mydevuser/my/share::${XDG_DATA_DIRS:-/usr/local/share/:/
> usr/share/}
> --- 8< ---
> logged into a new session et voilà, the session D-Bus now sees my D-Bus
> service files and starts the services as expected.
>

The equivalent for non-systemd people is to setup `pam_env` with user
env turned on to do the same thing at roughly the same time.
The drawback is you're always affecting that user, it's not on a per
login basis, which works for you, but not everyone.

David

Re: Developer setups for user D-Bus service files?

[David Edmundson]

>at least with systemd controlled start (but possibly also before

Since forever.

>So, what standard approach should we take as developers here?

Personally I would say developers should avoid having a system
installed KDE, you're only making life harder for yourself.
Then things are relatively easy. You still have to do some editing of
/etc/ but only once and you have no confusions.



But I appreciate that's not a good solution for everyone. So to
brainstorm some options.

For systemd services I couldn't find a good solution so on a dev
session on startup they copy all relevant files to
$XDG_RUNTIME_DIR/whatever then reload everything.
This is copied from gnome (I think they then run a nested systemd
--user maybe dbus too?)

https://invent.kde.org/plasma/plasma-workspace/-/blob/master/login-sessions/startplasma-dev.sh.cmake



I did start another idea.

If you populate the dev session environment variables *really* early
must we even go through pam you can set your XDG_DATA_DIRS before DBus
daemon has loaded it will then have the right stuff.
I made a patch doing that: https://github.com/sddm/sddm/pull/1370
which is merged but not released:


It's not perfect, you still have the issue of polkit/system dbus. It
also has a scope of lasting for the duration that the user is logged
in, not the duration you're in Plasma; but probably fixes 90% of
cases.

David

Re: QML API docs for C++ wrapper types?

[David Edmundson]

We have examples of where we have done this. Though I wouldn't
necessarily use the word "properly".

In Plasma-framework we have a manually made list where we can write
the plugin name and list items by their exported QML type name.

https://invent.kde.org/frameworks/plasma-framework/-/blob/master/src/declarativeimports/core/Mainpage.dox

Which appears as:
https://api.kde.org/frameworks/plasma-framework/html/core.html

That links to the classic C++ generated docs, and we rely on users to
know to only look at properties and signals.

Re: Gitlab CI - Inbound

[David Edmundson]

Excellent news!! Thanks very much

> Once the scripts have been proven successfully for Frameworks, we will look 
> at extending them to projects that depend only on Frameworks and repositories

Does this mean we would like Plasma to wait a while before merging?
Is it worth us creating the kde-cli files and not merging them so we
have some test cases ready?

David

Re: Gitlab CI - Inbound

[David Edmundson]

Excellent news!! Thanks very much

> Once the scripts have been proven successfully for Frameworks, we will look 
> at extending them to projects that depend only on Frameworks and repositories

Does this mean we would like Plasma to wait a while before merging?
Is it worth us creating the kde-cli files and not merging them so we
have some test cases ready?

David

Re: Gitlab CI - Inbound

[David Edmundson]

Excellent news!! Thanks very much

> Once the scripts have been proven successfully for Frameworks, we will look 
> at extending them to projects that depend only on Frameworks and repositories

Does this mean we would like Plasma to wait a while before merging?
Is it worth us creating the kde-cli files and not merging them so we
have some test cases ready?

David

Re: [kdiff3] [Bug 436826] kdiff3 has no window, wayland, gnome

[David Edmundson]

>I assume that is related to this:
>https://gitlab.gnome.org/GNOME/mutter/-/issues/217

Not really.
There are code paths upstream in QtWayland to support this case.

> I am terminating support for gnome/wayland unless and until gnome

Lets not just be dramatic.

There is a bug, it not necessarily in your product, but lets get the
right info and then forward it to the right people.
I'll take over on the bug report.

David

Re: Moving plasma-frameworks & krunner to Plasma release set for *6? (was: Re: KF6 meeting notes 2021-04-17)

[David Edmundson]

> It seems these days the only real user of plasma-frameworks & krunner
> libraries is the Plasma shell itself, with other applications only providing
> plugins/extensions and only targeting Plasma again.

That is mostly in line with other discussions in plasma. There is a
ticket splitting plasma-framework and all of the applet stuff we hope
to move to workspace - with some parts having other homes elsewhere.

KRunner we haven't discussed in as much detail.

Re: KF6 online sprint: March 27-28

[David Edmundson]

I wanted to bump this thread, just so people remember that it is this weekend!
There are many many slots still available.

David

Re: KF6 online sprint: March 27-28

[David Edmundson]

I wanted to bump this thread, just so people remember that it is this weekend!
There are many many slots still available.

David

Re: KCGroups in KDEreview

[David Edmundson]

> > (where 1000 is of course dynamic)
>
> Ditto, what enum names could we give to those?

/ -> All
/system.slice -> System
user.slice/user-1000.slice/user@1000.service -> User
user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps
user.slice/user-1000.slice/user@1000.service/session.slice -> UserSession
user.slice/user-1000.slice/user@1000.service/background.slice -> UserBackground


> Yes, I know I roll with questions. :-)

> Cheers.
> --
> Kevin Ottens, http://ervin.ipsquad.net

Re: KCGroups in KDEreview

[David Edmundson]

> > (where 1000 is of course dynamic)
>
> Ditto, what enum names could we give to those?

/ -> All
/system.slice -> System
user.slice/user-1000.slice/user@1000.service -> User
user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps
user.slice/user-1000.slice/user@1000.service/session.slice -> UserSession
user.slice/user-1000.slice/user@1000.service/background.slice -> UserBackground


> Yes, I know I roll with questions. :-)

> Cheers.
> --
> Kevin Ottens, http://ervin.ipsquad.net

Re: Plasma Firewall on KDE Review

[David Edmundson]

>Doesn't look like translations would work, at least the C++ part, not sure 
>about the QML one.

You were right at the time of writing.
I have tested that now both the C++ and QML side have correct
translations loaded with x-test.

David

Re: Plasma Framework and Kirigami unittests

[David Edmundson]

One down:
https://invent.kde.org/frameworks/kirigami/-/merge_requests/200

Re: T13975: Move hanyoung/libkweather to frameworks/kweathercore

[David Edmundson]

On Sun, 20 Dec 2020, 11:48 Friedrich W. H. Kossebau, 
wrote:

> (Added Han Young as BCC: based on code email address, as the task is not
> public, and not sure you are subscribed to the mailinglists)
>
> Am Sonntag, 20. Dezember 2020, 12:05:46 CET schrieb David Edmundson:
> > Please see https://community.kde.org/Policies/Application_Lifecycle
> about
> > the process of adding things to frameworks.
> >
> > As for plasma, we have a weather library there, so the comment about it
> > being easier for new plasmoids doesn't hold directly. Maybe you can
> expand
> > on what's different?
>
> David, any chance you misremembered there being a weather library? If you
> refer to the stuff in plasma-workspace (which then e.g. drives the kde-
> plasmaaddons weather applet), that is just a DataEngine.
>

That is what I was referring to, yes.
It may be "just" a dataengine, but the end-result of plasmoids/apps being
able to get weather data is the same.

I also have no qualms about replacing it for the same reasons you outlined
(except maybe that this has a very hardcoded single backend), but we want
to make sure we don't end up with two things.

David

Re: T13975: Move hanyoung/libkweather to frameworks/kweathercore

[David Edmundson]

Please see https://community.kde.org/Policies/Application_Lifecycle about
the process of adding things to frameworks.

As for plasma, we have a weather library there, so the comment about it
being easier for new plasmoids doesn't hold directly. Maybe you can expand
on what's different?

David

Re: KCGroups in KDEreview

[David Edmundson]

On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens  wrote:
>
> Hello,
>
> On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote:
> > Ultimately this isn't really dealing with cgroups directly but with
> > the manager to control them, systemd.
> >
> > That's correct usage, kernel docs of cgroups say to go via a
> > controller for write operations. However that at point is it worth
> > naming the library ksystemd?
> > It might cause some contention due to people who get angsty at a name,
> > but it's a lot more fitting. It would then give us a place to dump a
> > lot of other wrappers (especially logind) that we're seeing duplicated
> > in a bunch of places throughout KDE.
>
> Aren't you concerned this might lead to one of our infamous dumping grounds?
>
> There's always a tension between making it too focused and tiny or unfocused
> and with blackhole mass... we'd need to find where it stands but "systemd
> wrappers" looks too loosely defined to me.
>

> Do we have a list of the wrappers you got in mind and which piece of feature
> they all provide?

StartUnit, given this has a StopUnit
Used by plasma-workspace and plasma-firewall

Logind I have wrappers in:
 - kwin
 - libkworkspace
 - SDDM
 - powerdevil
 - kscreenlocker

None wrapping all of it, only what they need, but there's still overlap.
You're right that could be a separate framework if that's preferred.

>
> > I think we've artificially limited the usage of the library.
> > The code is very generic for handling units, but all the names and one
> > tiny line limit it to only managing a subset of units.
> >
> > If we make the "glob" static used in KApplicationScopeLister's have a
> > public setter (or a protected virtual) we can rename this class and it
> > becomes a much more generic library for others to use outside of any
> > initial use-case.
>
> Good point. Got a similar question though, which other unit types would be
> useful to control? Reason being that API wise I'd smell an enum for something
> like this.

Enum potentially works too.

Describing things in terms of cgroup hierarchy, I think the key use cases are:

/
user.slice/user-1000.slice/user@1000.service
user.slice/user-1000.slice/user@1000.service/app.slice
user.slice/user-1000.slice/user@1000.service/session.slice
user.slice/user-1000.slice/user@1000.service/background.slice
(where 1000 is of course dynamic)

Re: KCGroups in KDEreview

[David Edmundson]

On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens  wrote:
>
> Hello,
>
> On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote:
> > Ultimately this isn't really dealing with cgroups directly but with
> > the manager to control them, systemd.
> >
> > That's correct usage, kernel docs of cgroups say to go via a
> > controller for write operations. However that at point is it worth
> > naming the library ksystemd?
> > It might cause some contention due to people who get angsty at a name,
> > but it's a lot more fitting. It would then give us a place to dump a
> > lot of other wrappers (especially logind) that we're seeing duplicated
> > in a bunch of places throughout KDE.
>
> Aren't you concerned this might lead to one of our infamous dumping grounds?
>
> There's always a tension between making it too focused and tiny or unfocused
> and with blackhole mass... we'd need to find where it stands but "systemd
> wrappers" looks too loosely defined to me.
>

> Do we have a list of the wrappers you got in mind and which piece of feature
> they all provide?

StartUnit, given this has a StopUnit
Used by plasma-workspace and plasma-firewall

Logind I have wrappers in:
 - kwin
 - libkworkspace
 - SDDM
 - powerdevil
 - kscreenlocker

None wrapping all of it, only what they need, but there's still overlap.
You're right that could be a separate framework if that's preferred.

>
> > I think we've artificially limited the usage of the library.
> > The code is very generic for handling units, but all the names and one
> > tiny line limit it to only managing a subset of units.
> >
> > If we make the "glob" static used in KApplicationScopeLister's have a
> > public setter (or a protected virtual) we can rename this class and it
> > becomes a much more generic library for others to use outside of any
> > initial use-case.
>
> Good point. Got a similar question though, which other unit types would be
> useful to control? Reason being that API wise I'd smell an enum for something
> like this.

Enum potentially works too.

Describing things in terms of cgroup hierarchy, I think the key use cases are:

/
user.slice/user-1000.slice/user@1000.service
user.slice/user-1000.slice/user@1000.service/app.slice
user.slice/user-1000.slice/user@1000.service/session.slice
user.slice/user-1000.slice/user@1000.service/background.slice
(where 1000 is of course dynamic)

Re: KCGroups in KDEreview

[David Edmundson]

Ultimately this isn't really dealing with cgroups directly but with
the manager to control them, systemd.

That's correct usage, kernel docs of cgroups say to go via a
controller for write operations. However that at point is it worth
naming the library ksystemd?
It might cause some contention due to people who get angsty at a name,
but it's a lot more fitting. It would then give us a place to dump a
lot of other wrappers (especially logind) that we're seeing duplicated
in a bunch of places throughout KDE.

---

I think we've artificially limited the usage of the library.
The code is very generic for handling units, but all the names and one
tiny line limit it to only managing a subset of units.

If we make the "glob" static used in KApplicationScopeLister's have a
public setter (or a protected virtual) we can rename this class and it
becomes a much more generic library for others to use outside of any
initial use-case.

David

Re: KCGroups in KDEreview

[David Edmundson]

Ultimately this isn't really dealing with cgroups directly but with
the manager to control them, systemd.

That's correct usage, kernel docs of cgroups say to go via a
controller for write operations. However that at point is it worth
naming the library ksystemd?
It might cause some contention due to people who get angsty at a name,
but it's a lot more fitting. It would then give us a place to dump a
lot of other wrappers (especially logind) that we're seeing duplicated
in a bunch of places throughout KDE.

---

I think we've artificially limited the usage of the library.
The code is very generic for handling units, but all the names and one
tiny line limit it to only managing a subset of units.

If we make the "glob" static used in KApplicationScopeLister's have a
public setter (or a protected virtual) we can rename this class and it
becomes a much more generic library for others to use outside of any
initial use-case.

David

Re: Synchronized release schedule for Plasma

[David Edmundson]

>
> As distribution package maintainers, we would like Plasma developers to
> slightly alter the release schedule to align releases with a more
> distribution friendly cycle. You could consider shortening one release
> cycle (and then keep the 6 month schedule) to align releases.
>

We have in the past shuffled things slightly to line up things up with
distros on request, particularly LTS releases. We can certainly explore
that on a one-off basis.

>With this schedule in place, we would also benefit from more beta releases
over a slightly longer period. They would be packaged into the beta and RC
releases of those distributions thus enabling more pre-release testing.

We did have 6 month release cycles in the past.

The rationale for moving at the time was twofold:
 - people rushed in changes towards the feature freeze as otherwise it
would be aages till their changes reached users
 - the more changes we have in a release, the more testing and inevitable
regression fixes we need to do, spreading that out should result in things
being more stable

Initially we did every 3 months (which arguably still aligns) then it
slowly slipped to 4.

My personal impression is that releases have gotten better as a result of
those changes, so I'm hesitant about reverting that decision.

David


>

Re: Telemetry information in Plasma

[David Edmundson]

>
> It does indeed appear to always be null.

Just to clarify, as this email was intended as a privacy review.
That's a bug that will fail safe with less collected.

Everything looks safe.

David

Re: Telemetry information in Plasma

[David Edmundson]

On Tue, Nov 10, 2020 at 3:21 AM Nicolás Alvarez
 wrote:
>
> El lun., 9 de nov. de 2020 a la(s) 13:32, Aleix Pol (aleix...@kde.org) 
> escribió:
> > - BasicUsageStatistics
> > Usage time
> > Launches count (Discover)
>
> Is "launches count" reset to 0 after each telemetry submission, or is
> it cumulative / lifetime launch count?
>
> > - DetailedUsageStatistics
> > Panel Count (Plasma shell)
> > Application Source Name (Discover)
>
> What is Application Source Name? Is this actually implemented? The
> database seems to have pure NULLs but I may be looking in the wrong
> place.

It does indeed appear to always be null.

I think there's a mismatch in the schema.
Code has a scalar "applicationSourceName" with an entry "value"
Active Schema has a scalar "applicationSource" with an entry
"applicationSourceName"

The schema shipped in discover looks correct.

David

Re: RSIBreak / KIdleTime on Wayland

[David Edmundson]

change made:
https://invent.kde.org/plasma/kwayland-server/-/merge_requests/133

Re: RSIBreak / KIdleTime on Wayland

[David Edmundson]

change made:
https://invent.kde.org/plasma/kwayland-server/-/merge_requests/133

Re: RSIBreak / KIdleTime on Wayland

[David Edmundson]

>If the user was idle for a second (using a KIdleTime timeout), I start my own 
>idle time counter (counter++ every second).
>Then I catch the next resume event (next user input) and reset my counter to 0.

That sounds like what I had in mind.

> 2) It works with XWayland, but only detects user activity if the user makes 
> an input to an XWayland window.

Yeah, that's expected. We only send things to X when an X app has focus.
Changing this behaviour is not an option. I don't think this is a
viable setup option to support.

>RSIBreak is started as an XWayland application by default.
That shouldn't be the case. Are you on OpenSuse by any chance?

>
> 3) It works okay if RSIBreak is started as a native Wayland application 
> (QT_QPA_PLATFORM=wayland).
>All input is detected, on native and XWayland windows.
>But: It takes about 5-10 seconds of me not doing any inputs for the idle 
> timeout to be called, instead of the 1 second timeout I requested.
>(the resume event is emitted immediately though, it is just the idle 
> timout that is slow)

Indeed:

// less than 5 sec is not idle by definition
timer->setInterval(qMax(timeout, 5000u));

In kwayland-server/src/server/idle_interface.cpp
I have no objections to changing this.

David

>
> So I wonder if this can be fixed in KIdleTime, or if that's just how Wayland 
> works.
> Thank you,
> Dominik

Re: RSIBreak / KIdleTime on Wayland

[David Edmundson]

>If the user was idle for a second (using a KIdleTime timeout), I start my own 
>idle time counter (counter++ every second).
>Then I catch the next resume event (next user input) and reset my counter to 0.

That sounds like what I had in mind.

> 2) It works with XWayland, but only detects user activity if the user makes 
> an input to an XWayland window.

Yeah, that's expected. We only send things to X when an X app has focus.
Changing this behaviour is not an option. I don't think this is a
viable setup option to support.

>RSIBreak is started as an XWayland application by default.
That shouldn't be the case. Are you on OpenSuse by any chance?

>
> 3) It works okay if RSIBreak is started as a native Wayland application 
> (QT_QPA_PLATFORM=wayland).
>All input is detected, on native and XWayland windows.
>But: It takes about 5-10 seconds of me not doing any inputs for the idle 
> timeout to be called, instead of the 1 second timeout I requested.
>(the resume event is emitted immediately though, it is just the idle 
> timout that is slow)

Indeed:

// less than 5 sec is not idle by definition
timer->setInterval(qMax(timeout, 5000u));

In kwayland-server/src/server/idle_interface.cpp
I have no objections to changing this.

David

>
> So I wonder if this can be fixed in KIdleTime, or if that's just how Wayland 
> works.
> Thank you,
> Dominik

Re: RSIBreak / KIdleTime on Wayland

[David Edmundson]

>
> Yes, I meant that progress bar.
> I've had that 1s idle timer idea as well, unfortunately after writing this, 
> but thank you for confirming that this would indeed work.
> I will give that a try and if I can get RSIBreak to a working state on 
> wayland submit a PR for it.

Excellent, thank you very much.
Please do please reach out if there are any questions with regards to
the wayland side.

David

Re: RSIBreak / KIdleTime on Wayland

[David Edmundson]

>
> Yes, I meant that progress bar.
> I've had that 1s idle timer idea as well, unfortunately after writing this, 
> but thank you for confirming that this would indeed work.
> I will give that a try and if I can get RSIBreak to a working state on 
> wayland submit a PR for it.

Excellent, thank you very much.
Please do please reach out if there are any questions with regards to
the wayland side.

David

Re: RSIBreak / KIdleTime on Wayland

[David Edmundson]

> I agree, if we can't make the KIdleTime framework work in Wayland there 
> should be a way to query the framework if it's going to work or not.

Just to make sure that's not misread by others; the framework works
for the majority of methods used in the common case, just not this one
polling method.

> > So do you think it makes sense to have the function return some form or 
> > error instead of just returning 0, or is there a good reason it is not 
> > doing that already?

I don't think it helps with a lot, you need to change clients to
handle the error, at which point we've not really solved a lot. If
you're going to use the addIdleTimeout API you may as well do it
everywhere. It is considerably lighter on X11 too.

Like Albert suggested, a capabilities flag could make sense.
At a super bare minimum the documentation needs updating. At the other
extreme we could even deprecate it.

If after trying to port rsibreak to use the event driven API and it
turns out there really is a use case for a polling API, we do still
have the option to start a discussion about extending the relevant
wayland protocol to have such a query mechanism.



>RSIBreak is unable to count down in wayland, after 1 second it always resets 
>its timer.

Just to make sure we're talking about the same thing: Is it when you
have a shortbreak set after N minutes and you get a "please relax for
20seconds" with a progress bar?

If so, simplest option is to start a 1s idletime timer. We don't need
to know how long we've been idle via polling, just if/when we're
interrupted during the 20s countdown.

David

Re: RSIBreak / KIdleTime on Wayland

[David Edmundson]

> I agree, if we can't make the KIdleTime framework work in Wayland there 
> should be a way to query the framework if it's going to work or not.

Just to make sure that's not misread by others; the framework works
for the majority of methods used in the common case, just not this one
polling method.

> > So do you think it makes sense to have the function return some form or 
> > error instead of just returning 0, or is there a good reason it is not 
> > doing that already?

I don't think it helps with a lot, you need to change clients to
handle the error, at which point we've not really solved a lot. If
you're going to use the addIdleTimeout API you may as well do it
everywhere. It is considerably lighter on X11 too.

Like Albert suggested, a capabilities flag could make sense.
At a super bare minimum the documentation needs updating. At the other
extreme we could even deprecate it.

If after trying to port rsibreak to use the event driven API and it
turns out there really is a use case for a polling API, we do still
have the option to start a discussion about extending the relevant
wayland protocol to have such a query mechanism.



>RSIBreak is unable to count down in wayland, after 1 second it always resets 
>its timer.

Just to make sure we're talking about the same thing: Is it when you
have a shortbreak set after N minutes and you get a "please relax for
20seconds" with a progress bar?

If so, simplest option is to start a 1s idletime timer. We don't need
to know how long we've been idle via polling, just if/when we're
interrupted during the 20s countdown.

David

Re: Proposal: make squash-merging the default behavior for gitlab MRs

[David Edmundson]

>
> your_merge_request_commit_history
> 
> .
>
> However, it remains a fairly advanced workflow which is challenging for
> newcomers, drive-by-developers, and people not as familiar with git. For
> these people, squash-merging makes much more sense, and when they forget
> to check that checkbox and someone merges their work, the result is tons
> of garbage commits in the git history.
>

I do agree that state is a problem. Because we know that box exists we
press approve when the commits themselves are garbage and then we get this
mess.

Accordingly, I think squash-merging makes sense as the default value to
> avoid this. People who are comfortable with the "curated MR commit
> history" workflow will of course still be able to turn it off. IMO it
> makes more sense to ask experts to turn it off than to ask newcomers and
> novices to turn it on.
>
> Thoughts?
>

-1
New to kde doesn't mean new to git. We have a lot of skilled people, and
one of the biggest gains of adopting gitlab is that we expose git more
directly.

Imho that feature request to gitlab to set a default isn't actually what
we're after. It's requesting a bodge that replaces one problem with another.

We don't want a default for a merge option, we want an exposed action like
the existing rebase button to squash things within the local branch. That
would mean reviewers can review commits (and therefore review commit
messages properly) and you still provide an easy path for people who can't
squash locally. If we only approve when commits themselves are sound, it'll
be easy to manage. Win-win.

David

Re: KDE CI: Frameworks » kxmlgui » kf5-qt5 SUSEQt5.12 - Build # 190 - Still Unstable!

[David Edmundson]

My fault. Fix on review.

David

Re: Commit hookscripts operating only on commits from email addresses associated with a Bugzilla account

[David Edmundson]

> So here's an idea: close the bug with the committer's own Bugzilla
> account when an account is found that matches the email address in the
> commit. Otherwise, use a bot account so that the bug at least gets
> closed as intended. Could that work?
>

Any developer in question can also change their gitlab "Commit email". They
don't need to change their bugzilla or git author email.
The particular unnamed lazy developer you're referring to has just got
round to changing theirs.

David


>
> Nate
>

Re: Move Plasma Firewall to KDE Review

[David Edmundson]

>Arent we trying to portaway from kdelibs4support ?

Yes.

Though in this particular case It appears that is just a CMakeLists.txt
leftover, it builds fine with that line removed.

Re: kwayland's testRemoteAccess still flaky

[David Edmundson]

Urgh, let me just remove that test.

No-one will even use that protocol soon anyway.

Re: Looking for maintainer of Wayland KDE Idle protocol

[David Edmundson]

On Tue, Jul 7, 2020 at 12:18 PM David Edmundson 
wrote:

> >It seems that the most popular Wayland protocol for detecting when a
> user is "idle" is this protocol that is a part of KDE.
>
> Yes-ish.
>
> Note it is now being upstreamed:
>
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/29
>
> So now is a good time for any changes.
>
> Any discussion should happen there. I have a feeling you're effectively
> responding to the question Simon had about interaction with idle-inhibit
> and whether we really want to inhibit idle events or actions on idle events.
>
> >One limitation that I have with this protocol is that if the user stops
> typing/mousing, but is watching a video or something, the video player
> can send fake activity with the `simulate_user_activity` request.
>
> That's not really right.
> One should use an idle inhibition protocol. Annoyingly this is fragmented,
> there's one in x and wayland but also some DBus ones.
> `simulate_user_activity`will get deprecated at some point, it just exists
> from a time to fake things in X and us mapping it.
>
> >My application is trying to track actual keyboard/mouse activity, and
> this fake activity makes things difficult (even though it is an
> effective way to prevent a lockscreen from triggering).
>
> I suspect it's idle inhibitions that's breaking it, not this simulate user
> activity. Let's follow this up on the relevant wayland-protocols thread
> above
>
> David
>
> Relevant comment:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/29#note_560996

Re: Looking for maintainer of Wayland KDE Idle protocol

[David Edmundson]

>It seems that the most popular Wayland protocol for detecting when a
user is "idle" is this protocol that is a part of KDE.

Yes-ish.

Note it is now being upstreamed:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/29

So now is a good time for any changes.

Any discussion should happen there. I have a feeling you're effectively
responding to the question Simon had about interaction with idle-inhibit
and whether we really want to inhibit idle events or actions on idle events.

>One limitation that I have with this protocol is that if the user stops
typing/mousing, but is watching a video or something, the video player
can send fake activity with the `simulate_user_activity` request.

That's not really right.
One should use an idle inhibition protocol. Annoyingly this is fragmented,
there's one in x and wayland but also some DBus ones.
`simulate_user_activity`will get deprecated at some point, it just exists
from a time to fake things in X and us mapping it.

>My application is trying to track actual keyboard/mouse activity, and
this fake activity makes things difficult (even though it is an
effective way to prevent a lockscreen from triggering).

I suspect it's idle inhibitions that's breaking it, not this simulate user
activity. Let's follow this up on the relevant wayland-protocols thread
above

David

D26503: [Dialog Shadows] Port to KWindowSystem shadows API

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  port-to-shadows-api

REVISION DETAIL
  https://phabricator.kde.org/D26503

To: zzag, #plasma, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28355: Introduce function ecm_install_configured_file

[David Edmundson]

davidedmundson added a comment.


  Moved to invent.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D28355

To: davidedmundson, #build_system
Cc: apol, kossebau, pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, 
cblack, bencreasy, michaelh, ngraham, bruns

D28355: Introduce function ecm_install_configured_file

[David Edmundson]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R240:2976b27a6c0b: Introduce function 
ecm_install_configured_file (authored by davidedmundson).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28355?vs=79176=83249

REVISION DETAIL
  https://phabricator.kde.org/D28355

AFFECTED FILES
  docs/module/ECMConfiguredInstall.rst
  modules/ECMConfiguredInstall.cmake
  tests/CMakeLists.txt
  tests/ECMConfiguredInstallTest/CMakeLists.txt
  tests/ECMConfiguredInstallTest/check_tree.cmake.in
  tests/ECMConfiguredInstallTest/configured.txt
  tests/ECMConfiguredInstallTest/configured_atOnly.txt.in
  tests/ECMConfiguredInstallTest/expected/configured.txt
  tests/ECMConfiguredInstallTest/expected/configured_atOnly.txt
  tests/ECMConfiguredInstallTest/expected/multi1.txt
  tests/ECMConfiguredInstallTest/expected/multi2.txt
  tests/ECMConfiguredInstallTest/multi1.txt.in
  tests/ECMConfiguredInstallTest/multi2.txt.in

To: davidedmundson, #build_system
Cc: apol, kossebau, pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, 
cblack, bencreasy, michaelh, ngraham, bruns

D29050: KRunner fix prepare/teardown signals

[David Edmundson]

davidedmundson added a comment.


  > the runner "backend" is used (from the QML side of things).
  
  Repo is called milou

REPOSITORY
  R308 KRunner

BRANCH
  krunner_signal_bugfix (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D29050

To: alex, meven, ngraham, broulik
Cc: davidedmundson, cfeck, kde-frameworks-devel, Orage, LeGast00n, 
The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, michaelh, 
ZrenBot, ngraham, bruns, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, ahiemstra, mart

D29228: [KProcessRunner] Use only executable name for scope

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29228

To: broulik, #frameworks, #plasma, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29811: t/simplify-sending-data-through-socket

[David Edmundson]

davidedmundson added a comment.


  > that would probably mean recompiling most of KDE (Debian has packages for 
5.69 only). I will check out your change and see what remains.
  
  This isn't a universal rule that always applies, but generally speaking you 
can just roll back the the frameworks version in the CMakeLists.txt and build 
this one framework.

REPOSITORY
  R285 KCrash

REVISION DETAIL
  https://phabricator.kde.org/D29811

To: jpalecek, #frameworks
Cc: anthonyfieroni, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D29811: t/simplify-sending-data-through-socket

[David Edmundson]

davidedmundson added a comment.


  Your base kcrash is quite out of date - I simplified this method considerably 
a month ago, which gets rid of the two paths.
  
  Also can you check your commit messages, I don't know if it's phab being 
weird, but they all start with "t/" in the phab UI,

REPOSITORY
  R285 KCrash

REVISION DETAIL
  https://phabricator.kde.org/D29811

To: jpalecek, #frameworks
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29034: Add systemd user service file for kded

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R297 KDED

REVISION DETAIL
  https://phabricator.kde.org/D29034

To: broulik, #plasma, #frameworks, davidedmundson
Cc: bruns, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham

Request for plasma framework patch release

[David Edmundson]

We seem to have a common crasher newly introduced in plasma-framework. A
dozen reports in a few days.

Can I ask for a plasma-framework 5.70.1. with
c215c54eced5bd0b195c208dd72bb580e65f8fe4 cherry-picked.

Sorry.

David

D29742: Avoid potential disconnect of all signals in IconItem

[David Edmundson]

This revision was automatically updated to reflect the committed changes.
Closed by commit R242:c215c54eced5: Avoid potential disconnect of all signals 
in IconItem (authored by davidedmundson).

REPOSITORY
  R242 Plasma Framework (Library)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29742?vs=82830=82833

REVISION DETAIL
  https://phabricator.kde.org/D29742

AFFECTED FILES
  src/declarativeimports/core/iconitem.cpp

To: davidedmundson, #plasma, ahiemstra
Cc: ahiemstra, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29742: Avoid potential disconnect of all signals in IconItem

[David Edmundson]

davidedmundson created this revision.
davidedmundson added a reviewer: Plasma.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
davidedmundson requested review of this revision.

REVISION SUMMARY
  m_svgIcon can be null.
  
  disconnect(q, nullptr, nullptr, nullptr); would have pretty catastrophic
  consequences as it disconnects everything. Anyone listening for
  QObject::destroyed of IconItem for cleanup would no longer get anything.
  That could lead to obscure conditions.
  
  ShaderEffectSource watches for the source being destroyed for cleanup
  and we have a newly introduced crash with ShaderEffectSource that seems
  to come from this patch.
  
  CCBUG: 421170

TEST PLAN
  Uploading for someone to reproduce to test

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29742

AFFECTED FILES
  src/declarativeimports/core/iconitem.cpp

To: davidedmundson, #plasma
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29680: Fix modified line marker in kate minimap

[David Edmundson]

This revision was automatically updated to reflect the committed changes.
Closed by commit R39:f2b0dcdefea7: Fix modified line marker in kate minimap 
(authored by davidedmundson).

REPOSITORY
  R39 KTextEditor

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29680?vs=82663=82717

REVISION DETAIL
  https://phabricator.kde.org/D29680

AFFECTED FILES
  src/view/kateviewhelpers.cpp

To: davidedmundson, #kate, sars
Cc: sars, ngraham, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, 
cblack, domson, michaelh, bruns, demsking, cullmann, dhaumann

D29680: Fix modified line marker in kate minimap

[David Edmundson]

davidedmundson added a comment.


  What about ktexteditor?

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D29680

To: davidedmundson, #kate
Cc: ngraham, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, 
domson, michaelh, bruns, demsking, cullmann, sars, dhaumann

D29680: Fix modified line marker in kate minimap

[David Edmundson]

davidedmundson created this revision.
davidedmundson added a reviewer: Kate.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
davidedmundson requested review of this revision.

REVISION SUMMARY
  Our pixmap is the size of the number of lines in the document. When
  rendering the pixel for the modified marker we want to take a ratio of
  currentline to lines in the pixmap.
  
  The height of the groove isn't relevant.

TEST PLAN
  Create a 1 line empty document
  Added some line in the middle
  New line and orange dot appeared in the same place

REPOSITORY
  R39 KTextEditor

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29680

AFFECTED FILES
  src/view/kateviewhelpers.cpp

To: davidedmundson, #kate
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann

D29409: Add documentation line on KCM translations

[David Edmundson]

davidedmundson added inline comments.

INLINE COMMENTS

> cblack wrote in configmodule.h:98
> You probably want to use backticks instead of quotes as this is referring to 
> something codewise.

I don't understand.

REPOSITORY
  R296 KDeclarative

REVISION DETAIL
  https://phabricator.kde.org/D29409

To: davidedmundson
Cc: cblack, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D29668: Do not reject icon theme dir with invalid context/type.

[David Edmundson]

davidedmundson added a comment.


  Seems sensible, given it's valid to have an empty context.
  
  I don't know enough about icons to know all possible ill effects. If there's 
no other comments in a few days consider this a "ship it!"

REPOSITORY
  R302 KIconThemes

REVISION DETAIL
  https://phabricator.kde.org/D29668

To: xuetianweng, #frameworks, dfaure, apol
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29292: Port KKeySequenceItem to QQC2

[David Edmundson]

This revision was automatically updated to reflect the committed changes.
Closed by commit R296:c730edc8dce4: Port KKeySequenceItem to QQC2 (authored by 
davidedmundson).

REPOSITORY
  R296 KDeclarative

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29292?vs=81557=82604

REVISION DETAIL
  https://phabricator.kde.org/D29292

AFFECTED FILES
  src/qmlcontrols/kquickcontrols/KeySequenceItem.qml
  tests/keysequencetest.qml

To: davidedmundson, #plasma, davidre, ngraham
Cc: ngraham, cblack, broulik, kde-frameworks-devel, LeGast00n, michaelh, bruns

D29511: Label: Add ping-pong logic

[David Edmundson]

davidedmundson requested changes to this revision.
davidedmundson added a comment.


  Plasmacomponents is deprecated please see Plasmacomponents3 then see the 
readme within that and put this somewhere else.
  
  1. Label is a super super super common element we don't want to add any 
overhead instantiating a label. A new special class would be best
  2. It can all be done in one SequentialAnimation, you don't need states.
  3. You don't need to get the width again, we know this already from the other 
text properties.
  4. This is broken for any text that's wrapped or elided

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D29511

To: patrickelectric, #plasma, #vdg, ognarb, davidedmundson
Cc: davidedmundson, ognarb, cblack, kde-frameworks-devel, LeGast00n, michaelh, 
ngraham, bruns

D29503: Pixel align children of GridViewInternal

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R296 KDeclarative

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29503

To: fvogt, #frameworks, broulik, mart, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D25814: [KColorScheme] Add SeparatorColor

[David Edmundson]

davidedmundson added a comment.


  Relevant link on that last comment: 
https://bugreports.qt.io/browse/QTBUG-63331
  
  They actively seeked our opinion on colour roles

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D25814

To: ndavis, #frameworks, #vdg
Cc: ahiemstra, broulik, manueljlin, alexde, ngraham, davidedmundson, filipf, 
cfeck, hpereiradacosta, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns

D29397: KPreviewJob : Support for DeviceRatioPixel

[David Edmundson]

davidedmundson added a comment.


  > Allow users of KPreviewJob to request a devicePixelRatio for generated 
thumbnails.
  
  At the risk of asking a stupid question, why?
  
  As opposed to just having a width and height always be in device pixels. 
We're always working with pixmaps is there a reason to do anything with logical 
sizes?
  That's how I thought the current design worked.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29397

To: meven, dfaure, broulik, #frameworks
Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns

D29409: Add documentation line on KCM translations

[David Edmundson]

davidedmundson created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
davidedmundson requested review of this revision.

REPOSITORY
  R296 KDeclarative

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29409

AFFECTED FILES
  src/quickaddons/configmodule.h

To: davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29374: UK, Scotland: Fix syntax error by adding category of Early May Bank Holiday

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R175 KHolidays

REVISION DETAIL
  https://phabricator.kde.org/D29374

To: weisi, winterz, davidedmundson
Cc: jriddell, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29371: KMainWindow: remove doc paragraph about KGlobal::ref usage

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R263 KXmlGui

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29371

To: dvratil, dfaure, #frameworks, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28498: [xdgoutput] Explicitly set version of server interface

[David Edmundson]

davidedmundson abandoned this revision.
davidedmundson added a comment.


  All these problems go away with KWaylandServer \o/

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D28498

To: davidedmundson, #kwin
Cc: zzag, anthonyfieroni, apol, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns

D29278: Port KWin to KWaylandServer

[David Edmundson]

davidedmundson added a comment.


  > Hmm, I can't build kwin
  
  Hit the same thing, we've since fixed that (patch in kwayland-server)

REPOSITORY
  R108 KWin

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29278

To: apol, #kwin, #plasma, #frameworks, davidedmundson
Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, 
ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, 
romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29278: Port KWin to KWaylandServer

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R108 KWin

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29278

To: apol, #kwin, #plasma, #frameworks, davidedmundson
Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, 
ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, 
romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D29292: Port KKeySequenceItem to QQC2

[David Edmundson]

davidedmundson added inline comments.

INLINE COMMENTS

> broulik wrote in KeySequenceItem.qml:57
> Why is it the worst? It keeps us from having to hardcode magic numbers.

See task.

REPOSITORY
  R296 KDeclarative

REVISION DETAIL
  https://phabricator.kde.org/D29292

To: davidedmundson, #plasma, davidre
Cc: cblack, broulik, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D29292: Port KKeySequenceItem to QQC2

[David Edmundson]

davidedmundson added inline comments.

INLINE COMMENTS

> cblack wrote in KeySequenceItem.qml:57
> Are we able to use some form of units? Hardcoding this seems wrong.

> Can we use the non-attached version here please since it's not likely

It's the worst!

> Are we able to use some form of units? Hardcoding this seems wrong.

It's come up before, this isn't ideal, but there's no other consistent 
alternative. It's the convention followed elsewhere.

Let's follow that up on https://phabricator.kde.org/T10873

> broulik wrote in KeySequenceItem.qml:58
> Is this `_tr` thing we could also improve (separately o/c)?

We need to specify the domain, but you're right i18nd would work just as well 
and save a QObject

REPOSITORY
  R296 KDeclarative

REVISION DETAIL
  https://phabricator.kde.org/D29292

To: davidedmundson, #plasma, davidre
Cc: cblack, broulik, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns

D29292: Port KKeySequenceItem to QQC2

[David Edmundson]

davidedmundson created this revision.
davidedmundson added a reviewer: Plasma.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
davidedmundson requested review of this revision.

REVISION SUMMARY
  This implicitly fixes a bug where space is used in the shortcut item.
  Previously as QQC1 button was made up of multiple objects the key
  handling would be handled by an internal object before our filters.
  
  In QQC2 it's all one item, so our Keys handler takes precendence.

TEST PLAN
  Added a test file
  Set the button to control+space, alt+4
  Set the button to alt+space (this correctly showed a warning about a conflict)
  Confirmed tooltip worked correctly
  Used space to activate the button when we weren't recording. This someone 
still worked..

REPOSITORY
  R296 KDeclarative

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29292

AFFECTED FILES
  src/qmlcontrols/kquickcontrols/KeySequenceItem.qml
  tests/keysequencetest.qml

To: davidedmundson, #plasma
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D29231: Add keyboard_shortcuts_inhibit protocol

[David Edmundson]

davidedmundson added inline comments.

INLINE COMMENTS

> zzag wrote in keyboard_shortcuts_inhibit_interface.cpp:21
> You've probably meant Q_DECL_HIDDEN, right?
> 
> On an unrelated note: there are valid arguments against nested private 
> classes so it would be really nice if we revisit this topic in the new repo.

yeah, that one

> there are valid arguments against nested private classes so it would be 
> really nice if we revisit this topic in the new repo.

Sure

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D29231

To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

D29231: Add keyboard_shortcuts_inhibit protocol

[David Edmundson]

davidedmundson added a comment.


  Let's wait for the new kwaylandserver repo before pushing.
  
  But ++, looks good.

INLINE COMMENTS

> keyboard_shortcuts_inhibit_interface.cpp:21
> +
> +class KeyboardShortcutsInhibitorInterface::Private : public 
> QtWaylandServer::zwp_keyboard_shortcuts_inhibitor_v1
> +{

Q_DECL_PRIVATE

> keyboard_shortcuts_inhibit_interface.cpp:35
> +
> +KeyboardShortcutsInhibitorInterface::Private::Private(wl_resource *resource, 
> int id, SurfaceInterface *surface,
> +  SeatInterface *seat,

It's not clear what resource this argument is referring to.

I think from reading the code it's the resource of the manager? At which point 
"parentResource" would be a better name.

Or separate client, id, version args.

REPOSITORY
  R127 KWayland

REVISION DETAIL
  https://phabricator.kde.org/D29231

To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns

Re: Splitting KWayland

[David Edmundson]

That is what I imagined.

The protocols section contains some things we can strip down.
We shouldn't host anything that's in wayland-protocols like text-input.
Also I think there's some dead things like plasma-effects.

But we can do that sort of thing anytime before the first release.

David

D29256: [server] Introduce mapped() signal

[David Edmundson]

davidedmundson accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R127 KWayland

BRANCH
  introduce-mapped-signal

REVISION DETAIL
  https://phabricator.kde.org/D29256

To: zzag, #kwin, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

Re: Splitting KWayland

[David Edmundson]

On Tue, 28 Apr 2020, 07:24 Vlad Zahorodnii,  wrote:

> On 4/27/20 4:12 PM, David Edmundson wrote:
> > I don't think we want to remove client or server tests on this one. As
> > the client tests covered the server side too
>
> Hmm, does this mean we are going to keep both the client and the server
> side in KWaylandServer?
>

No.

We said we would build them against KWayland::Client

With the slow migration for the protocols to be against the new approach.

David

>
> Cheers,
> Vlad
>
>
>