D28196: BUGFIX BookmarksRunner: Fix wrong default profile extraction, remove caching

[Alexander Lohnau]

alex created this revision.
alex added reviewers: bruns, z3ntu, apol, broulik, davidedmundson.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
alex requested review of this revision.

REVISION SUMMARY
  Before this patch the path to the default profile database was once read and 
then written in the config. And as long as this file exists this value would be 
used. But if the user changes the default profile in Firefox the old profile 
will still be used (as long as it is not deleted).
  
  And the default profile was also not always correctly extracted (this 
configuration got only edited in the about:profiles page in Firefox):
  F8192502: BugfixDoc 

TEST PLAN
  Test if the bookmarks are correctly displayed (with a single profile), add a 
new profile and restart KRunner, set the default profile back to the old 
profile and restart KRunner.
  The bookmarks should always be displayed.

REPOSITORY
  R120 Plasma Workspace

BRANCH
  bookmarks_firefox_bugfix (branched from master)

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

AFFECTED FILES
  runners/bookmarks/browsers/firefox.cpp

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

D28196: BUGFIX BookmarksRunner: Fix wrong default profile extraction, remove caching

[Alexander Lohnau]

alex updated this revision to Diff 78205.
alex added a comment.


  Add check if profilePath is empty

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28196?vs=78204&id=78205

BRANCH
  bookmarks_firefox_bugfix (branched from master)

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

AFFECTED FILES
  runners/bookmarks/browsers/firefox.cpp

To: alex, bruns, z3ntu, apol, broulik, davidedmundson, #plasma
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27669: [kstyle] Tools area

[David Redondo]

davidre added inline comments.

INLINE COMMENTS

> breezehelper.cpp:90
> +_decorationConfig->load();
> +if (qApp && qApp->property("KDE_COLOR_SCHEME_PATH").isValid()) {
> +const auto path = 
> qApp->property("KDE_COLOR_SCHEME_PATH").toString();

I don't think you need such a big if. Loading a kconfig with empty string will 
load kdeglobals

REPOSITORY
  R31 Breeze

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

To: cblack, #plasma, #breeze, #vdg
Cc: IlyaBizyaev, davidre, davidedmundson, hpereiradacosta, ngraham, manueljlin, 
niccolove, ndavis, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

[Johan Ouwerkerk]

On Sun, Mar 22, 2020 at 3:20 AM Ben Cooksley  wrote:
>
> We already do have a repository of artifacts :)
> You can find the public view of this at
> https://build-artifacts.kde.org/production/
>

>
> We already use Virtual Machines for both FreeBSD and Windows.
>
> The main problem here is that there is no way of dynamically
> provisioning full VMs without building an entire Openstack type
> system, which is just too much overhead for the number of builders we
> have.
>

First of all, thanks for your patience in explaining to me what must
be obvious to you. I really appreciate it.

>
> Shouldn't this kind of experimentation be done on developers systems
> rather than the CI system?
> Please do remember that CI resources are not infinite and at times can
> be quite constrained.
>
> My main query here though is what would be achieved by allowing this
> sort of thing that the existing system does not allow for?
> (Ignoring the fact we don't cover feature branches - something which
> is in the long term pipeline)
>

Pure experimentation should definitely be done on developers' systems.
But changes to your CI cannot be fully validated on your own machine
beforehand: you need to verify that it works on the actual CI
builders. Ideally without breaking the CI for anyone else.

So the main gain here is that projects can improve, evaluate and
mature their CI efforts independently. Examples of things we currently
don't have but some projects might benefit from are: licensing
compliance checking (reuse), dependency scanning (e.g.: snyk) and
mutation testing (e.g.: stryker).

I'm not saying that this couldn't be achieved today with a lot of help
and guidance from the sysadmins. But I think this does impose a lot of
overhead, especially while such changes are still experimental and do
not fully work yet in CI or need tweaking for prettier output or
whatever. In fact, your reply to my other question kind of indicates
as much:

> >
> > Possibly projects would also submit custom images for consideration to
> > that registry.
>
> This isn't something that is terribly easy to do within our existing
> Jenkins setup - but is theoretically possible. It requires quite a bit
> of provisioning work on the Jenkins side.
>
> The CI scripts would also need some adapting to make this sort of
> setup efficient to operate with them if you were to use them (and you
> probably do want to use them for running tests).
> A good portion of this adapting will done as part of moving the CI
> system to Gitlab.

Does this mean that we will be encouraged to configure `image`
settings in .gitlab-ci.yml? If so, that basically gives me what I
really wanted here. All the actual images I might ever need could be
submitted for review via MR to a repository on invent as and when I
would need them.

>
> Note however that images based upon Fedora or anything that shares
> it's lineage (including CentOS and it's derivates) is strictly
> prohibited and won't be accepted for inclusion.
>

Personally I'm more inclined towards using Debian myself, but out of
interest what is the reason for banning Fedora and CentOS images? Does
this still apply when the move to Gitlab CI is completed?

Regards,

- Johan

Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

[Albert Astals Cid]

El diumenge, 22 de març de 2020, a les 3:19:57 CET, Ben Cooksley va escriure:
> Note however that images based upon Fedora or anything that shares
> it's lineage (including CentOS and it's derivates) is strictly
> prohibited and won't be accepted for inclusion.

I still find this highly annoying since Fedora seems to be the only distro 
providing an almost full stack of mingw packages so for example i could add 
easily a mingw/windows CI to QCA using fedora but i can't because, for some 
reason i forgot, you are very unhappy with them.

Cheers,
  Albert

> 
> >
> > Regards,
> >
> > - Johan
> 
> Cheers,
> Ben
> 

D28200: Enable wrapping of error messages which use KMessageWidget

[Kitae Kim]

develoot created this revision.
develoot added a reviewer: VDG.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
develoot requested review of this revision.

REVISION SUMMARY
  Error messages should be shown to users no matter how much long it is.

REPOSITORY
  R119 Plasma Desktop

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

AFFECTED FILES
  kcms/activities/imports/dialog.cpp
  kcms/hardware/joystick/joywidget.cpp
  kcms/touchpad/src/kcm/xlib/touchpadconfigxlib.cpp

To: develoot, #vdg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

CI mail filtering (was Re: Manner in which kde-gtk-config development is conducted)

[Ahmad Samir]

On 21/03/2020 22:38, Ben Cooksley wrote:

On Sun, Mar 22, 2020 at 3:08 AM David Edmundson
 wrote:


You're absolutely right that mistakes were made and have reason to be
frustrated.

kde-gtk-config is now maintained by new developers.
Plasma has a new influx of new people which is good to see and
something we need to foster carefully.

Overall these new devs are doing a super job and we want to encourage them.

Ultimately there are two parties at fault:
  - brand new developers who didn't know the rules. KDE has a lot of
rules and they're certainly not all written down in a consistent
location.

  - the more "senior" Plasma people (me, Kai, Aleix, etc) who do know
the rules, not paying due attention to something that's now under
Plasma's umbrella


which means that the repository is no longer eligible to form
part of a KDE release module and should be moved to Playground


I think this is an overreaction that punishes the wrong people. Users.


The reaction is intended to force the hand of Plasma as a collective
group to pay attention to the notifications from the CI system - which
it delivers to the plasma-devel mailing list.
I know that some people do pay attention to these, but it is evident
that others do not or have active filtering in place to ensure they
don't see them.



The traffic of CI mail can be a bit daunting, and failure mails could simply go unnoticed, so I 
suggest some "reverse filtering", i.e. I've just created a filter in Thunderbird:

From: CI System 
X-Jenkins-Results: FAILURE

(in TBird you can create customise message headers and add a new one).

I don't care as much about success reports, (and I haven't yet dug in the mails to create a filter 
to cull mails about successful builds that have some unit tests failure).


I suggest that if you commit regulary to a KDE repo to make a habit of checking the results of the 
unit tests on the CI every now and then (jenkins has a nice web interface). Unit tests could pass 
locally and fail on the CI for some reason.


[...]


My, beginner-dev, 2 p's,

--
Ahmad Samir

D28115: feat(kded): add a dbus method to lock current rotation

[Roman Gilg]

romangg requested changes to this revision.
romangg added a comment.
This revision now requires changes to proceed.


  Please call the functions `AutoRotate`. I failed to name it consistently in 
the code until now but let's go with AutoRotate from now on (and I will try to 
rename it where I accidentally said AutoRotation in some form). Reasons are 
that it's shorter and when I googled it I found only one technical document. 
Was for Android and called the feature that way 
.

INLINE COMMENTS

> config.cpp:104
> +}
> +}
> +

Do it like this:

  void Config::setAutoRotation(bool value)
  {
  for (KScreen::OutputPtr &output : m_data->outputs()) {
  if (output->type() != KScreen::Output::Type::Panel) {
  continue;
  }
  if(m_control->getAutoRotate(output) != value) {
  m_control->setAutoRotate(output, value);
  }
  }
  m_control->writeFile();
  }

REPOSITORY
  R104 KScreen

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

To: bshah, romangg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

[Ben Cooksley]

On Mon, Mar 23, 2020 at 12:49 AM Albert Astals Cid  wrote:
>
> El diumenge, 22 de març de 2020, a les 3:19:57 CET, Ben Cooksley va escriure:
> > Note however that images based upon Fedora or anything that shares
> > it's lineage (including CentOS and it's derivates) is strictly
> > prohibited and won't be accepted for inclusion.
>
> I still find this highly annoying since Fedora seems to be the only distro 
> providing an almost full stack of mingw packages so for example i could add 
> easily a mingw/windows CI to QCA using fedora but i can't because, for some 
> reason i forgot, you are very unhappy with them.
>

I'm unhappy with them due to how they handled the complete disaster
that was a significant version update to a core system library (libc I
think) which they did in a stable, released distribution. As one would
expect, trying to do such an update broke things, in particular it
broke the BDB libraries, which are used by amongst other things, their
package manager (DNF).

Once this became apparent (which didn't take long) not only did they
not withdraw the update to libc/glibc, they pressed ahead with a
series of hotfixes to bdb and the package manager. Unfortunately these
were reliant on the underlying file system supporting a particular set
of POSIX specified functionality, which overlayfs (the file system
used by Docker) didn't support. The end result of all of this is that
it was impossible for us to generate a new CI image.

While this is already bad, this was then amplified by the reaction on
the Fedora side, where the DNF developers ignored our (and others)
report of the issue they said was fixed still being broken. Two weeks
later, and still being ignored, I complained to the Fedora Engineering
Steering Committee (Fesco) concerning this, and after a few days
someone asked someone else to rebuild the base Fedora Docker image -
which pulled in some fixes that resolved the issue finally and let us
generate an image.

Following this my complaint was closed as "resolved", even though they
had not put in place any safeguards to prevent this from happening
again, nor had they addressed the failure of the maintainers of one of
the core components of their distribution to respond to users
regarding something that was totally broken.

Unsurprisingly, within a few days the DNF developers pushed yet
another update that broke the build of the image again. I returned to
Fesco, asking for the push privileges of the DNF developers to be
suspended as they had broken it yet again.

This finally resulted in the DNF developers responding (funny that!),
but not with an apology or anything along those lines. Instead, they
engaged in a ranting attack. In this they made various errornous
claims (including that we were using an out of date Fedora image,
which was not the case and I had provided logs earlier which
demonstrated this which it was obvious they had failed to read) and
were in general extremely hostile.

Following this there was some back and forth and the issue was
scheduled for discussion at the next Fesco online meeting (apparently
they only make decisions once a week at these meetings). This time for
this meeting came and went, with no comment made on the issue.
Following further investigation I found out the meeting had been
cancelled due to a lack of attendence, which had not been communicated
to us.

It was at this point that I had finally had enough of Fedora (having
previously had to deal with their internal politics over the packaging
of QtWebEngine, which meant we ended up having to use Qt 5.8 rather
than the Qt 5.9 which we had initially targeted as the 5.9 packaging
was blocked) and dumped them for SUSE, the images that we continue to
use today.

For those wondering, my complaint against the DNF developers was
dismissed and closed as "they were responding now" with a one line
message posted through an IRC Bot about a week later when they held
their next meeting.

Suffice to say, I don't want anything to do with Fedora ever again. It
was an extremely stressful 6 weeks or so in all, with developers
chasing up when we could get some additional packages installed and us
being unable to deliver because Fedora had broken things.

This is why Fedora and all associated derivatives are banned from our systems.

> Cheers,
>   Albert

With regards to MingW, the better way to do this would be by using
native MingW rather than cross compiling. Craft already uses MingW for
some dependencies, and Krita's binary factory builds use it as well so
most of the infrastructure for this is already in position.

Regards,
Ben

>
> >
> > >
> > > Regards,
> > >
> > > - Johan
> >
> > Cheers,
> > Ben
> >
>
>
>
>

Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

[Ben Cooksley]

On Mon, Mar 23, 2020 at 12:41 AM Johan Ouwerkerk  wrote:
>
> On Sun, Mar 22, 2020 at 3:20 AM Ben Cooksley  wrote:
> >
> > We already do have a repository of artifacts :)
> > You can find the public view of this at
> > https://build-artifacts.kde.org/production/
> >
>
> >
> > We already use Virtual Machines for both FreeBSD and Windows.
> >
> > The main problem here is that there is no way of dynamically
> > provisioning full VMs without building an entire Openstack type
> > system, which is just too much overhead for the number of builders we
> > have.
> >
>
> First of all, thanks for your patience in explaining to me what must
> be obvious to you. I really appreciate it.
>
> >
> > Shouldn't this kind of experimentation be done on developers systems
> > rather than the CI system?
> > Please do remember that CI resources are not infinite and at times can
> > be quite constrained.
> >
> > My main query here though is what would be achieved by allowing this
> > sort of thing that the existing system does not allow for?
> > (Ignoring the fact we don't cover feature branches - something which
> > is in the long term pipeline)
> >
>
> Pure experimentation should definitely be done on developers' systems.
> But changes to your CI cannot be fully validated on your own machine
> beforehand: you need to verify that it works on the actual CI
> builders. Ideally without breaking the CI for anyone else.
>
> So the main gain here is that projects can improve, evaluate and
> mature their CI efforts independently. Examples of things we currently
> don't have but some projects might benefit from are: licensing
> compliance checking (reuse), dependency scanning (e.g.: snyk) and
> mutation testing (e.g.: stryker).
>

Sounds reasonable enough.

My main concern here is people trying to replicate builds under their
$distroOfChoice which doesn't really add value to the system but which
does increase resource consumption.

> I'm not saying that this couldn't be achieved today with a lot of help
> and guidance from the sysadmins. But I think this does impose a lot of
> overhead, especially while such changes are still experimental and do
> not fully work yet in CI or need tweaking for prettier output or
> whatever. In fact, your reply to my other question kind of indicates
> as much:
>
> > >
> > > Possibly projects would also submit custom images for consideration to
> > > that registry.
> >
> > This isn't something that is terribly easy to do within our existing
> > Jenkins setup - but is theoretically possible. It requires quite a bit
> > of provisioning work on the Jenkins side.
> >
> > The CI scripts would also need some adapting to make this sort of
> > setup efficient to operate with them if you were to use them (and you
> > probably do want to use them for running tests).
> > A good portion of this adapting will done as part of moving the CI
> > system to Gitlab.
>
> Does this mean that we will be encouraged to configure `image`
> settings in .gitlab-ci.yml? If so, that basically gives me what I
> really wanted here. All the actual images I might ever need could be
> submitted for review via MR to a repository on invent as and when I
> would need them.

I would prefer if we could avoid the proliferation of too many images
if at all possible, however there may be scope for this where they
don't overlap functionality wise with our existing images (a different
Qt version does not overlap, but providing builds using a different
distribution for a version of Qt already covered definitely would
overlap)

>
> >
> > Note however that images based upon Fedora or anything that shares
> > it's lineage (including CentOS and it's derivates) is strictly
> > prohibited and won't be accepted for inclusion.
> >
>
> Personally I'm more inclined towards using Debian myself, but out of
> interest what is the reason for banning Fedora and CentOS images? Does
> this still apply when the move to Gitlab CI is completed?

I've detailed this ban in my response to Albert.
The ban applies to all parts of our infrastructure, including Gitlab,
and is indefinite in duration.

Images based upon Debian, Ubuntu and SUSE are perfectly acceptable.

>
> Regards,
>
> - Johan

Cheers,
Ben

D28115: feat(kded): add a dbus method to lock current rotation

[Bhushan Shah]

bshah updated this revision to Diff 78232.
bshah added a comment.


  - rename methods to AutoRotate
  - write control file after change, thanks @romangg for suggestion

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28115?vs=77896&id=78232

BRANCH
  arcpatch-D28115

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

AFFECTED FILES
  kded/config.cpp
  kded/config.h
  kded/daemon.cpp
  kded/daemon.h
  kded/org.kde.KScreen.xml

To: bshah, romangg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28115: feat(kded): add a dbus method to lock current rotation

[Roman Gilg]

romangg accepted this revision.
romangg added inline comments.
This revision is now accepted and ready to land.

INLINE COMMENTS

> config.cpp:103
> +}
> +if(m_control->getAutoRotate(output) != value) {
> +m_control->setAutoRotate(output, value);

On push change to: `if (` (whitespace)

REPOSITORY
  R104 KScreen

BRANCH
  arcpatch-D28115

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

To: bshah, romangg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28115: feat(kded): add a dbus method to lock current rotation

[Bhushan Shah]

bshah updated this revision to Diff 78233.
bshah added a comment.


  whitespace

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28115?vs=78232&id=78233

BRANCH
  arcpatch-D28115

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

AFFECTED FILES
  kded/config.cpp
  kded/config.h
  kded/daemon.cpp
  kded/daemon.h
  kded/org.kde.KScreen.xml

To: bshah, romangg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28115: feat(kded): add a dbus method to lock current rotation

[Bhushan Shah]

This revision was automatically updated to reflect the committed changes.
Closed by commit R104:7e98fd7c1b29: feat(kded): add a dbus method to lock 
current rotation (authored by bshah).

REPOSITORY
  R104 KScreen

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28115?vs=78233&id=78234

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

AFFECTED FILES
  kded/config.cpp
  kded/config.h
  kded/daemon.cpp
  kded/daemon.h
  kded/org.kde.KScreen.xml

To: bshah, romangg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28057: Fix/Allow folderview popup mode icon and list icon size

[Alexandre Pereira]

pereira.alex updated this revision to Diff 78238.
pereira.alex added a comment.


  Fixing bug on changing icon size between list/grid view
  
  So with this commit, I fixed the bug that was happening explained in previous 
commit.
  Actually, this was what was happening that cause the opening of the bug 
report.
  
  Now, one can change between list and grid view mode, change size on list 
mode, change size on grid mode
  and everything will work as should be ( no need to restart plasmashell ).
  
  So it seems the code is using iconSize property for icons, with the exception 
of FolderView.qml
  that uses the makeIconSize function. Instead of creating functions/if's to 
test which mode is being used,
  I created two config variables: listViewIconSize and gridViewIconSize. The 
config qml (ConfigIcons.qml) will use those
  two variables and update the iconSize config variable, which will then be 
used by the plasmoid as the icon size.
  
  So to summarize, instead of "detecting" if list view or grid view mode, 
  config will update iconSize with the proper size from listViewIconSize or 
gridViewIconSize.
  
  If this logic of code is fine, in the next work I will merge the patch I did 
previously to only use
  one slider, and then remove the makeIconSize function.

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28057?vs=77808&id=78238

BRANCH
  fix-folderview-popup-icon-list-size (branched from master)

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

AFFECTED FILES
  containments/desktop/package/contents/config/main.xml
  containments/desktop/package/contents/ui/ConfigIcons.qml
  containments/desktop/package/contents/ui/FolderView.qml

To: pereira.alex, #plasma, #vdg, ngraham
Cc: ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28115: feat(kded): add a dbus method to lock current rotation

[David Edmundson]

davidedmundson added a comment.


  How does mobile retrieve the current lockAutoRotate value?

REPOSITORY
  R104 KScreen

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

To: bshah, romangg
Cc: davidedmundson, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28115: feat(kded): add a dbus method to lock current rotation

[Roman Gilg]

romangg added a comment.


  In D28115#632489 , @davidedmundson 
wrote:
  
  > How does mobile retrieve the current lockAutoRotate value?
  
  
  It could read it from the config file. But it would be better to add another 
dbus method for that.

REPOSITORY
  R104 KScreen

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

To: bshah, romangg
Cc: davidedmundson, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

Re: CI talk (Was: re: Manner in which kde-gtk-config development is conducted)

[Albert Astals Cid]

El diumenge, 22 de març de 2020, a les 16:12:04 CET, Ben Cooksley va escriure:
> On Mon, Mar 23, 2020 at 12:49 AM Albert Astals Cid  wrote:
> >
> > El diumenge, 22 de març de 2020, a les 3:19:57 CET, Ben Cooksley va 
> > escriure:
> > > Note however that images based upon Fedora or anything that shares
> > > it's lineage (including CentOS and it's derivates) is strictly
> > > prohibited and won't be accepted for inclusion.
> >
> > I still find this highly annoying since Fedora seems to be the only distro 
> > providing an almost full stack of mingw packages so for example i could add 
> > easily a mingw/windows CI to QCA using fedora but i can't because, for some 
> > reason i forgot, you are very unhappy with them.
> >
> 
> ...
> 
> This is why Fedora and all associated derivatives are banned from our systems.

Is there a way they can be ever forgiven or is your plan to ban Fedora forever?

> 
> > Cheers,
> >   Albert
> 
> With regards to MingW, the better way to do this would be by using
> native MingW rather than cross compiling. Craft already uses MingW for
> some dependencies, and Krita's binary factory builds use it as well so
> most of the infrastructure for this is already in position.

But that's something that requires magic and thus sysadmin to do it, a 
Fedora+mingw gitlab CI is something i can do myself.

But If you're volunteering to do a Windows gitlab CI for QCA I'll take it :)

Cheers,
  Albert

> 
> Regards,
> Ben
> 
> >
> > >
> > > >
> > > > Regards,
> > > >
> > > > - Johan
> > >
> > > Cheers,
> > > Ben
> > >
> >
> >
> >
> >
> 

Drag and drop to system tray

[Martin Bammer]

Hi,

are there any plans to implement drap and drop support to system tray?
So that it is possible to drag any file to an icon in the system tray,
then the window of the corresponding app opens and then the file can be
dropped in the right destination.

Best regards,

Martin

Re: Drag and drop to system tray

[David Edmundson]

When you say system tray, what specifically are you referring to?

There are definitely no plans to support dropping files onto the
org.kde.plasma.systemtray containment.

Re: Drag and drop to system tray

[Kai Uwe Broulik]

Hi,

I think Martin means a behavior similar to the task manager where 
dragging a file over a window and waiting a little will raise that 
window so you can drag that file into the corresponding window.


There's no plans to implement this and I personally think apps don't 
belong in System Tray to begin with so, I'll leave it to someone else to 
decide whether that's a good idea or not.


There's no way to "raise" the corresponding window, though, we can just 
send a "left clicked" signal which then usually brings the window to the 
front but it might not. And also while you're dragging, focus stealing 
prevention might be in effect? Implementation sounds trivial to me but I 
don't think it'll work reliable enough to be useful. Also, since most 
System Tray icons are applets which hardly ever handle any files.


Cheers
Kai Uwe

D28208: Move sni icon handling logic from data engine to applet

[David Redondo]

davidre created this revision.
davidre added reviewers: kmaterka, broulik, mart, Plasma, VDG.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
davidre requested review of this revision.

REVISION SUMMARY
  The engine does complicated logig in order to provide a pre rendered icon.
  However in combination with IconItem this also resulted in bugs causing
  overlay icons to effectively not work (correctly) [1, 2].  This exposes the 
name and pixmap
  properties in the data engine as in the specification [3]. Displaying of the 
data
  is now done at the correct layer. The statusnotifertest is additionally 
extended
  to make testing of all combinations of icon properties easier. For now the old
  combined properties are kept for backwards compatibility but can be removed in
  a later commit or in Plasma 6.
  [1] https://phabricator.kde.org/D28107
  [2] https://phabricator.kde.org/D27617#630440
  [3] 
https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/

TEST PLAN
  use statusnotifiertest

REPOSITORY
  R120 Plasma Workspace

BRANCH
  sni (branched from master)

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

AFFECTED FILES
  applets/systemtray/package/contents/ui/items/StatusNotifierItem.qml
  applets/systemtray/systemtraymodel.cpp
  applets/systemtray/systemtraymodel.h
  applets/systemtray/tests/statusnotifier/statusnotifiertest.cpp
  applets/systemtray/tests/statusnotifier/statusnotifiertest.ui
  dataengines/statusnotifieritem/statusnotifieritemsource.cpp

To: davidre, kmaterka, broulik, mart, #plasma, #vdg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28208: Move sni icon handling logic from data engine to applet

[David Redondo]

davidre added a comment.


  For now I tried to replicate `KIconLoader::drawOverlays` that is used in 
IconItem but that results in very small overlays. Because of this I added #vdg 
 for opinions on better sizing.

REPOSITORY
  R120 Plasma Workspace

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

To: davidre, kmaterka, broulik, mart, #plasma, #vdg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D26738: Launch plugin with argument, change signals

[Alexander Lohnau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R119:04e60d7e65b6: Launch plugin with argument, change signals 
(authored by alex).

REPOSITORY
  R119 Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26738?vs=73814&id=78254

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

AFFECTED FILES
  kcms/runners/kcm.cpp
  kcms/runners/kcm.h

To: alex, broulik, mart
Cc: apol, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, ahiemstra, mart

D28208: Move sni icon handling logic from data engine to applet

[Nathaniel Graham]

ngraham added inline comments.

INLINE COMMENTS

> StatusNotifierItem.qml:84
> +}
> +return 64;
> +}

Most of these numbers correspond to standard icon sizes (e.g. 
`units.iconSize.smallMedium` == 22); maybe use those where possible

> StatusNotifierItem.qml:90
> +bottom: iconItem.bottom
> +bottomMargin: 0.05 * iconItem.width
> +rightMargin: anchors.bottomMargin

always round when multiplying by a non-integer value

REPOSITORY
  R120 Plasma Workspace

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

To: davidre, kmaterka, broulik, mart, #plasma, #vdg
Cc: ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28208: Move sni icon handling logic from data engine to applet

[David Redondo]

davidre added inline comments.

INLINE COMMENTS

> StatusNotifierItem.qml:84
> +}
> +return 64;
> +}

Good to know! That was a  straight copy from 
https://cgit.kde.org/kiconthemes.git/tree/src/kiconloader.cpp#n478 :D
I'm sure we can find better sizing though, I think this is to small, for sure.

REPOSITORY
  R120 Plasma Workspace

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

To: davidre, kmaterka, broulik, mart, #plasma, #vdg
Cc: ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

Re: Drag and drop to system tray

[Martin Bammer]

"Also, since most System Tray icons are applets which hardly ever
handle any files."

You forgot about applications like Telegram, Skype, etc. These
applications indeed accept files for sending.
Currently if I want to send a file via drag and drop I have to open the
window (e.g. Telegram) first (if it is minimized to the system tray),
then I can drag and drop it.
Wouldn't it be more convenient for the user to have DnD support in the
system tray?

I think Apple has exactly this feature.

Best regards,

Martin

D27495: Remove unnecessary code and function calls

[Alexander Lohnau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R120:86fd0f2f7176: Remove unnecessary code and function calls 
(authored by alex).

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27495?vs=76009&id=78257

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

AFFECTED FILES
  runners/shell/CMakeLists.txt
  runners/shell/shellOptions.ui
  runners/shell/shell_config.cpp
  runners/shell/shell_config.h
  runners/shell/shellrunner.cpp
  runners/shell/shellrunner.h

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

D27098: Bugfix: Konsole does not launch, optimize and simplify runner

[Alexander Lohnau]

alex added a comment.


  Ping :-)

REPOSITORY
  R114 Plasma Addons

BRANCH
  konsole_bugfix (branched from master)

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

To: alex, davidedmundson, ngraham, #plasma, #konsole, tcanabrava, hindenburg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28209: [applets/notes] Actually hide button row when it's not visible

[Nathaniel Graham]

ngraham created this revision.
ngraham added reviewers: Plasma, VDG.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
ngraham requested review of this revision.

REVISION SUMMARY
  Currently the row's opacity is changed from 0% to 100% depending on focus 
state, but it
  does not actually become hidden when at 0% opacity. This means that it's 
possible to
  click the invisible buttons accidentally when focusing the applet. This has 
been an
  issue for a long time, but becomes dangerous with D28064 
, since you could delete a note just by 
clicking in the bottom-right corner to focus the applet!
  
  This patch makes the button row actually hidden when the applet is not 
focused, not just
  100% transparent.

TEST PLAN
  Clicking on the place where a button will appear on an unfocused applet now 
just focuses
  it and does not also click the button

REPOSITORY
  R114 Plasma Addons

BRANCH
  hide-row (branched from master)

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

AFFECTED FILES
  applets/notes/package/contents/ui/main.qml

To: ngraham, #plasma, #vdg
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27783: Add new Account portal

[Nathaniel Graham]

ngraham added a comment.


  How can I test this?

REPOSITORY
  R838 Flatpak Support: KDE Portal for XDG Desktop

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

To: jgrulich, #plasma, ngraham
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28200: Enable wrapping of error messages which use KMessageWidget

[Nathaniel Graham]

ngraham added reviewers: Plasma, Frameworks.
ngraham added a comment.


  Thanks for the patch! I wonder if it makes sense to set this on the widget 
itself, as a sensible default. You're probably going to want to word-wrap more 
often than you aren't.

REPOSITORY
  R119 Plasma Desktop

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

To: develoot, #vdg, #plasma, #frameworks
Cc: ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28208: Move sni icon handling logic from data engine to applet

[Konrad Materka]

kmaterka added inline comments.

INLINE COMMENTS

> StatusNotifierItem.qml:58
>  }
> +// IconItem.overlays only supports names so we need a second item for 
> the overlay, using the same
> +// positioning that KIconLoader::drawOverlays uses that IconItem uses 
> internally

Should overlay pixmaps be supported in `PlasmaCore.IconItem`? I guess that 
would require changes in `KIconLoader` as well.

> StatusNotifierItem.qml:72
> +width: {
> +if (iconItem.width < 32) {
> +return 8;

In StatusNotifierItemSource::overlayIcon() 

 it is "width <= 32". There is a pre-existing inconsistency between 
StatusNotifierItemSource and IconItem/KIconLoader.

> davidre wrote in StatusNotifierItem.qml:84
> Good to know! That was a  straight copy from 
> https://cgit.kde.org/kiconthemes.git/tree/src/kiconloader.cpp#n478 :D
> I'm sure we can find better sizing though, I think this is to small, for sure.

StatusNotifierItemSource::overlayIcon() 

 also has some sizes hard coded. I quickly checked, looks like the values are 
the same.
You can use the same syntax here:

  if (iconItem.width <= units.iconSize.medium) {
  return units.iconSize.small / 2;
  }
  if (iconItem.width <= units.iconSize.large) {
  return units.iconSize.small;
  }

> ngraham wrote in StatusNotifierItem.qml:90
> always round when multiplying by a non-integer value

In StatusNotifierItemSource::overlayIcon() 

 it has a different logic to position overlay. Margin is always the size of 
overlay icon. Another pre-existing inconsistency. Which one to choose? I think 
that `KIconLoader` is more important.

> systemtraymodel.h:97
>  IconThemePath,
>  IconsChanged,
>  Id,

You can safely remove all *Changed as well. Or maybe better in a separate 
commit?

> statusnotifieritemsource.cpp:90
>  //by setting everything up-front so that we have all role names when we 
> call the first checkForUpdate()
> +// TODO Plasma 6 remove combined "*Icon" properties and only expose the 
> raw "*IconName" and "*IconPixmap" properties
>  setData(QStringLiteral("AttentionIcon"), QIcon());

I would suggest to extend removal to all *Changed roles. These are not used 
(were in KDE/Plasma 4).

REPOSITORY
  R120 Plasma Workspace

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

To: davidre, kmaterka, broulik, mart, #plasma, #vdg
Cc: ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28200: Enable wrapping of error messages which use KMessageWidget

[David Edmundson]

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


  > I wonder if it makes sense to set this on the widget itself, as a sensible 
default.
  
  No.
  
  Not because it's a better or worse default, but because making a behavioural 
change in released public API would retroactively break any few places where we 
didn't want to word wrap.
  
  No code adds
  
  > setFoo(theDocumentedDefaultValue)

REPOSITORY
  R119 Plasma Desktop

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

To: develoot, #vdg, #plasma, #frameworks, davidedmundson
Cc: davidedmundson, ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28200: Enable wrapping of error messages which use KMessageWidget

[Nathaniel Graham]

ngraham added a comment.


  In D28200#632622 , @davidedmundson 
wrote:
  
  > > I wonder if it makes sense to set this on the widget itself, as a 
sensible default.
  >
  > No.
  >
  > Not because it's a better or worse default, but because making a 
behavioural change in released public API would retroactively break any few 
places where we didn't want to word wrap.
  >
  > No code adds
  >
  > > setFoo(theDocumentedDefaultValue)
  
  
  Gotcha. Would that be something we can revisit for KF6?

REPOSITORY
  R119 Plasma Desktop

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

To: develoot, #vdg, #plasma, #frameworks, davidedmundson
Cc: davidedmundson, ngraham, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D28194: [WIP] Fix loading button icons from qrc

[Aleix Pol Gonzalez]

apol added a comment.


  Fixing QIcon would make sense but I'd say getting this in is not the worst 
thing either.

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

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

To: nicolasfella, #plasma, mart
Cc: apol, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, ahiemstra, mart

D27098: Bugfix: Konsole does not launch, optimize and simplify runner

[Aleix Pol Gonzalez]

apol added a comment.


  If you ask me, this patch does many things:
  
  - fixes an issue
  - changes coding style
  - does some code bits a bit more differently.
  
  It's hard to review for me, I hope someone else more familiar with the 
codebase can.

INLINE COMMENTS

> konsoleprofiles.cpp:155
> -
> -if (profileData.displayName.compare(term, 
> Qt::CaseInsensitive) == 0) {
> -match.setRelevance(1.0);

Why has the relevance code been removed?

REPOSITORY
  R114 Plasma Addons

BRANCH
  konsole_bugfix (branched from master)

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

To: alex, davidedmundson, ngraham, #plasma, #konsole, tcanabrava, hindenburg
Cc: apol, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, ahiemstra, mart

D28066: Remove the STATIC_LIBRARY option to fix static builds

[Charles Barto]

bartoc updated this revision to Diff 78262.
bartoc added a comment.


  Made setting STATIC_LIBRARY a fatal error.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28066?vs=77694&id=78262

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

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt

To: bartoc, #kirigami
Cc: apol, plasma-devel, fbampaloukas, GB_2, domson, dkardarakos, ngraham, 
ahiemstra, davidedmundson, mart

D28167: packagekit: Fix checking of APT::Periodic::Update-Package-Lists

[Aleix Pol Gonzalez]

apol added a comment.


  Do you want me to land the change?

REPOSITORY
  R134 Discover Software Store

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

To: eliac, #discover_software_store, apol, ngraham
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, semareit, 
jraleigh, zachus, fbampaloukas, GB_2, ragreen, ixoos, ZrenBot, James, ngraham, 
alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, 
apol, ahiemstra, mart

D28211: [applets/systemtray] Make Pin button a bit larger

[Nathaniel Graham]

ngraham created this revision.
ngraham added reviewers: VDG, Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
ngraham requested review of this revision.

REVISION SUMMARY
  The Pin button in the System Tray expanded view is very small. This has 
always felt
  slightly odd to me, and the recent change to add a defined header area makes 
it even odderin my opinion, as the icon is now much smaller than the area it 
visibly inhabits. This
  patch makes it into a standard sized toolbutton, which I think looks better 
and more
  visually balanced.

TEST PLAN
  Before: F8194101: Before.png 
  After: F8194100: After.png 

REPOSITORY
  R120 Plasma Workspace

BRANCH
  normal-sized-pin-button (branched from master)

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

AFFECTED FILES
  applets/systemtray/package/contents/ui/ExpandedRepresentation.qml

To: ngraham, #vdg, #plasma
Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, 
fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart

D27098: Bugfix: Konsole does not launch, optimize and simplify runner

[Alexander Lohnau]

alex added inline comments.

INLINE COMMENTS

> apol wrote in konsoleprofiles.cpp:155
> Why has the relevance code been removed?

It has been refactored and is now in line 132/188:
`match.setRelevance((float) term.length() / (float) data.displayName.length());`

REPOSITORY
  R114 Plasma Addons

BRANCH
  konsole_bugfix (branched from master)

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

To: alex, davidedmundson, ngraham, #plasma, #konsole, tcanabrava, hindenburg
Cc: apol, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, 
zachus, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, ahiemstra, mart