D6628: Fix and normalize license in .desktop files

[Matthias Klumpp]

mak added a comment.


  In D6628#676722 , @bam wrote:
  
  > Thanks for clarifying.
  >
  > In D6628#676721 , @mak wrote:
  >
  > > So, this change looks fine to me now, as it is :-)
  >
  >
  > And yet it was changed again! :-D
  >  
https://github.com/KDE/plasma-desktop/commit/05c230733a1b9d16c0e52eb54955c62d340b94e3
  
  
  :-D - *That* change also looks good, and apparently it doesn't break 
anything. The "GPL-2.0+"-style identifiers are encouraged by AppStream as much 
as "GPL-2.0-or-later", but "GPLv2.0+" is considered legacy. Its curious that AS 
would even validate this stuff though, as it doesn't look into desktop-entry 
files (but maybe some auto-generation is at play here).

REPOSITORY
  R119 Plasma Desktop

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

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

D6628: Fix and normalize license in .desktop files

[Matthias Klumpp]

mak added a comment.


  In D6628#676720 , @sitter wrote:
  
  > These aren't SPDX identifiers but kaboutlicense keywords 
https://api.kde.org/frameworks/kcoreaddons/html/kaboutdata_8cpp_source.html#l00397
  
  
  Makes sense.
  @bam As far as the "legacy syntax" is concerned: SPDX broke their conventions 
multiple times, so on the AppStream side I really got sick of these breaking 
changes and any syntax is fine. On the KDE side, switching the kaboutlicense 
keywords to SPDX is probably a bigger endeavour, and may not actually be worth 
the effort (I would guess that there may be some break risk here). So, this 
change looks fine to me now, as it is :-)

REPOSITORY
  R119 Plasma Desktop

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

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

D25100: Mark all wallpaper plugins as addons

[Matthias Klumpp]

mak added a comment.


  Did this have AppStream metadata before? Probably the distribution data still 
lists this as component, while the new file lists it as addon. The distro data 
is preferred, so that's why this shows up as app. You need your distro to ship 
this as update, or set `PreferLocalMetainfoData=true` in  `/etc/appstream.conf` 
(that should override the data).
  The output of `appstreamcli dump org.kde.haenau` is also always helpful to 
investigate issues like this. The component is incorrectly marked as "generic 
component" instead of "addon" (although I would argue that Discover should hide 
generic components as well, as those may be things like shared libraries and 
developer tools as well).

REPOSITORY
  R114 Plasma Addons

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

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

D23328: Exclude other desktop file from AppStream metadata generation

[Matthias Klumpp]

mak added a comment.


  I didn't test this, but I wrote the code which will handle this and it works 
in other cases ;-)
  My comment was to confirm that the commit does indeed what you intend it to 
do, according to the spec and code.

REPOSITORY
  R124 System Settings

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

To: ngraham, kossebau, apol, mak
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23328: Exclude other desktop file from AppStream metadata generation

[Matthias Klumpp]

mak added a comment.


  Effect is `kdesystemsettings.desktop` not being shown in any software center.
  LGTM

REPOSITORY
  R124 System Settings

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

To: ngraham, kossebau, apol, mak
Cc: plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, 
ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Matthias Klumpp]

mak added a comment.


  In D23306#515666 , @kossebau wrote:
  
  > In D23306#515662 , @mak wrote:
  >
  > > In D23306#515616 , @kossebau 
wrote:
  > >
  > > > Thanks! Though reading it, leaves open questions with me:
  > > >
  > > > - what is meant by "referenced"? only via ?
  > >
  > >
  > > In modern metainfo files yes, only via `launchable`. However, if a 
component `id` has a .desktop suffix, as was required in the past, and a 
matching .desktop file is found, that also counts as referenced and the 
desktop-entry file will be read.
  >
  >
  > As developer trying to write metainfo files, I would welcome this logic 
also documented n the docs. The current content of the docs is confusing to me 
at least.
  >
  > >> - if there are two desktop files referenced by  where one 
has the ignore entry set, will this overrule the "Data will only be fetched 
from a desktop file if one  tag is present" rules above?
  > > 
  > > No. A `launchable` tag always beats whatever was defined in the 
desktop-entry file itself, so if there is one launchable tag, the .desktop 
entry file will be taken into consideration no matter what was defined in it 
(to e.g. merge in category information). Any equivalent data in the metainfo 
file beats that of the desktop-entry file though. If there are multiple 
`launchable` entries, the generator has no idea which .desktop file to read, so 
rather than reading any and getting information wrong, it will read none 
(requiring the metainfo author to add all data they want in there explicitly).
  > >  This could maybe be made smarter, but tbh this case is so rare that just 
making the metainfo files more complete in such events seems like the better 
approach.
  >
  > So, in our case here, `systemsettings.desktop` actually means there is 
no need to add `X-AppStream-Ignore=true` to "kdesystemsettings.desktop" ? 
Because the generators would ignore it already due to a `` present 
and pointing to the other desktop file?
  
  
  No, you need `X-AppStream-Ignore=true` in `kdesystemsettings.desktop`, 
because since the desktop filename is different, the AppStream generator will 
see those as different applications and create entries for both. You however do 
not need to add the AppStream-ignore field to the `systemsettings.desktop` 
file, as that one is referenced from the metainfo file and therefore the 
metadata generator will know that the two files belong together and describe 
just one application. (if there was another launchable entry for 
`kdesystemsettings.desktop`, that would also be the case, but it would break 
the "Launch" dialog in software centers, so having one .desktop file ignored is 
the way to go)

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Matthias Klumpp]

mak added a comment.


  In D23306#515616 , @kossebau wrote:
  
  > In D23306#515609 , @mak wrote:
  >
  > > @kossebau How to hide .desktop files from AppStream is now more visible 
in 
https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html#spec-appdata-introduction
 as a hint.
  >
  >
  > Thanks! Though reading it, leaves open questions with me:
  >
  > - what is meant by "referenced"? only via ?
  
  
  In modern metainfo files yes, only via `launchable`. However, if a component 
`id` has a .desktop suffix, as was required in the past, and a matching 
.desktop file is found, that also counts as referenced and the desktop-entry 
file will be read.
  
  > - if there are two desktop files referenced by  where one has 
the ignore entry set, will this overrule the "Data will only be fetched from a 
desktop file if one  tag is present" rules above?
  
  No. A `launchable` tag always beats whatever was defined in the desktop-entry 
file itself, so if there is one launchable tag, the .desktop entry file will be 
taken into consideration no matter what was defined in it (to e.g. merge in 
category information). Any equivalent data in the metainfo file beats that of 
the desktop-entry file though. If there are multiple `launchable` entries, the 
generator has no idea which .desktop file to read, so rather than reading any 
and getting information wrong, it will read none (requiring the metainfo author 
to add all data they want in there explicitly).
  This could maybe be made smarter, but tbh this case is so rare that just 
making the metainfo files more complete in such events seems like the better 
approach.
  
  In D23306#515621 , @ngraham wrote:
  
  > @mak The link 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-compulsory_for_desktop
 seems broken. I found a reference to `compulsory_for_desktop` at 
https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html, 
but it points to a nonexistent page.
  
  
  Hmm, it works fine here - maybe refresh the page? (the page was recently 
updated and your browser may still have an older, cached version)

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Matthias Klumpp]

mak added a comment.


  In D23306#515595 , @ngraham wrote:
  
  > In fact there are three possible relationships:
  >
  > - App is associated with desktop, but not required by it or limited to it 
(e.g. Dolphin, Gwenview, Nautilus, GNOME Music)
  
  
  --> `project_group` 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_group
  
  > - App requires desktop (e.g. KDE System Settings, GNOME System Settings, 
GNOME Tweaks)
  
  --> `compulsory_for_desktop` 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-compulsory_for_desktop
  (Also potentially `extends`, if the thing in question is an addon / 
desktop-shell extension)
  
  > - Desktop requires app (e.g. KDE System Settings, GNOME System Settings)
  
  --> `compulsory_for_desktop` 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-compulsory_for_desktop
  
  > If we had the ability to mark things according to the above relationships 
that would be amazing.
  
  We actually can, I think...
  
  @kossebau How to hide .desktop files from AppStream is now more visible in 
https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html#spec-appdata-introduction
 as a hint.

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Matthias Klumpp]

mak added a comment.


  In D23306#515592 , @ngraham wrote:
  
  > In D23306#515589 , @mak wrote:
  >
  > > In D23306#515577 , @ngraham 
wrote:
  > >
  > > > Adjust according to review comments
  > >
  > >
  > > This will work. I would change `System Settings` to ` 
KDE System Settings` or `Plasma System Settings`, just like 
GNOME sets a name like "GNOME Videos" instead of "Videos" in their metadata. 
Otherwise this name will confuse users of GNOME, I guess.
  >
  >
  > This gets at the original reason why System Settings has two .desktop 
files: one adds "KDE" onto the beginning of the name when it's not run in 
Plasma. Ideally we would want the same thing in AppStream:
  >
  > - Show "KDE Plasma System Settings" in search and browse lists, where the 
fact that it's for KDE Plasma is otherwise not apparent
  > - Show "System Settings" in Discover's Updates lists, where the fact that 
it's for KDE Plasma is implied and redundant because you're seeing it in 
Plasma's software updater
  >
  >   Is such a thing possible?
  
  
  Not at the moment... Discover can use the compulsory information to group the 
components into a "System components" group and it could also use the AppStream 
ID to arbitrarily override component names.
  The AppStream metainfo data is intended to be completely desktop agnostic and 
reliably the same on every software center, that's why we don't allow apps to 
change names depending on which software center they are in.
  However, software centers may use the compulsory information to actually 
completely hide components from foreign desktops, so not having a KDE prefix 
may not even be necessary. I am not sure if GNOME Software actually hides the 
apps based on the compulsory information (as this may also cause problems, e.g. 
I would consider Dolphin to be compulsory for Plasma, but GNOME people may 
potentially also want to install that file manager, so hiding it in GNOME 
Software may actually be wrong here).

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Matthias Klumpp]

mak added a comment.


  Adding a `project_group` may also be a nice idea: 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_group

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Matthias Klumpp]

mak added a comment.


  In D23306#515585 , @kossebau wrote:
  
  > @mak: tnanks for the hint. will also see to use X-AppStream-Ignore for 
kdevelop then. any chance we can see this trick documented on 
https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html
 , please? :)
  
  
  There should probably be another note block on that page... ;-)

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Matthias Klumpp]

mak added a comment.


  In D23306#515577 , @ngraham wrote:
  
  > Adjust according to review comments
  
  
  This will work. I would change `System Settings` to ` KDE 
System Settings` or `Plasma System Settings`, just like 
GNOME sets a name like "GNOME Videos" instead of "Videos" in their metadata. 
Otherwise this name will confuse users of GNOME, I guess.
  You'll also highly likely want to set `compulsory_for_desktop` ( 
https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html#tag-ct-compulsory_for_desktop
 ) to prevent this app to be removable on Plasma.
  So adding
  
KDE
Plasma
  
  will do the trick (AppStream recognizes "Plasma", but the desktop is actually 
known as "KDE" everywhere in Freedesktop, so just using "KDE" would probably be 
sufficient and compatible with everything. Having "Plasma" as well won't hurt 
though)
  Ypu may want FSFAP  as 
`metadata_license` as it's much shorter than CC0 and mixes well with GPL. 
However that's a personal choice and not required for anything. CC0 would work 
just fine.

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, mak, #plasma
Cc: kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23302: Stop installing two desktop files

[Matthias Klumpp]

mak added a comment.


  @kossebau You'll also want to annotate the .desktop files correctly to hide 
them. See https://phabricator.kde.org/D23306#515575 for details.

REPOSITORY
  R124 System Settings

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

To: ngraham, apol, #plasma
Cc: mak, kossebau, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D23306: Add AppStream metadata file

[Matthias Klumpp]

mak added a comment.


  There's also a FAQ entry for this, apparently I only documented this for 
Debian Developers back in the day ^^
  
  > 
https://wiki.debian.org/AppStream/Guidelines#How_to_exclude_.desktop_files_from_the_metadata
  
==
  
  We may actually be at a point where we could only process stuff that has 
metainfo files by default in appstream-generator now... Something to consider 
for future releases.

REPOSITORY
  R124 System Settings

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

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

D23306: Add AppStream metadata file

[Matthias Klumpp]

mak added a comment.


  @ngraham
  
  > Alternative to D23302 . According to 
the AppStream documentation 
(https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html),
  >  adding an AppStream metadata file with multiple launchable tags will 
prevent AppStream
  >  info generators from parsing desktop files to determine metadata,
  
  I don't think this will do what you intend. What will actually happen here is 
that an AppStream generator will not *merge* in data from any of the desktop 
files into the final metadata collection, only being limited to what is in the 
.desktop file. Having the two `launchable` tags though will make software 
centers ask the user which app they want to launch if they click on the 
"Launch" button in a software center, which in this case are both identical.
  
  If you just want to hide a .desktop file from being processed by AppStream, 
there is a much simpler solution: Just add `X-AppStream-Ignore=true` to the 
.desktop file in question, and it will be hidden (unless it is referenced in a 
metainfo file of course, in which case it may still be used as data source for 
that metainfo file).

REPOSITORY
  R124 System Settings

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

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

Re: freedesktop.org meeting again?

[Matthias Klumpp]

Am Mo., 11. Feb. 2019 um 00:06 Uhr schrieb Aleix Pol :
>
> On Sat, Feb 9, 2019 at 1:32 PM David Faure  wrote:
>>
>> Is anyone interested in participating in a technical meeting with other
>> desktop environments?
>>
>> I did that years ago and this is how we came up with various shared
>> specifications, but at this point it might be more useful for people working
>> on other things to attend.

Oh, nice that this is happening again!
I would be very interested in attending, but I am already working on
cross-desktop stuff and less on "pure" KDE projects (so as a KDE
delegate I might not be the best choice).
Cheers,
Matthias


>> --  Forwarded Message  --
>>
>> Subject: freedesktop.org meeting again?
>> Date: mercredi 6 février 2019, 15:27:32 CET
>> From: Agustin Benito Bethencourt 
>> To: Lennart Poettering , David Faure ,
>> de...@desrt.ca
>>
>> Dear Allison, David and Lennart,
>>
>> this mail has as a goal to evaluate the interest you would have in meeting
>> again like you guys did in 2013 and 2014 in Nuremberg, Germany, hosted again
>> by SUSE, this time  during the openSUSE Conference[1], that will take place
>> from May 24th to May 26th.
>>
>> If the dates, location matches your availability and there is interest in
>> having this working sessions, I would be happy to coordinate the logistics 
>> and
>> invite those who you think it should be present.. SUSE and openSUSE
>> representatives are very interested in hosting this activity once again.
>>
>> What do you think? Who else should be at the event?
>>
>> [1] https://events.opensuse.org/conference/oSC19
>>
>
> It could be an interesting event to have indeed. Maybe it would make sense to 
> piggy-back on something more on-topic like XDC or LAS?
> Or is SUSE especially interested?
>
> Aleix



-- 
I welcome VSRE emails. See http://vsre.info/

D13772: Add AppStream metadata

[Matthias Klumpp]

mak added a comment.


  In D13772#284459 , @ngraham wrote:
  
  > FWIW, @mak, `appstrealcli validate` doesn't like my launchable tag, though 
I can't see anything wrong with it.
  >
  >   dev@dev-pc:~/repos/ksysguard$  (appstream-metadata) appstreamcli validate 
gui/org.kde.ksysguard.appdata.xml
  >   W - org.kde.ksysguard.appdata.xml:org.kde.ksysguard:7
  >   Found invalid tag: 'launchable'. Non-standard tags must be prefixed 
with "x-".
  >  
  >   Validation failed: warnings: 1
  >
  
  
  You have an old version of AppStream, as it looks like - ideally always 
update it to the most recent version (0.12.1 currently).

REPOSITORY
  R106 KSysguard

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

To: ngraham, #plasma, apol, mak, pino
Cc: pino, mak, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13772: Add AppStream metadata

[Matthias Klumpp]

mak requested changes to this revision.
mak added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> org.kde.ksysguard.appdata.xml:2
> +
> +
> +  KSysGuard

Nitpick: Use `desktop-application`

> org.kde.ksysguard.appdata.xml:7
> +  org.kde.ksysguard
> +  CC0-1.0
> +  GPL-2.0+

Maybe using `FSFAP` as license is better here, so the sources don't have to 
ship a copy of the CC0 license.

> org.kde.ksysguard.appdata.xml:18
> +
> +   type="source">https://www.kde.org/images/screenshots/ksysguard.png
> +   type="thumbnail">https://www.kde.org/images/screenshots/resized/ksysguard.png

Thumbnails are generally thrown away be the metadata extractor on the Linux 
distro side, so you can really drop the "type" property of the image tag here 
and just add the source image.

> org.kde.ksysguard.appdata.xml:28
> +  
> +

The component is missing a `launchable` tag: 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-launchable
The categories and mimetypes lists can be dropped, as those will be 
automatically extracted from the desktop-file mentioned in the launchable tag 
(if they are not dropped, the metainfo file will *override* the desktop file 
contents, which is likely not the desired behavior here)

REPOSITORY
  R106 KSysguard

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

To: ngraham, #plasma, apol, mak
Cc: mak, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13123: Make .deb and .rpm mime type handling optional at build time

[Matthias Klumpp]

mak added a comment.


  Checking for the dpkg and rpm binaries isn't really foolproof, because you 
can install rpm on Debian and dpkg on Fedora & Co. easily.
  The only issue proof thing that I can imagine would be checking for the 
distribution name in /etc/os-release, or maybe checking for the presence of 
/etc/debian_version.

REPOSITORY
  R134 Discover Software Store

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

To: arojas, apol
Cc: mak, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

Re: Translations and appstream summaries

[Matthias Klumpp]

2017-12-14 23:40 GMT+01:00 David Edmundson :
> Translators,
>
> We're getting a bunch of tests failing [1] because of a translation issue.

I wonder if that's true - appstreamcli will only return a non-zero
exist status if you have warnings or errors, the added dot is just an
info-type validation message (it's a cosmetic thing, not a functional
issue).
>From the link, "Found empty 'project_license' tag" and "The component
is missing a summary ( tag)." seem to kill validation.

That being said, resolving the translation issues would be really
really nice! :-)

Cheers,
Matthias

Re: Missing mouse pointer in KWin on Wayland with Etnaviv

[Matthias Klumpp]

2017-10-31 10:22 GMT+01:00 Martin Flöser <mgraess...@kde.org>:
> Am 2017-10-31 02:56, schrieb Matthias Klumpp:
>>
>> Hello!
>> For a phone we obviously don't need a mouse pointer, but at the moment
>> I can only interact with the UI by clicking blindly, which is not
>> ideal for testing. So, do you have an idea on what might be wrong
>> here?
>
> I have ideas...
>
> First of all: the mouse cursor is only shown if a mouse is connected. I
> assume that you connected one ;-)

Yes, I have only one USB port on the board, but decided to buy a small
remote keyboard-touchpad brick now, and that does the job well (prior
to that I was swapping mouse and keyboard).

> The more likely explanation is that etnaviv doesn't have a mouse cursor
> layer, which would make sense as it's a mobile chip set. KWin uses the
> hardware cursor layer in the drm platform, so if it does not exist it won't
> work.

This makes complete sense. I didn't know that there was such as thing
as a mouse cursor layer (why would the cursor be special?). When
running Weston, I do get a cursor though, so I guess it's using some
kind of emulation.

> Whether that's the case is something which can only be tested with the
> hardware (e.g. adding a break point and seeing where KWin goes). If that's
> the case we can easily fix it by using the sofware rendered cursor. IIRC
> that is only available in 5.11, though.

Neat!

> Another possibility is that there is no mouse cursor theme configured. I'm
> not sure how much magic happens in startkde which is not executed on Plasma
> mobile. That should be easy to test, just export XCURSOR_THEME to something
> sensible (e.g. breeze_cursors).

I'd need to look into taht, but I am pretty sure a cursor is set properly.

2017-10-31 10:42 GMT+01:00 Martin Flöser <mgraess...@kde.org>:
> Am 2017-10-31 02:56, schrieb Matthias Klumpp:
>>
>> For a phone we obviously don't need a mouse pointer, but at the moment
>> I can only interact with the UI by clicking blindly,
>
> If you have a keyboard connected you can use the Mouse Mark effect: Just
> press and hold control+meta and you get two rotating circles around the
> center of the mouse cursor.

Hah! That did the trick easily, after enabling the effect in KWin's
configuration - I didn't think of this before (probably because I
didn't have that hybrid keyboard yet). Finally I can navigate the UI
more precisely :-)
Performance isn't great at all at the moment (and stability also
isn't, it crashes as soon as I try to pull down the top drawer), but
aside from these things which are actually minor issues, the whole UI
looks fairly complete and pretty nice.

I do hope we'll go with the i.mx8 chip eventually, to give us some
headroom for performance.

Thank you for your help!

Cheers,
Matthias

Missing mouse pointer in KWin on Wayland with Etnaviv

[Matthias Klumpp]

Hello!

The past weekend I made Plasma Mobile work on our preliminary
"devboard" for the Purism Librem 5 phone (which at the moment is not
much more than a i.mx6 CPU with peripherals/a screen - it will be much
more exciting soon).

The system is running Debian Testing (Buster) with KDE libraries found
there (Plasma 5.10.5 (KWin 5.10.5), KF 5.37.0, ...) and Plasma Mobile
Git master. With some fiddling and Bhushan's help I got it to work.
The only real obstacle was Debian's really outdated version of
libepoxy, which made KWin not detect the OpenGL ES features (to be
fixed soonish in Debian).
Also, did you know that you get screen artifacts and "stripes" as soon
as you run kwin_wayland as root and not as regular user? ;-)

Anyway, the only real issue is panels vanishing in the mobile shell
(apparently a known issue and soon resolved) and KWin not showing any
mouse pointer (as well as - to be expected - performance currently).

For a phone we obviously don't need a mouse pointer, but at the moment
I can only interact with the UI by clicking blindly, which is not
ideal for testing. So, do you have an idea on what might be wrong
here?
(The logs I know of don't show anything related to this issue). If
this is a real bug and not a configuration mistake, I'll file a bug.

Anyway, there will be a blogpost about this soon, with pretty pictures
I hope ;-)

I also think we should get Plasma Mobile into Debian as soon as
possible. For that we'd (ideally) need a release tarball. I talked to
Bhushan about this, and he is preparing something.

Cheers,
Matthias

Re: Videoconference between KDE community and Purism regarding Librem5

[Matthias Klumpp]

Just to make sure this message gets through to all the mailinglists (I
dropped some of the CCs, because the list was rejecting this, and I
also don't know if Zlatan is subscribed to plasma-devel & co.), since
some people didn't get the next yet apparently

This is our meeting place:

2017-09-07 16:32 GMT+02:00 Zlatan Todoric :
> [...]
> I suggest Jitsi as well and I suggest just the name KDEPurismMeeting so:
> https://meet.jit.si/KDEPurismMeeting

Re: Videoconference between KDE community and Purism regarding Librem5

[Matthias Klumpp]

> Sebastian Kügler wrote :
> let's pin down Thursday, 19:00 CEST (9.00am PDT), in any case.

For me, this would work even better :-)
(But we need Todd in the meeting, so let's wait and hope he's
available at that time as well)

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Matthias Klumpp]

2017-09-05 12:10 GMT+02:00 Jonathan Riddell <j...@jriddell.org>:
> On Mon, Sep 04, 2017 at 10:56:12PM +0200, Matthias Klumpp wrote:
>> > And honestly I don't think it's something the Debian team cares about: it's
>> > much more important to have the "perfect" package.
>>
>> Yes, that is required for getting things into the distribution. The
>> copyright analysis must be done and be good to even get into Debian,
>> which is something Neon was lacking last time I checked.
>
> There's nobody much watching over neon's copyright analysis so I often
> don't spend much time writing long copyright files. It's more
> important to me that the code KDE releases has clear and valid
> licences and I frequently make changes in KDE directly when it doesn't,
> as well as ensuring KDE projects actually make releases so they can
> get picked up by distros and that those releases follow a licence
> policy and best release practice plus defining those policies and best
> practice.

That makes complete sense for a project like Neon, which is
KDE-centric and wants to ship new version of KDEs software as soon as
possible.
Debian has a different focus there and treats all upstreams equal, in
equally not blindly trusting their license claims. That's why
copyright reviews are made and documented in d/copyright. Of course,
that's a pointless excercise if you *are* the upstream project :D

>> The Kubuntu
>> packaging oftentimes was mediocre too (bumping epochs without reason
>> comes to my mind, even for new packages) - *but* that is no reason to
>> take the Neon packaging, fix the problems and submit the changes back
>> to Neon and the package to Debian. That workflow would actually help
>> both projects and reduce work for Debian.
>
> I'm a bit lost here. epochs are typically set to keep package sets
> consistent with each other, you can blame stephan coolo for packaging
> KDE in debian in the 1990s. I'd love to have more sharing between
> kubuntu, neon and Debian. The neon packaging automatically merges in
> debian packaging for frameworks and makes it easy for everything else
> so I merge whenever there's a benefit.

I was specifically thinking about e.g. Muon getting an epoch although
it was a completely new package, etc. It's not really an obstacle for
collaboration though.

>> That got me curious, and I diff'ed the Neon vs. Debian packaging.
>> Surprisingly, the packaging is completely disjoint. Sometimes, Debian
>> is better, sometimes Neon is. And it looks like Neon does take care of
>> the copyright file afterall, in some packages it is even *better* than
>> in Debian.
>
> Why thank you, I think :)

>From just very briefly looking at the things, the Neon packaging is
often times better/more complete. I did not expect Neon to have a
better d/copyright file, so that was very surprising :-D

> We like to automate things in neon so the automated QA tools will moan
> about some thing which get fixed. It would be great if Debian and/or
> kubuntu would merge these back but I suspect it doesn't happen much.
>
> Stuff gets packaged on different schedules of course so updates happen at 
> different times.

Right - with Neon being faster, adopting changes in Debian would make
a lot of sense though, instead of duplicating effort.

>> Also, fun bits happen, for example Debian updated your copyright in
>> the kwin package, Neon forgot to do that, but instead added other
>> copyright holders Debian missed. Also, Neon adds
>> "KF5IdleTimeKWinWaylandPrivatePlugin.so" to the kwin-common package,
>> while in Debian it's in kwin-wayland (where it belongs, I guess?).
>> Debian also builds proper debugsymbols using the dbgsym support in
>> Debian, while Neon is using legacy stuff.
>
> Thanks for your bug reports, we also accept patches or bugs on
> bugs.kde.org or KDE devs can commit directly :)

Hehe ^^ - I think I'll fix that one directly then :-)

>> [...]
>> Anyway, this is something PureOS and Purism could actually resolve or
>> help resolving (in the ideal case directly on Debian, in the worst
>> case only for PureOS).
>
> Doing merges between neon/kubuntu/debian would be super awesome

I would love that! I am a member of the Debian KDE team, but the
majority of packaging work is not done by me, so I don't have that
much of a say about anything. But I could probably bring that up. The
primary person of contact about Debian KDE stuff would be maxy, I
think.
I think one of the best ways for collaboration would be merging the
Neon packaging autmatically into a branch of the corresponding Debian
packaging, so Debian can pick changes from there and ideally also send
patches back. Kubuntu was using a similar approach, but that was
stopped, so fig

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Matthias Klumpp]

2017-09-04 22:29 GMT+02:00 Martin Flöser :
> Am 2017-09-04 19:51, schrieb Zlatan Todoric:
>>
>> I had pretty unstable experience with KDE in Debian, so I assume that
>> KDE community will improve that in future (we need more Debian KDE
>> maintainers!) ;)
>
> Personal opinion as a long time Debian testing user (~10 years) and KDE
> contributor following:
>
> The packaging of Debian is really not great and questionable. As an example:
> currently testing ships Qt 5.9 in combination with KWin 5.8. KWin 5.8 does
> not compile against Qt 5.9, patches exist in master and I refused to
> backport them to the 5.8 branch as that is untested. Debian shipped that
> without even consulting with upstream developers. I think that is extremely
> bad practice from a distribution. They know me, they know they could ask for
> my opinion.

That is definitely a problem. It could be that the team is overworked
though (I don't know enough here). In any case, a good relation with
upstream is key for any package maintainer, it looks like there is
definitely something lacking here.

> The task-kde does a really bad default package selection. As an example: it
> installs Konqueror as the default browser in the favorites section of the
> launcher while at the same time warning against QtWebKit based browsers in
> the release announcement.

Agreed! The KDE task interestingly isn't maintained by the KDE team
though, and last time I asked that there was no influence on it. I
doubt that. Sending a patch would definitely be accepted by the task
maintainers.
When we made Tanglu, people were amazed how well the distro was
working, and how quickly. When I looked into that, it turned out that
the more lightweight package selection was the biggest cause for that
perception.

> [...]
> And honestly I don't think it's something the Debian team cares about: it's
> much more important to have the "perfect" package.

Yes, that is required for getting things into the distribution. The
copyright analysis must be done and be good to even get into Debian,
which is something Neon was lacking last time I checked. The Kubuntu
packaging oftentimes was mediocre too (bumping epochs without reason
comes to my mind, even for new packages) - *but* that is no reason to
take the Neon packaging, fix the problems and submit the changes back
to Neon and the package to Debian. That workflow would actually help
both projects and reduce work for Debian.
But I think this is getting into a highly political area, and I don't
feel qualified to comment about why things are the way they are or
what has been tried in the past.

> After all they constantly
> re-invent the wheel instead of using the already packaged software by
> Kubuntu or KDE Neon (hopefully that improved, but looking at the recent
> commits it doesn't look like it:
> https://anonscm.debian.org/git/pkg-kde/plasma/kwin.git/commit/?id=1cf72f55228a59fb37649c8f8a29cc509a8881b1
> ).

That got me curious, and I diff'ed the Neon vs. Debian packaging.
Surprisingly, the packaging is completely disjoint. Sometimes, Debian
is better, sometimes Neon is. And it looks like Neon does take care of
the copyright file afterall, in some packages it is even *better* than
in Debian.
Also, fun bits happen, for example Debian updated your copyright in
the kwin package, Neon forgot to do that, but instead added other
copyright holders Debian missed. Also, Neon adds
"KF5IdleTimeKWinWaylandPrivatePlugin.so" to the kwin-common package,
while in Debian it's in kwin-wayland (where it belongs, I guess?).
Debian also builds proper debugsymbols using the dbgsym support in
Debian, while Neon is using legacy stuff.

> Just my 2 cents as someone who has been annoyed by the lack of collaboration
> between Kubuntu and Debian for years

>From briefly looking over it, I have to agree - this is not only slightly 
>mad...
I know at some point, Kubuntu packaging was in Debian Git, but then it
was abandoned (I think someone in Debian complained, but I am not
certain).

Anyway, this is something PureOS and Purism could actually resolve or
help resolving (in the ideal case directly on Debian, in the worst
case only for PureOS).

Cheers,
Matthias

Re: Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Matthias Klumpp]

2017-09-04 19:51 GMT+02:00 Zlatan Todoric :
> [...]
> Well, for having both as separate offer (if GNOME hits the pace), is not
> an issue. I am wondering if having both at the same time on phone will
> end up being to much (how many libraries are there that one uses and
> other DE doesn't), also depending on disk space, you don't want to eat
> like 20% of all space for base OS.

Just commenting on that point: I think having two DEs on a phone with
some kind of "desktop switcher" is a terrible idea. I think it would
be much more maintainable if we spin two separate base images, and in
case someone wants something different they can just swap those (we
will offer those images on our website anyway).

Giving users the choice to switch between desktops randomly when using
the phone is a bad thing usability wise (it's not a simple thing, and
radically changes the appearance of the UI), requires additional
engineering effort and is generally harder to maintain and support
(because we will have multiple configurations and mix of technology on
one image).
Shipping the phone with one default image and offering others on our
site that people can put on their phone seems to be a much better idea
to me.

> I had pretty unstable experience with KDE in Debian, so I assume that
> KDE community will improve that in future (we need more Debian KDE
> maintainers!) ;)

When exactly was that? ;-) But yeah, the Debian KDE team would be
happy for any additional help.

> [...]

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-09-03 23:17 GMT+02:00 Sebastian Kügler :
> Hey Zlatan,
> [...]
>> so I had discussion with our CEO and he is of course absolutely in.
>> To make clear our standpoint - both GNOME and KDE *will* be first
>> class citizen on Librem5. So there is no favorite between two, but
>> both are equal in this challenge.
>>
>> That said, looking in general code readiness between two, it would
>> appear that plasma mobile would be default in first wave of librems
>> (we are not releasing until one DE is ready for it and we will also
>> not wait for other DE to be ready but gradually add it). There is
>> some discussion in terms of offer - do we want to offer Librem5 with
>> choice of having Plasma or GNOME or do we have both right away inside
>> (maybe to heavy for such device)  so users can pick during boot-up?
>
> I'm not familiar with GNOME's strategy for a mobile UI (would love to
> know more however!), so for me it's hard to judge whether Plasma is
> technologically closer. From the Plasma side, I know that we're
> *currently* not good enough for anything end-user, so it will need a
> dedicated development push, and we need to rally the resources
> necessary for that.

Plasma is much further developed than GNOME though on the mobile front
- GNOME at the moment would require a vendor to commit to making GNOME
Mobile, which is a rather large task involving changes in all parts of
the GNOME platform. Plasma Mobile on the other hand has the groundwork
done already.

> I do know that there is a good amount of interest
> in the community, but my impression is also that many people are
> playing a waiting game for others to move before they're getting their
> hands dirty. This is something we need to resolve to get the ball really
> rolling. A decent plan and coordination of these effort is definitely
> needed, and this is something we should come up with first. Build and
> they will come.

Indeed!

> [...]
>> Also, while currently we are offering PureOS with GNOME as default on
>> Librem13/15, I think there is future for KDE as desktop offering by
>> default as well (also as an option PureOS GNOME and PureOS Plasma/KDE)
>> because the convergence might be very interesting choice for many
>> users and your desktop is very modular for fine tweaking.
>
> I haven't looked into the packaging for the device, so it's hard to
> comment on that. I can imagine that Plasma is something people would
> want to run on the device, and it makes a story of complementary
> devices both running Plasma more compelling, so I think we should at
> least have an answer to that.
>
> That said, I'm not familiar with packaging for PureOS, and KDE is just
> getting ready to flatpak things.

Don't worry about that - PureOS is basically a combination of Debian
with things the FSF doesn't like stripped out, combined with some good
ideas from the Tanglu debian derivative. Anything that runs on Debian
runs on PureOS as well.

> I'm not sure in how far flatpacking
> the DE is an option, but I guess Matthias can weigh in here as well.

Flatpacking a DE is a bad idea. Flatpak is strictly for applications,
and does not work well (or at all, depending on the specifics) for
anything that's more than an app. For example, the desktop needs to
provide the portals implementation, fire up the user/session DBus on
startup, communicate with the display manager, and in general
integrate well with the rest of the OS. It also doesn't benefit much
from being sandboxed, since it launches applications that would
inherit the sandboxing policies of their parent, which can cause all
kind of problems.

For the phone base system, I envision a system similar to what
EndlessOS[1] currently is. This will require quite a bit of
redesigning of PureOS to work well with OSTree[2] and build OSTree
images automatically from packages, but will work much better on a
phone. Apps should be in Flatpaks, but that is also something I can
help with (although last time I looked at it, all work was done in KDE
already).
In any case, don't worry about the base OS and plumbing layer for now
:-) That will work well no matter which UX sits on top.

> We
> do have some expertise in the Plasma team as well, but so far the DE
> itself hasn't been the primary target of our flatpak efforts, we've
> more concentrated on apps.

Don't try flatpacking the DE, it won't be a good investment of time
(Ubuntu's Snappy system works differently here in that it allows
making snaps of pretty much anything, even system components - last
time I heard though that even Ubuntu would stick with .deb package for
longer though).
Flatpak is strictly for apps, and at the moment even more strictly for
apps that have a graphical user interface.

> [...]

Cheers,
Matthias

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-08-30 9:24 GMT+02:00 Bhushan Shah <bhus...@gmail.com>:
> Hello Matthias and all,
>
> First of all huge thanks for reaching to us!
>
> On Tue, Aug 29, 2017 at 03:28:36PM +0200, Matthias Klumpp wrote:
>> As some of you might already know, we at Purism are planning to
>> develop a mobile phone that uses only free software and Matrix[2] for
>> communication. We are currently running a crowdfunding campaign[1] in
>> order to be able to make the phone a reality.
>
> Best of luck for that campaign! I will reach out to KDE Promo people as
> well to help spread a word about this campaign.

That would be awesome! Thank you for considering this!

>> [...]
> I see no issues with this, in fact Plasma Mobile platform is designed
> with ability to switch underlying distribution in mind, we also have
> some experimental Arch Linux ARM based images in addition to normal
> Ubuntu ARM images. Basically following are the requirements for Plasma
> Mobile stack.
>
> - Logind/Consolekit
> - Libinput
> - Ofono, Telepathy (For calling functionalities)
> - Qt5 (5.7.1 minimum, 5.9 recommended)
> - Wayland
> - DRM/HWcomposer/Framebuffer for graphics
> - Login manager with wayland session support (SDDM for example)
>
> If any distribution provides those, it can work as a base for the Plasma
> Mobile.

That pretty much describes any modern Linux system, PureOS or even
stock Debian support this with ease.

>> The system will make full use of systemd and will use Bubblewrap[6]
>> for sandboxing of selected more critical components.
>
> This is interesting, We Plasma devevlopers haven't looked into
> Bubblewrap so far, but it would be useful from the initial glance at
> documentation it seems.

Bubblewrap is an amazing piece of software. It comes with a slight
performance penalty for startup, but gives you a well audited and
relatively easy to use sandboxing solution. Bubblewrap is used by
Flatpak to sandbox its applications, and a couple of other projects
make use of it as well.

>> Due to the nature of the hardware, we will not need libhybris or any
>> Android kernel abstraction, which means that we can run stock Linux on
>> the phone, which greatly simplifies development and will allow us to
>> develop at a faster pace, due to not being bound to a specific kernel
>> version.
>
> YAY! As Sebastian mentioned in his reply this is the dream for us and
> also lot of users.

Yes indeed :-) It's probably the thing I am most excited about myself :D

>> The downside is that the i.mx6 ARM CPU isn't incredibly fast. We hope
>> that we will be able to update to the faster i.mx8 when it is
>> available and can be used with free drivers, but at this point in time
>> we need to focus on the i.mx6 as primary hardware target.
> [...]
> Other bit I am unsure about is, mobile baseband. Tech specs on the
> campaign page mentions just "Separate mobile baseband" without any
> further details. Though assuming that mobile baseband is supported by
> ofono [2][3] Plasma Phone will work with it.

The problem here is that we need to find one which has working drivers
and open-sourced firmware, which will be a bit challenging. We haven't
settled on anything yet, that's why this item is unspecified on the
campaign page for now. In any case, whetever we come up with will need
to support OFono.

>
>> ## What we need from a phone UI
>>
>> Our scope for this project is limited, in order to be able to complete
>> it successfully and not end up in a never ending development loop: The
>> phone should be able to communicate via Matrix, have a web browser,
>> make calls, take pictures. We are not aiming for a massive amount of
>> apps, but instead want the basic functionalities of the phone working
>> well when we ship it - more apps and features can be delivered later
>> via Flatpaks and system updates.
>
> To meet the need of Librem, we have following,
>
> - A simple yet functional phone shell

Yay!

> - Web browser: we have QtWebengine based Angelfish browser for mobile

Interesting, I didn't know a dedicated browser existed. There is some
talk about using Firefox here, but I do not know any details on it
yet.
In any case, having a browser that is already optimized for mobile is great!

> - Calling: Dialer application and a simple contacts application which
>   supports vcard based storage, can be extended with KPeople[4]
>   framework. Actual calling functionality is handled through
>   telepathy-ofono[5] and telepathy-ofono-ril-mc-plugin[5] (part of same
>   sources as telepathy-ofono). However Librem 5 won't need the
>   ril-mc-plugin, given it won't be using Android based RILd.
>
> - Take Pictures: We have very simple camera application which uses

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-08-29 18:39 GMT+02:00 Martin Flöser <mgraess...@kde.org>:
> Am 2017-08-29 15:28, schrieb Matthias Klumpp:
>>
>> What we would be interested in is knowing about the future plans for
>> Plasma Mobile, especially in the area of design and performance
>> improvements. I didn't have the opportunity yet to test Plasma Mobile
>> on one of our development boards, but I hope I can get to that
>> soonish.
>
> Speaking for the KWin (Wayland compositor) part. Ideal would be drm support
> in the phone directly, but that is probably just wishful thinking.

The Vivante GPU on the i.mx6 is supported natively by the Linux
Etnaviv driver, which should make Wayland work instantly without too
many troubles (I would need to verify that though, maybe we need to do
a bit of kernel work to make the driver ready).

> KWin does
> have a working Android hwcomposer backend through libhybris. That works well
> and good for the limited use cases we had so far. The code base of this
> plugin is extremely small (< 1000 lines of code), which shows that most of
> the code is shared and it's relatively easy to extend and adjust this code
> base for new needs.
>
> Having done the initial port of KWin to the Nexus 5 I can proudly say that
> KWin performs very well on such kind of hardware. We benefit a lot from
> performance improvements done in the general KWin stack. And we can bring
> improvements from other platforms also to the phone stack. For example Roman
> did a lot of work to get layered compositing working in the DRM platform and
> that would be an ideal candidate to bring also in the hwcomposer plugin.
> Thus we have all the heavy lifting done to do things like rendering videos
> directly in a hardware plane.

Very nice :) I am fully convinced of the quality of the KWin
compositor, and I do not think we will run into troubles with it on
the Librem 5 hardware, as long as the Linux drivers work as expected
(as usual, there is a chance that we might need some fiddling to get
this to work properly).

> One of the things currently being worked on for the phone is to get rid of
> XWayland. This could give you a nice performance boost as you have a Wayland
> only system (of course it's also nice to have X support, but one cannot get
> it with GL support, so the gain is not worth it IMHO).

I am relatively sure that Zlatan (or CTO) would make pure Wayland a
pretty high priority ;-) Personally, I would not even bother with X on
the phone and just require everything running there to use Wayland. I
briefly thought that having X is useful for the convergence usecase
(if that becomes a reality), but even for that the apps need some
level of adjustment for a phone already, and in that case walking the
extra mile to get things to work with Wayland makes sense.

Cheers,
Matthias

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-08-29 16:44 GMT+02:00 Sebastian Kügler <se...@kde.org>:
> Hi Matthias, et al!
>
> On Tue, 29 Aug 2017 15:28:36 +0200
> Matthias Klumpp <matth...@tenstral.net> wrote:
>> [ Please keep the CC list intact for replies ]
>>
>> [...]
>
> Yes, Kirigami has been rather a success story, and we see more and more
> applications adopting it. That means that they will work much better
> also on mobile devices, such as phones. (It doesn't necessarily mean
> that they'll run and work entirely perfectly on a phone, but moves them
> from "this is clearly a desktop-focused UI into "small, fixable
> niggles".)

As usual with software :-)

>> ## Some details about the phone software
>>
>> The base operating system of the phone will be PureOS[3], our Debian
>> derivative that is currently pending endorsement from the FSF.
>> The plan is to use OSTree[4] for the base system, in order to achieve
>> atomic updates and easy rollbacks, as well as Flatpaks[5] for
>> deployment of applications. It is likely that we will have our own
>> Flatpak repository with apps specifically for the phone at some point
>> in the future.
>
> Great, this is a direction we've been pursuing as well, e.g. by adding
> support for Flatpak to discover, our package manager client (and KDE
> Store / OCS client). Discover uses Kirigami as well, by the way, so it
> works well on a smartphone already.

Yes, and Discover is a key component of the whole OS stack. There was
a talk by Jan at GUADEC about the state of Flatpak in KDE Discover,
and the status seemed to be "almost done". (I also tested this a while
back without problems).

>> The system will make full use of systemd and will use Bubblewrap[6]
>> for sandboxing of selected more critical components.
>
> Interesting, makes a lot of sense. I can't really comment from a Plasma
> point of view on this, it's something we need to try and if necessary,
> make work.

This is more of an OS-wide approach to isolate components better - in
the long run, I hope we can have vulnerability mitigation in place
from the kernel to the apps wherever it makes sense.

>> [...]

>> Our scope for this project is limited, in order to be able to complete
>> it successfully and not end up in a never ending development loop: The
>> phone should be able to communicate via Matrix, have a web browser,
>> make calls, take pictures. We are not aiming for a massive amount of
>> apps, but instead want the basic functionalities of the phone working
>> well when we ship it - more apps and features  can be delivered later
>> via Flatpaks and system updates.
>>
>> The UI therefore doesn't need to be excessive and support each and
>> every feature that Android already has, having a more minimal UI works
>> fine.
>
> I think that's a very valid approach. Catching up with Android (or iOS)
> in a short time-frame won't work, and it's better and more realistic to
> concentrate on a limited feature set and extend from there.
>
> That said, we have a reasonably working shell / workspace UI to launch
> and switch between apps, and a bunch of essential system controls, so
> we should offer a state which isn't too far from a basic usable system
> (except perhaps for Matrix support, but I'd suggest to read Eike's
> email, he's our chat goto guy and knows these ins and outs much better
> than I do).
>
> I think it would make sense to sit down and look at the delta between
> what you have in mind as a basic feature set and what we currently
> have, and then evaluate what we need to work on and prioritize based on
> that.

I think Plasma Mobile's current feature set pretty much covers what we
need already - the only thing needed would be system integration and
lots of design & polish. But I guess I need to try the phone UI again,
instead of just watching videos of it :-) (last time hands-on was last
year at Akademy).

> [...]
> We've been continuously improving our memory requirements (actually
> across the whole stack including Plasma desktop), and we will continue
> to do that. Bugfixing is of course among our top priorities.
>
> Aside from the obvious, embedded targets (not just phones, but also
> mini computers such as ODROID C1+, Pine64, Pinebook are an increasingly
> important target for us, so there's more performance work going to come
> in that specific area as well.
>
> What we're currently lacking is enthusiasm from people who want to work
> at the user interface level. We're running into a bit of a
> chicken-and-egg problem here, as we've long lacked viable target
> devices for Plasma Mobile, and a platform that only runs on very
> specific hardware and isn't at end-user quality (or very, very

Re: Plasma Mobile on the Librem 5

[Matthias Klumpp]

2017-08-29 15:58 GMT+02:00 Eike Hein <h...@kde.org>:
>
> On 08/29/2017 10:28 PM, Matthias Klumpp wrote:
>> As some of you might already know, we at Purism are planning to
>> develop a mobile phone that uses only free software and Matrix[2] for
>> communication. We are currently running a crowdfunding campaign[1] in
>> order to be able to make the phone a reality.>
>> [...]
>>
>> Our scope for this project is limited, in order to be able to complete
>> it successfully and not end up in a never ending development loop: The
>> phone should be able to communicate via Matrix, have a web browser,
>> make calls, take pictures. We are not aiming for a massive amount of
>> apps, but instead want the basic functionalities of the phone working
>> well when we ship it - more apps and features can be delivered later
>> via Flatpaks and system updates.
>
> Very interesting!
>
> I'll let others reply about some of the more Plasma Mobile-specific
> parts as they're better equipped to do so and will focus on the Matrix
> part, as it piqued my interest with my "Konversation developer" hat on.
>
> Konversation is KDE's IRC client. As a by-product of an (ongoing)
> conversation within the KDE community on whether we want to stick by IRC
> or move on to another chat solution as 'the one' for the community, and
> how to transition smoothly, we're currently (a) rewriting the UI to be
> more convergent and allow for a mobile version and (b) looking to
> retarget it as an IRC/Matrix client.
>
> This is a very early effort currently focused on UI experimentation and
> rampup (read: there are no Matrix bits yet, although the Konvi team has
> been following Matrix for a while and is to a degree familiar with the
> technology). After a few initial sessions of hacking this months, here
> are some (working and chatting) mockups of the UI direction:
>
> https://www.youtube.com/watch?v=1cr7hirDzws=1
> https://www.youtube.com/watch?v=b88oqdlNyuU=1
> http://imgur.com/a/bT7XE
>
> As you can see the UI is headed toward a responsive/convergent bent
> (here with desktop-specific concessions) using KDE's Kirigami UI technology.
>
> As one of the main problems the community has with IRC is the poor state
> of mobile access, a mobile version of Konversation for both Plasma
> Mobile and Android - both platforms Kirigami easily deploys to - is
> definitely planned, leveraging both Kirigami's convergent nature (and
> meaning it, not buzzword bingo) and the ability to do form
> factor-specific customization via KPackage. This work is currently being
> done in collab with KDE's Visual Design group and with (code, advice)
> support from the Kirigami team as well.
>
> Again, it's the early days of this effort - but I can confirm Matrix is
> something we're interested in and gearing up to hack on, motivated in
> large part by mobile. We share that one.

I was made aware of that effort already a few weeks ago, and it is
looking great! I guess the default Matrix app in the Librem phone
would have to be something focused on person-to-person communication
and tight integration with the user's contact list, instead of being
more group-chat centric like Konversation is. But having more choice
in Matrix clients is a good thing, and maybe we can have different UIs
for the same backend.
Keep up the good work!

Plasma Mobile on the Librem 5

[Matthias Klumpp]

[ Please keep the CC list intact for replies ]

Hi!

As some of you might already know, we at Purism are planning to
develop a mobile phone that uses only free software and Matrix[2] for
communication. We are currently running a crowdfunding campaign[1] in
order to be able to make the phone a reality.

One of the open questions for the phone is still which UX we will use,
and Plasma Mobile would obviously be a perfect fit for this kind of
project, since KDE and Purism share the same values, the UI is already
done in large parts, and nothing would have to be developed from
scratch (especially the Kirigami controls are great!).


## Some details about the phone software

The base operating system of the phone will be PureOS[3], our Debian
derivative that is currently pending endorsement from the FSF.
The plan is to use OSTree[4] for the base system, in order to achieve
atomic updates and easy rollbacks, as well as Flatpaks[5] for
deployment of applications. It is likely that we will have our own
Flatpak repository with apps specifically for the phone at some point
in the future.

The system will make full use of systemd and will use Bubblewrap[6]
for sandboxing of selected more critical components.

Due to the nature of the hardware, we will not need libhybris or any
Android kernel abstraction, which means that we can run stock Linux on
the phone, which greatly simplifies development and will allow us to
develop at a faster pace, due to not being bound to a specific kernel
version.
The downside is that the i.mx6 ARM CPU isn't incredibly fast. We hope
that we will be able to update to the faster i.mx8 when it is
available and can be used with free drivers, but at this point in time
we need to focus on the i.mx6 as primary hardware target.


## What we need from a phone UI

Our scope for this project is limited, in order to be able to complete
it successfully and not end up in a never ending development loop: The
phone should be able to communicate via Matrix, have a web browser,
make calls, take pictures. We are not aiming for a massive amount of
apps, but instead want the basic functionalities of the phone working
well when we ship it - more apps and features can be delivered later
via Flatpaks and system updates.

The UI therefore doesn't need to be excessive and support each and
every feature that Android already has, having a more minimal UI works
fine.


## Purism and KDE

While Purism is using GNOME for its laptops by default for various
reasons, partnering with KDE for the phone does make a lot of sense
for us, and we are excited about it. There are a few ways we can think
of how to help the Plasma Mobile team, and this email is intended to
make first contact and allow you to ask us any questions.

What we would be interested in is knowing about the future plans for
Plasma Mobile, especially in the area of design and performance
improvements. I didn't have the opportunity yet to test Plasma Mobile
on one of our development boards, but I hope I can get to that
soonish.

It is still not certain yet whether we will ultimately go with Plasma
Mobile as OS on the Librem 5 (there are also ideas to use GNOME), but
I think Plasma would be a good choice.

So, let's hope for the success of the campaign!
If you have any questions about Purism, the phone, Plasma on PureOS /
Debian, life, the universe, everything, please ask!

Kind regards,
Matthias Klumpp (Software engineer at Purism)


[1]: https://puri.sm/shop/librem-5/
[2]: https://matrix.org/
[3]: https://pureos.net/
[4]: https://ostree.readthedocs.io/en/latest/
[5]: http://flatpak.org/
[6]: https://github.com/projectatomic/bubblewrap

D7567: Support edit and appstream actions also for application search results

[Matthias Klumpp]

mak added inline comments.

INLINE COMMENTS

> hein wrote in actionlist.cpp:380
> That code wasn't touched during this refactoring, so this is immaterial to 
> the review. Please inform Aleix Pol about it.

I know, that's why I didn't flag this as change request (just a general 
observation).

REPOSITORY
  R119 Plasma Desktop

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

To: hein, #plasma, broulik, davidedmundson
Cc: mak, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7567: Support edit and appstream actions also for application search results

[Matthias Klumpp]

mak added inline comments.

INLINE COMMENTS

> actionlist.cpp:380
> +
> +const auto components = 
> appstreamPool->componentsById(service->desktopEntryName()+QLatin1String(".desktop"));
> +for(const auto : components) {

This will not work, because the component-ID can be an arbitrary reverse-DNS 
string identifying the application, and doesn't have to resemble the 
.desktop-entry-id at all. If that happens, it's purely accidental.

I was planning to add a `componentsByLaunchable(TYPE, STR)` method to AppStream 
anyway, I could probably do that for the next release of AS.

REPOSITORY
  R119 Plasma Desktop

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

To: hein, #plasma, broulik, davidedmundson
Cc: mak, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D6628: Fix and normalize license in .desktop files

[Matthias Klumpp]

mak added a comment.


  Is there any reason not to use the SPDX license IDs here? => 
https://spdx.org/licenses/ (e.g. `GPL-2.0+` in this case).
  In any case, this patch makes things way better, so +1 from me :-)

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

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

To: sebas, #plasma, sitter, mart, broulik
Cc: mak, mart, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, lukas

Re: Discover depending on unreleased Appstream

[Matthias Klumpp]

2017-06-27 10:23 GMT+02:00 Jonathan Riddell :
> Plasma Discover recently got an update to use Appstream Qt API which
> was itself only committed a few days ago
>
> https://phabricator.kde.org/D6267 Use appstream-qt insted of glib based one
>
> https://github.com/ximion/appstream/commit/548a5ae6617ef1c2523981cadb73fd2d41e0cf43#diff-e85823b4e7db1064f4301e1c74978199
>
>
> Do we have any reassurances that appstream will be released and
> realistic for distros to use before the Plasma 5.11 release?

Yes, there will likely be multiple releases prior to the Plasma 5.11
release. This patch might cause issues for people wanting to test
Discover Master right now though.
I am aiming for an AppStream release next Monday.

Cheers,
Matthias

D5405: Create desktop file name based on organization domain unless set explicitely

[Matthias Klumpp]

mak added a comment.


  In https://phabricator.kde.org/D5405#101574, @ltoscano wrote:
  
  > I'm still confused. Documentation or not, bad usage or not, is it correct 
that desktop file name is constructed from both the organization domain AND the 
homepage?
  
  
  Yes. See 
https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s02.html

REPOSITORY
  R244 KCoreAddons

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

To: stikonas, mpyne, kossebau, aacid, ltoscano
Cc: mak, plasma-devel, kde-frameworks-devel, #frameworks, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol

[Differential] [Accepted] D4447: Add missing summaries

[Matthias Klumpp]

mak accepted this revision.
mak added a reviewer: mak.
mak added a comment.
This revision is now accepted and ready to land.


  Looks good!

REPOSITORY
  R120 Plasma Workspace

BRANCH
  Plasma/5.9

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #plasma, mak
Cc: mak, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Commented On] D3923: Make AppstreamQt optional

[mak (Matthias Klumpp)]

mak added a comment.


  In https://phabricator.kde.org/D3923#73574, @anthonyfieroni wrote:
  
  > In https://phabricator.kde.org/D3923#73375, @mak wrote:
  >
  > > In any case, knowing the distro might be useful to check whether their 
packaging makes sense ;-)
  >
  >
  > KaOS don't have appstream nor appstreamQt nor Discover (it's a fairly 
normal when first two are missing)
  
  
  Well, then they should package it? It really has no unusual dependencies, and 
the only one which isn't available everywhere I checked (libstemmer) can be 
disabled via a compile-time switch.
  I am more after the "too many dependencies" claim than after distros not 
having packaged the library, because the latter is relatively easy to achieve 
(KaOS could just pull the Arch Linux package).
  Speaking of Arch Linux: Their package has an unnecessary dependency on 
protobuf, python2 and intltool.

REPOSITORY
  R119 Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: davidedmundson, #plasma, apol
Cc: anthonyfieroni, huber, hein, mak, plasma-devel, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, andreaska, sebas

[Differential] [Commented On] D3943: Make sure we only initialize the appstream pool once

[mak (Matthias Klumpp)]

mak added a comment.


  Looks good!
  (appstreamPool is a bit verbose for my taste, AppStream interally calls it 
dpool (DataPooL) asPool or just pool - but that's just me being lazy and having 
to type too much n C anyways)

REPOSITORY
  R119 Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #plasma, broulik
Cc: mak, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Commented On] D3923: Make AppstreamQt optional

[mak (Matthias Klumpp)]

mak added a comment.


  @davidedmundson What do you mean with big dependency chain? libappstream and 
libappstreamQt depend in total on only libxml2, libyaml, GLib and Qt5Core which 
pretty much any distro, especially with Plasma on it, should already have 
anyway.
  Didn't you use Neon? Or was it Manjaro/Arch? In any case, knowing the distro 
might be useful to check whether their packaging makes sense ;-)

REPOSITORY
  R119 Plasma Desktop

BRANCH
  master

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: davidedmundson, #plasma, apol
Cc: mak, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

Re: Discover requires Qt 5.7?

[Matthias Klumpp]

2016-09-22 14:36 GMT+02:00 Matthias Klumpp <matth...@tenstral.net>:
> 2016-09-22 13:15 GMT+02:00 Jonathan Riddell <j...@jriddell.org>:
>> On Thu, Sep 22, 2016 at 01:02:45PM +0200, Aleix Pol wrote:
>>> On Thu, Sep 22, 2016 at 10:20 AM, Daniel Vrátil <dvra...@kde.org> wrote:
>>> > Hi,
>>> >
>>> > Discover 5.7.95 requires Qt 5.7 due to usage of qAsConst() [0], although
>>> > CMakeLists.txt claims Qt 5.2 is required (which seems to be too low 
>>> > anyway).
>>> >
>>> > Can you please either replace qAsConst() with const_cast or bump the Qt
>>> > dependency?
>>> >
>>> > Thanks,
>>> > Dan
>>> >
>>> > [0] https://copr-be.cloud.fedoraproject.org/results/mkyral/plasma-5.7.95/
>>> > fedora-24-x86_64/00455948-plasma-discover/build.log.gz
>>>
>>> This and other problems have been fixed lately, when I was pointed
>>> this could be a problem. The next beta will work with Qt 5.6.
>>
>> There's no more betas, only a final release next week, so verification 
>> before then would be good.
>
> I requested that change, tested it and it works ~okay - there are some
> UI / font rendering issues, but all of those problems are apparently
> caused by Qt itself, so nothing we can solve. Also, they don't make
> using Discover impossible or harder, it just doesn't look as nice.
>
> So, for me it's working with Debian's version of Qt 5.6.

One addition: If Kirigami is missing on the system, Discover will
build but simply crash on startup - so, we should make the application
handle this case better (= not crash) or simply depend on Kirigami at
build-time, so people don't forget to make it available.
Especially for distributors this is kind of important, so they get the
dependencies set correctly.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: Discover requires Qt 5.7?

[Matthias Klumpp]

2016-09-22 13:15 GMT+02:00 Jonathan Riddell :
> On Thu, Sep 22, 2016 at 01:02:45PM +0200, Aleix Pol wrote:
>> On Thu, Sep 22, 2016 at 10:20 AM, Daniel Vrátil  wrote:
>> > Hi,
>> >
>> > Discover 5.7.95 requires Qt 5.7 due to usage of qAsConst() [0], although
>> > CMakeLists.txt claims Qt 5.2 is required (which seems to be too low 
>> > anyway).
>> >
>> > Can you please either replace qAsConst() with const_cast or bump the Qt
>> > dependency?
>> >
>> > Thanks,
>> > Dan
>> >
>> > [0] https://copr-be.cloud.fedoraproject.org/results/mkyral/plasma-5.7.95/
>> > fedora-24-x86_64/00455948-plasma-discover/build.log.gz
>>
>> This and other problems have been fixed lately, when I was pointed
>> this could be a problem. The next beta will work with Qt 5.6.
>
> There's no more betas, only a final release next week, so verification before 
> then would be good.

I requested that change, tested it and it works ~okay - there are some
UI / font rendering issues, but all of those problems are apparently
caused by Qt itself, so nothing we can solve. Also, they don't make
using Discover impossible or harder, it just doesn't look as nice.

So, for me it's working with Debian's version of Qt 5.6.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

Re: Review Request 128996: Don't generate appstream files for components that are not in rdn

[Matthias Klumpp]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128996/#review99401
---


Ship it!




Ship It!

- Matthias Klumpp


On Sept. 21, 2016, 10:41 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128996/
> ---
> 
> (Updated Sept. 21, 2016, 10:41 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Appstream will spit them out anyway, better do it early in the process and 
> with a warning.
> 
> 
> Diffs
> -
> 
>   KF5PackageMacros.cmake 7a12292 
> 
> Diff: https://git.reviewboard.kde.org/r/128996/diff/
> 
> 
> Testing
> ---
> 
> Plasma Desktop doesn't generate information for offending components but also 
> won't make the test fail.
> 
> ```
>   Appstream information won't be generated for kcm_splashscreen.
>   Appstream information won't be generated for kcm_desktoptheme.
>   Appstream information won't be generated for kcm_lookandfeel.
> ```
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

Re: Fix the broken plasma-desktop! Re: Jenkins-kde-ci: plasma-desktop master kf5-qt5 » Linux,gcc - Build # 326 - Still unstable!

[Matthias Klumpp]

2016-09-12 16:33 GMT+02:00 Martin Gräßlin :
> Hi all,
>
> this has been broken now since Friday. We have several builds on it which
> did not address it. This is not OK.
>
> It's our responsibility to keep the CI green. A CI where everybody just
> ignores it, is pointless.
> This must be a show stopper, especially one week before the release.
>
> So everyone please have a look at it.
>
> The problem is the appstream test failing. Please check the modules you
> maintain and fix it:

Fascinating - it looks like the failure is mainly triggered by the
components not having a reverse domain-name... I am not sure if that
can be fixed right now, and whether it is useful to have metadata for
KCMs at all, so for some components it might be useful to ignore the
failed test.
On the other hand, having reverse-DNS names is really important now...

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/

[Differential] [Commented On] D1816: Switch to Noto Mono as default monospace font

[mak (Matthias Klumpp)]

mak added a comment.


  `Hack` and `Source Code Pro` are beautiful fonts for programming - from a 
Debian perspective, there is no reason to not use `Hack`, we have it in the 
archive already (I don't know about `Source Code Pro` though).

REPOSITORY
  rPLASMAINTEGRATION Integration for Qt applications in Plasma

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: jriddell, #plasma, #plasma:_design
Cc: mak, jensreuterberg, palimaka, dhaumann, mart, davidedmundson, 
plasma-devel, abetts, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Long term support release for Plasma?

[Matthias Klumpp]

Hey :)

Just a quick notice: All the judgement on this issue given by Debian
and Kubuntu people apply to Tanglu as well (and we completely agree
with Martin Steigerwalds post).

Cheers and greetings from Debconf!
Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D1844: Add Appinfo metadata file

[mak (Matthias Klumpp)]

mak added inline comments.

INLINE COMMENTS

> org.kde.plasmashell.metainfo.xml:4
> +  org.kde.plasmashell
> +  GPL-2.0+
> +  KDE Plasma Desktop

Btw, a "metadata_license" tag with a permissive license (CC0/MIT) needs to be 
added too, so we are sure that we can reuse the metadata downstream easily.
See 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license
 for details.

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: jriddell, mak, #plasma, sebas, #visual_design_group
Cc: bshah, sebas, plasma-devel, jensreuterberg
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D1844: Add Appinfo metadata file

[mak (Matthias Klumpp)]

mak added inline comments.

INLINE COMMENTS

> CMakeLists.txt:158
>  endif()
> +install(FILES "${CMAKE_CURRENT_BINARY_DIR}/plasma-desktop.metainfo.xml" 
> DESTINATION ${METAINFODIR})
>  feature_summary(WHAT ALL INCLUDE_QUIET_PACKAGES 
> FATAL_ON_MISSING_REQUIRED_PACKAGES)

I might be wrong with that, but shouldn't `METAINFODIR` be 
`CMAKE_INSTALL_METAINFODIR` (or KDE_INSTALL_* for that matter?)
Also, you probably want CMAKE_CURRENT_SOURCE_DIR instead of BINARY_DIR, to make 
out of tree builds work, and also adjust the filename here too ^^.

> org.kde.plasmashell.metainfo.xml:16
> +   Plasma Desktop in Folder View with Clock and Notes 
> Widgets
> +type="source">https://www.kde.org/workspaces/plasmadesktop/screenshots/general-desktop.png
> +

You could even drop the type=source property here, but having it also doesn't 
hurt.

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: jriddell, #visual_design_and_promo, mak, #plasma, sebas
Cc: bshah, sebas, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D1844: Add Appinfo metadata file

[mak (Matthias Klumpp)]

mak added inline comments.

INLINE COMMENTS

> mak wrote in plasma-desktop.metainfo.xml:3
> This should ideally be a reverse-domain-name, to fit the general style of 
> AppStream unique IDs.
> So something like "org.kde.plasmashell" or "org.kde.plasma-desktop".
> See 
> https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-id-generic

oh, and if this is changed, renaming the metainfo file is a useful thing to do 
(-> "org.kde.plasmashell.metainfo.xml")

> plasma-desktop.metainfo.xml:16
> +   Plasma Desktop
> +height="930">https://www.kde.org/workspaces/plasmadesktop/screenshots/general-desktop.png
> +

FWIW, you can omit width and height here - the AppStream generators won't trust 
that information in metainfo files anyway and just fetch the screenshot and 
update the data accordingly.
Also, the caption should probably be a bit more descriptive, e.g.  "The Plasma 
desktop with a notes and clock widget."

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: jriddell, #visual_design_and_promo, mak, #plasma, sebas
Cc: bshah, sebas, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: appstream in Plasma

[Matthias Klumpp]

2016-06-13 14:54 GMT+02:00 Jonathan Riddell :
> I've submitted a review for a plasma-desktop metadata file.
> https://phabricator.kde.org/D1844
> But I was surprised to see the metadata format doesn't support many
> types.  Shouldn't something like Plasma widgets be a good target for
> appstream metadata?

Types are generally for not application-specific elements which are
useful in every desktop. So we will likely see a type "wallpaper" and
"icontheme" in future.
For everything that is app-specific, there is an extension mechanism
in place. See 
https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Addon.html
for details.

That way, we keep the amount of big component types small and
manageable, while still allowing apps to find their extensions.
Problems happen if an application supports multiple different types of
addons, or wants to filter them somehow. For that, it might be useful
to add some kind of addon_domain tag to the spec later, to allow this
kind of fine-grained filtering.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D1844: Add Appinfo metadata file

[mak (Matthias Klumpp)]

mak added a comment.


  In https://phabricator.kde.org/D1844#34142, @sebas wrote:
  
  > Should also have a screenshot?
  
  
  Normally I would say "yes", but since this is a so-called generic component, 
which means that it will be possible to search for it with cli tools and 
install it easily e.g. via "appstreamcli install `, but it will generally 
not be visible in tools like Discover.
  This is because installing a complete DE is usually seen to be a bad idea.
  
  So, adding screenshots won't hurt, but they won't be as visible as 
type=desktop component ones.
  Btw, having a generic name of Plasma means one can write metainfo files for 
Plasmoids (which would sett "org.kde.plasmashell" in their metainfo 
file), meaning Plasma would be able to search for Plasmoids in a 
distro-agnostic way, so this is a great addition.

INLINE COMMENTS

> CMakeLists.txt:158
>  endif()
> +install( FILES "${CMAKE_CURRENT_BINARY_DIR}/plasma-desktop.metainfo.xml" 
> DESTINATION ${SHARE_INSTALL_PREFIX}/appdata/
>  feature_summary(WHAT ALL INCLUDE_QUIET_PACKAGES 
> FATAL_ON_MISSING_REQUIRED_PACKAGES)

This should be `${SHARE_INSTALL_PREFIX}/metainfo/`, the "appdata" path is the 
legacy location.
Or simply use the e-c-m variable (which still needs to be updated to point to 
/metainfo at a later time).

> plasma-desktop.metainfo.xml:3
> +
> +  kde-plasma-desktop
> +  GPL-2.0+

This should ideally be a reverse-domain-name, to fit the general style of 
AppStream unique IDs.
So something like "org.kde.plasmashell" or "org.kde.plasma-desktop".
See 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-id-generic

> bshah wrote in plasma-desktop.metainfo.xml:11
> This is wrong, no? there is no plasma-desktop binary anymore? or you mean 
> package name?

Jup, the binary name would be plasmashell. But you could omit this data block 
entirely, unless you want people to be able to search for the AppStream 
component when they know the binary name.

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: jriddell, #visual_design_and_promo, sebas, #plasma, mak
Cc: bshah, sebas, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: appstream in Plasma

[Matthias Klumpp]

2016-04-10 0:06 GMT+02:00 Thomas Pfeiffer :
> On Samstag, 9. April 2016 20:32:24 CEST Martin Graesslin wrote:
>
>> If using a framework requires a workspace component being installed,
>> something is seriously broken in our workflows. We have worked a lot on
>> making our apps not depend on Plasma, let's not accept a status where that
>> doesn't work.
>
> That, right here, may well be the most important argument: If an application
> is supposed to work outside of Plasma, it must work there properly without any
> part of Plasma installed, period.

Full ACK

> If an application doesn't, file a bug. If the application team doesn't care,
> then they apparently don't care about their application running anywhere else.
> That's their loss, then, and it's not Plasma's task to fix the situation for
> them.
>
>> > What I have understood so far, systemsettings5 is supposed to be a
>> > Plasma-only tool. Given that, we (KDE) are lacking a KCM browser tool
>> > suitable for everyone.
>
> We are not. No browser tool for _Plasma_ settings needs to be suitably for
> anyone not using Plasma, because...
>
>> Correct systemsetting is part of Plasma. This means it is meant for use in
>> Plasma. No KDE application should depend on a Plasma tool being installed.
>> If applications/frameworks are not useable without having Plasma installed,
>> that is a bug in the applications/frameworks that needs to be fixed.
>
> ...as Martin says: If an application needs a setting, that setting has to be
> reachable from the application. An application cannot assume a specific 
> desktop
> settings applicaiton to be available.

Indeed. I would even argue that the user ever wanting to install a
settings module is a serious bug on its own, because it means there is
either a bug in the app or in the existing settings so the user can't
find something he's looking for.
The problem with the existing Systemsettings is that there are modules
which we don't install by default, which users might want to have. At
time, only the systemd module comes to my mind. Question is: Is the
systemd KCM an app, or is it a settings panel?

>> And that is obviously a bug: we cannot expect users to know that they need
>> to install Plasma's systemsettings to configure KFooBar.
>
>> And I need to point out: making systemsettings available in e.g. GNOME would
>> also mean that we need to make sure it's useable in GNOME. This means for
>> example adding lots of "Only-Show-In=Plasma" to our configuration modules.

This is not something we support with AppStream, and I am in very
strong opposition against adding it (as in: never gonna happen, unless
some really huge problem appears that can only be solved by adding
this).
With AppStream, you either mark your software as app and have it show
up in all software centers, or - if it is really desktop specific -
hide it by making it a generic component.

>> It's a little bit confusing after all if you open systemsettings in GNOME,
>> go to window management, change something and it doesn't change it. And I
>> just checked: KWin's configuration modules don't have that entry, they
>> would be shown. It would be quite some work to get this configured in a way
>> that it is useful for a user on GNOME. Sorry, no, we care about Plasma here
>> and not about making Plasma tools work on other DEs. You have all the
>> rights to use it, though. Nobody is restricting that right.
>
> Interestingly, GNOME Control Center does provide AppStream data, so it should
> show up in e.g. Discover (it does so for me in Manjaro, at least).

Yes, GNOME provides metadata for it and makes it an application... I
am discussing this with upstream at time, and there is a pretty good
chance that we can drop this and making it not show up anymore.
Having users install missing settings panels from the SC is just wrong...

What you can do with AppStream - and I am not sure if that's actually
a good solution - is having apps themselves search for missing
modules.
So in case of the systemd KCM, the Systemsettings app itself could
offer users to install the systemd module, e.g. via an "Additional
configurations" module, or just when the users search for it, etc.
Since AppStream assigns a unique ID to every software, finding it and
making it available is easy (e.g. by passing it's ID directly to the
Discover, which can then install it).
I don't think users will ever thing of installing desktop settings
modules via Discover, and I don't think they should ever need to do
that. Whether having Systemsettings itself offer the installation of
missing stuff is a good idea is something I am not sure about either,
though.

Cheers,
Matthias

P.S: I will make some changes in AppStream which should make it more
obvious that you can use the metadata for *anything* - you should just
select the right component type (generic, desktop(-app), font, codec,
inputmethod, addon, firmware) for it.

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE 

Re: metadata.yaml for Plasma projects?

[Matthias Klumpp]

2016-04-07 13:55 GMT+02:00 Martin Graesslin :
> On Thursday, April 7, 2016 1:21:55 PM CEST Aleix Pol wrote:
>> On Thu, Apr 7, 2016 at 11:41 AM, Martin Graesslin 
> wrote:
>> > Hi Plasmates,
>> >
>> > an idea for better documentation is to introduce some metadata similar
>> > like
>> > what frameworks have. This could be useful for potential devs who want to
>> > contribute, but also for distributions as in that way:
>> > * we can specify whether it's experimental, released, obsoleted, etc.
>> > * what other Plasma projects it depends on
>> > * who is maintaining it and where to reach us
>> >
>> > Below I have an example how this could look like (in the case of KWin).
>> >
>> > What do you think?
>> >
>> > Cheers
>> > Martin
>> >
>> > # The maintainer of the project
>> > maintainer: graesslin
>>
>> I'd suggest offering an appstream appdata file instead of this.
>
> We have projects for which appstream doesn't make sense. Example is KWin,
> kdecoration, kscreenlocker, kwayland, etc. etc. In fact I think we have more
> projects in Plasma which do not need an appdata file than projects which
> actually benefit from it.

That's actually not true - AppStream is a generic metadata format, and
instead of writing an appdata file, you can just as well write a
generic metainfo file to add metadata (and a unique ID!) to any
software component.
Just omit the type= attribute in the  root tag, or set it
to "generic". Those components won't show up in software centers, but
the metadata will still be available in distributions via more
advanced tools.

So, your metadata file ideally only contains stuff that isn't in the
metainfo XML already - or you add your own, non-standard tag to the
metainfo file.

> # The maintainer of the project
> maintainer: graesslin

Maybe update_contact, or the developer tag (but that would in this
case be "KDE", and having a KDE Identity name makes sense, so maybe
extra data is necessary here).

> # A short description of the project
> description: X11 Window Manager and Wayland Compositor

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-summary

> # tier 1: depends only on Qt and KDE frameworks
> # tier 2: depends only on Qt, KDE frameworks and tier 1 Plasma projects
> # tier 3: depends on Qt, KDE frameworks, tier 1, 2 and 3 Plasma projects
> tier: 3

Not in AppStream (obviously)

> # Whether the project is obsoleted, if true means it's not included in future
> # releases any more
> obsoleted: false

Not in AppStream.

> # Whether this is an experimental project
> experimental: false

Not in AppStream, but probably a good idea to add it, to mark
development snapshots and experimental apps in software centers (and
hide them by default, while still allowing for an easy way to install
them if needed).

> # Whether it's included in releases
> release: true

Not in AS, KDE specific.

> # The git clone url
> git: git://anongit.kde.org/kwin

Same

> # some code review information on phabricator
> phabricator:
> # url to the diffusion
> diffusion: https://phabricator.kde.org/diffusion/KWIN/
> # the review group
> reviewer: plasma
> # the project it belongs to
> project: plasma
> irc:
> network: chat.freenode.net
> channel: "#kwin"
> mailinglist: k...@kde.org

Not in AppStream.

> bugs:
> url: https://bugs.kde.org
> product: kwin

See 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-url

> dependencies:
> - KWayland
> - KDecoration
> - KScreenLocker

Not in AS.

So: You might want that extra metadata, but ideally you don't want to
duplicate stuff that's in AS metainfo files already.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: appstream in Plasma

[Matthias Klumpp]

2016-04-07 19:47 GMT+02:00 Martin Gräßlin :
> Am 2016-04-07 18:01, schrieb Scarlett Clark:
>>
>> FWIW some distros like Kubuntu (neon?) use systemsettings for all of
>> our system settings. So having separate places for all other settings
>> is very poor user experience.
>
> But Kubuntu uses Plasma and systemsettings is installed. So for Kubuntu it
> just doesn't matter whether there is appstream data for systemsettings. In
> fact it would be bad, why list something which the user has installed and
> should not uninstall.

AppStream has a compulsory_for_desktop key, which hides the uninstall
button - this is only really useful though if the app has addons to be
installed (and should be shown).

In the case of the systemd KCM, you could declare that to be an addon
to Systemsettings...

>> And I do recall seeing in various places third party KCMs like systemd
>> and feel that this absolutely should be supported.
>
>
> Sure, 3rd party can install to integrate with Plasma. That's fine. But not a
> reason to have systemsettings available outside of Plasma.

Yes.

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: appstream in Plasma

[Matthias Klumpp]

2016-04-07 15:08 GMT+02:00 Jonathan Riddell :
> Martin's thread on metadata got me wondering about if we should have
> appstream files in Plasma.  It would be nice to have plasma-desktop in
> software installers for people who run another desktop and want to
> install it.  There's also applications like system settings (which has
> dozens of plugins), khotkeys and kinfocenter which may or may not be
> useful for appstream.

I'm at the GNOME Software hackfest right now (working mainly on
AppStream), and we briefly discussed this: Generally, adding desktops
to the SC isn't a great idea, because it's not really an application,
but a system component - being able to run more desktops than one is
more useful for distro developers and experienced users, and will be
very confusing for regular users, which are the target audience of
software centers.

However, adding an AppStream metainfo file would be something I would
very much support! AppStream supports "generic components", so you
could just drop a file
"org.kde.plasma-desktop.metainfo.xml" containing

  Plasma Desktop
  
  ... (etc)

which describes the Plasma Desktop. Software centers like Discover or
GNOME Software will not show that, but users can find it with
appstreamcli and would be able to install it using "appstreamcli
install org.kde.plasma-desktop".

So: More metadata please! (But ideally no desktops in the SC)

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127308: Fix name of desktop file to have icon working on Wayland

[Matthias Klumpp]

> On März 8, 2016, 5:20 nachm., Hrvoje Senjan wrote:
> > Do we want a kconf_update script with that for all hte people that have 
> > systemsettings.desktop as favourite in launchers?
> 
> Martin Gräßlin wrote:
> I don't think it's needed. The important part is that there is a desktop 
> file which is reverse domain name dot binaryname. How the desktop file which 
> launched the application is called, doesn't really matter.
> 
> Hrvoje Senjan wrote:
> A misunderstanding ;-)
> I'm merely talking about people losing their favourite after upgrading to 
> 5.6.
> 
> Martin Gräßlin wrote:
> Sorry I don't get that. Why should renaming result in losing the favorite?
> 
> Matthias Klumpp wrote:
> The favourite apps settings is a list with .desktop filenames which are 
> shown in the launcher. If you now change the .desktop filename, the launcher 
> entry will become invalid or vanish, although the actual application is still 
> there, leading to confused users.
> 
> Martin Gräßlin wrote:
> and where is that stored?
> 
> Martin Gräßlin wrote:
> btw. that's a pretty big problem. We have thousands of incorrectly named 
> desktop files. I don't want to write a kconf update script for each of them. 
> I don't mind spending the time to fix the desktop files, but also adding a 
> kconf update script is quite some work.

Yeah, it's a massive pain. Ubuntu is duplicating .desktop files for that reason 
and hiding the new name (so the app doesn't show up twice), so user's 
favourites don't break in Unity - which has a whole lot of problems.
GNOME had a .desktop file name mapping once (I think meanwhile they've just 
given up completely), but only cared for GNOME apps in there.

So yes, much pain, hard to solve, really annoying :(


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127308/#review93306
---


On März 8, 2016, 3:18 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127308/
> ---
> 
> (Updated März 8, 2016, 3:18 nachm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> The desktop file name should include the reverse domain name and must
> much the binary.
> 
> 
> Diffs
> -
> 
>   app/CMakeLists.txt 3fa8dbb52b4cd8fd553c67a768fcd68c51cb83e4 
>   app/systemsettings.desktop  
> 
> Diff: https://git.reviewboard.kde.org/r/127308/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: two exceptions for string freeze in Plasma

[Matthias Klumpp]

First of all, I don't have a strong opinion on generic names - name
the stuff whatever you want to!

2016-03-09 16:00 GMT+01:00 Sebastian Kügler :
> [...]
>
> I find this whole discussion rather backwards. I could address the concerns by
> coming up with some random bullshit name, putting that in the Name= field and
> putting "Info Center" into GenericName= then. I still don't know which
> (actual, not constructed possible future) problem it would solve other than
> putting one of the unfounded concerns to sleep. I do know some new problems it
> creates, though. Of course it also adds a lot of work.
>
> I simply don't want to waste my time discussing things that lead nowhere, and
> so far, this thread strongly resembles this, while almost entirely ignoring my
> initial question.  I'm leaning towards just ignoring further discussion on
> this and accepting that we keep the wrong "KDE" usage in Plasma 5.6 because
> apparently we prefer bickering over getting our shit together. Yes, this is a
> frustrating experience.

The issue is rather theoretical: By claiming a generic name other
desktop environments may want to use or may even use already in their
UI, it creates confusion (especially in software centers) over what
the right "Info Center" application is. It also makes it a bit harder
to google for answer "Mediaplayer is crashing when playing file X! -
Which Mediaplayer? The one used in KDE, GNOME, MATE, ...". In software
centers you might have five different apps called "Mediaplayer" or
"Photos" etc.
That's pretty much the reason for wanting specific names like "Plasma
Info Center".
It's just something to keep in mind to not overdo it with generalizing
names. For the particular case, I think "Info Center" is fine (there's
no other tool named like this). Please don't make the binary name
generic too, though ;-)


>> P.S: Sidenote: Could people please add Summary= fields to .desktop
>> files too?  This is the No1 reason KDE apps are rejected for
>> inclusion into AppStream at time
>
> First time I hear of the Summary field, may warrant telling more people about
> it. Which .desktop files need it, for example? (If you answer, you may as well
> create a new thread, in this thread, it's about as off-topic as it gets and
> given the depth of the emails in this thread, it will likely not be read by
> many people at this stage.)

Heh, you probably haven't heard of it because it's actually the
Comment= field in .desktop files, but called "summary" in the
AppStream spec. Basically, if you don't define a summary in your
metainfo file for AppStream, you must at least have a Comment= tag in
your desktop file.
I will add a check for that in the AppStream validator soon even when
there is no AppStream metadata present, and also raise the issue again
on the ML.

Thanks!

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 127308: Fix name of desktop file to have icon working on Wayland

[Matthias Klumpp]

> On März 8, 2016, 5:20 nachm., Hrvoje Senjan wrote:
> > Do we want a kconf_update script with that for all hte people that have 
> > systemsettings.desktop as favourite in launchers?
> 
> Martin Gräßlin wrote:
> I don't think it's needed. The important part is that there is a desktop 
> file which is reverse domain name dot binaryname. How the desktop file which 
> launched the application is called, doesn't really matter.
> 
> Hrvoje Senjan wrote:
> A misunderstanding ;-)
> I'm merely talking about people losing their favourite after upgrading to 
> 5.6.
> 
> Martin Gräßlin wrote:
> Sorry I don't get that. Why should renaming result in losing the favorite?

The favourite apps settings is a list with .desktop filenames which are shown 
in the launcher. If you now change the .desktop filename, the launcher entry 
will become invalid or vanish, although the actual application is still there, 
leading to confused users.


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127308/#review93306
---


On März 8, 2016, 3:18 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127308/
> ---
> 
> (Updated März 8, 2016, 3:18 nachm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: systemsettings
> 
> 
> Description
> ---
> 
> The desktop file name should include the reverse domain name and must
> much the binary.
> 
> 
> Diffs
> -
> 
>   app/CMakeLists.txt 3fa8dbb52b4cd8fd553c67a768fcd68c51cb83e4 
>   app/systemsettings.desktop  
> 
> Diff: https://git.reviewboard.kde.org/r/127308/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: two exceptions for string freeze in Plasma

[Matthias Klumpp]

2016-03-09 10:26 GMT+01:00 Sebastian Kügler :
> [...]
> I'd like to address your feedback and come to a solution everyone is happy
> with, but for that, please provide suggestions what to use instead, and don't
> just point out "that's bad", because the previous naming was wrong, and the
> current isn't (AFAICS), so it's not an option to just revert, I'd rather fix
> it.

The Freedesktop .desktop spec has a GenericName= key, which is exactly
for the purpose of allowing to display generic names in menus if
necessary. Values for GenericName might be "Media Player" "Info
center", "System Settings" "File Manager" etc. while the Name key
contains the actual application name.
So, changing how that stuff is displayed and giving it a generic name
key would probably make everyone happy :)
(KDE could also in theory add a key X-KDE-PreferGenericName to prefer
the GenericName over the Name key in Plasma)

Cheers,
Matthias

P.S: Sidenote: Could people please add Summary= fields to .desktop
files too? ;-) This is the No1 reason KDE apps are rejected for
inclusion into AppStream at time ;-)

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126732: a plymouth theme for breeze

[Matthias Klumpp]

> On Jan. 13, 2016, 2:55 nachm., andreas kainz wrote:
> > Hi,
> > 
> > for me it look to "boring". I'm working on a cooperate design from grub to 
> > the shutdown menue. and plymouth is one part of it.
> > 
> > I made a grub theme and some mockups you can get everything in the 
> > share.kde.org and the forum thread.
> > 
> > My idea was to have the plasma background on top an "transparent" black 
> > overlay. Big header on top on bottom a toolbar compare to the plasma 
> > standard panel and in the middle an vertical align element. For plymounth I 
> > would move in the middle the konqui-app-hardware-mascot 
> > https://share.kde.org/index.php/s/jXXooedZYlyUqkC with an rotating circle 
> > for the booting element. if the harddisk wil be scanned the 
> > konqui-app-hardware-mascot could play tetris and when you have to enter the 
> > key the mascot could be animated don't know. only an idea.
> > 
> > my focus was same "style" for everything an useful (nice and good readable) 
> > background and in the center the stuff you need.
> > 
> > 
> > my draft files
> > https://share.kde.org/index.php/s/URqovLbvXdY9nD3
> > https://share.kde.org/index.php/s/ar8AoTUmMGNGOGf
> > 
> > the related kde forum
> > https://forum.kde.org/viewtopic.php?f=285=130271=349237#p349237
> 
> Kai Uwe Broulik wrote:
> Note that the splash screen needs to be baked into the kernel image which 
> means a huge wallpaper significantly blows it up and slows down startup, 
> which is why a simple gradient is the best we could do.

> Note that the splash screen needs to be baked into the kernel image

You mean the initramfs, right? :P A massive wallpaper will definitely slow down 
boot with slow disks in any case (question is: how much? has anyone measured 
that?), so it's probably best to not get too crazy with the Plymouth theme ^^


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126732/#review91012
---


On Jan. 13, 2016, 2:27 nachm., Jonathan Riddell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126732/
> ---
> 
> (Updated Jan. 13, 2016, 2:27 nachm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: breeze
> 
> 
> Description
> ---
> 
> a plymouth theme for breeze
> 
> based on kubuntu theme, it's one image with a fading in and out glow
> also a 16 bit fallback which is just the static k logo
> some cmake to look for the current plymouth theme diretory which could do 
> with testing on other distros
> it doesn't try to set it as default theme or run update-initramfs, I think 
> that can only be done by packagers
> suggestions for artwork welcome but changing the functionality (fade in and 
> out glow) is not something I have the knowledge or time for
> I've not included a text fallback theme, the plymouth text theme seems very 
> limited in functionality and the ubuntu-text theme is presumably distro 
> specific
> 
> http://weegie.edinburghlinux.co.uk/~jr/tmp/out-3.ogv
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt cdcc46e 
>   cmake/FindPlymouth.cmake PRE-CREATION 
>   plymouth/CMakeLists.txt PRE-CREATION 
>   plymouth/breeze/README PRE-CREATION 
>   plymouth/breeze/breeze.grub PRE-CREATION 
>   plymouth/breeze/breeze.plymouth.in PRE-CREATION 
>   plymouth/breeze/breeze.script PRE-CREATION 
>   plymouth/breeze/images/16bit/dot.png PRE-CREATION 
>   plymouth/breeze/images/16bit/logo.png PRE-CREATION 
>   plymouth/breeze/images/16bit/progress-rect.png PRE-CREATION 
>   plymouth/breeze/images/16bit/text-input.png PRE-CREATION 
>   plymouth/breeze/images/dot.png PRE-CREATION 
>   plymouth/breeze/images/logo-glow.png PRE-CREATION 
>   plymouth/breeze/images/logo.png PRE-CREATION 
>   plymouth/breeze/images/source.svgz PRE-CREATION 
>   plymouth/breeze/images/text-input.png PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/126732/diff/
> 
> 
> Testing
> ---
> 
> installed this
> set default.plymouth link to point to breeze.plymouth
> install plymouth-x11
> sudo plymouthd --debug --tty=`tty` --no-daemon
> sudo plymouth show-splash
> pretty K blinks
> 
> 
> Thanks,
> 
> Jonathan Riddell
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D797: Require user to authenticate when trying to change lock screen settings

[mak (Matthias Klumpp)]

mak added a subscriber: mak.
mak added a comment.

In https://phabricator.kde.org/D797#15210, @davidedmundson wrote:

> This breaks every user's backup script by having root files in the user's 
> home. So I am very much not happy with this idea at all.
>  Especially as it acheives very little anyway, if you have a malicious app on 
> your system - why on Earth does it want to modify your lock screen settings 
> when it has access to everything the user has already?
>
> We want to sandbox apps that might misbehave from the user, not elevate user 
> processes above the user.


I must agree with David on this, generally having root own files in /home is a 
terrible idea.
One solution that might work is to move the whole configuration file out of 
home and into `/etc/kde/plasma-screenlocker//config` and have 
the KCM write to that file and have the screenlocker read information from 
there. It's still a hack, but I think it's a better one than having rood fiddle 
with stuff in /home.
On the general usecase, I think it really adds just marginal additional 
security, and personally I would ignore this particular attack vector with the 
same reasoning @davidedmundson already outlined. On the other hand though, 
every bit of additional security might be a good thing, and a fully-sandboxed 
world won't happen on the Linux desktop within the next years, so if a good 
solution can be found, we should use it.


REPOSITORY
  rKSCREENLOCKER KScreenLocker

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, bshah, colomar, davidedmundson
Cc: mak, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: KDE Discover binary & library names

[Matthias Klumpp]

2016-01-11 16:34 GMT+01:00 Ivan Čukić :
>> As a maintainer, I say no. Because it's just not my goal, I think that
>> being part of Plasma makes it a more appealing product.
>
> Ok, got you :)

GNOME-Software supports "profiles" for other desktop environments,
which mostly means that it stops preferring GNOME apps over other apps
in search results.
One could also implement slight variations in functionality in
Discover, depending on the detected DE, to make it possible for other
DEs to use Discover (e.g. not show Plasmoids on LXQt).
The primary goal should be designing for Plasma though, with any other
functionality not interfering with that goal - I fully agree with
Aleix on that :-)

Cheers,
Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126268: Move shutdown scripts into ksmserver cleanup

[Matthias Klumpp]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126268/#review89227
---

Ship it!


Good thing!
I wasted a few hours yesterday in finding out why this works, just to come to 
the conclusion that it can't possibly work.
Thank you for the explanation, this does make more sense to me now :)

- Matthias Klumpp


On Dez. 7, 2015, 12:26 vorm., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126268/
> ---
> 
> (Updated Dez. 7, 2015, 12:26 vorm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Shutdown scripts are done by startkde after ksmserver quits. Which never
> happens because we've told systemd to shutdown.
> 
> Old systems worked because they used to communicate with the display
> manager which then closed us before shutting down, this is no longer the
> case.
> 
> This moves handling the shutdown scripts into ksmserver (which already
> handles startup scripts) and runs them before asking logind to shutdown.
> 
> BUG: 356190
> 
> 
> Diffs
> -
> 
>   ksmserver/server.h 1a2f0810c53d508d7d721fb4be1c25f0585c0602 
>   ksmserver/server.cpp 9477e542399ad65f993e581fc4212883f282b70e 
>   startkde/startkde.cmake 41a8975cce1fb2a4e7a034e697ce6e2cc59d5b1e 
>   startkde/startplasma.cmake 8360a636d3f68c957a15158484360a611cfe3ff8 
> 
> Diff: https://git.reviewboard.kde.org/r/126268/diff/
> 
> 
> Testing
> ---
> 
> had a shutdown script to touch a file in my home, worked for shutdown and 
> logout.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

[Matthias Klumpp]

> On Nov. 19, 2015, 5:31 nachm., Matthias Klumpp wrote:
> > Okay, I talked to some GNOME people (thanks!) to find out how they handle 
> > this issue, and the short answer is: Not at all
> > Reason for that is that it is really hard to fully secure the compositor if 
> > we allow apps to arbitrarily write to config files in HOME.
> > For example, one process might start to ptrace kwin, catching all input 
> > sent through it. Or someone might install a malicious KWin script. Or the 
> > bad app might install a .desktop file override in .local/share/applications 
> > overriding e.g. Firefox and then catching all the input. Etc.
> > Also, if the attacker went this far, they already have access to all files 
> > in the home directory and likely have reached their goal already.
> > 
> > So, I think we can get KWin secure by adding some really heavy 
> > countermeasures (restricting it's access to $HOME, using a setgid bit on 
> > it's binary, ...) the question is: Is this effort worth it?
> 
> Martin Gräßlin wrote:
> Thanks for asking.
> 
> > Not at all
> 
> I already feared that this would be the answer
> 
> > if we allow apps to arbitrarily write to config files in HOME.
> 
> I don't think this is an issue in the case of KWin.
> 
> > ptrace kwin
> 
> At least on Ubuntu one needs to be root to e.g. attach gdb to the 
> process. Might be an idea to get this into all distros.
> 
> > Or someone might install a malicious KWin script
> 
> KWin scripts are fine (both QScript based scripts and effects). QML based 
> scripts are problematic at the moment (will be hardened). QML based 
> decorations (and decorations in general) are not a problem. I spent quite 
> some time thinking about what is dangerous in KWin and what isn't ;-)
> 
> > Or the bad app might install a .desktop file override in 
> .local/share/applications overriding e.g. Firefox and then catching all the 
> input.
> 
> That's obvious, but our launcher got hardened against such things years 
> ago (see https://www.purinchu.net/wp/2009/02/21/desktop-file-security/ )
> 
> > they already have access to all files in the home directory and likely 
> have reached their goal already
> 
> I disagree on that. This was the approach on X - hey we don't have to do 
> security, because heck X is broken anyway. I really think we should prevent 
> the keylogger scenario.
> 
> > Is this effort worth it?
> 
> Yes, if it makes it impossible to get a keylogger it's worth it.

> Yes, if it makes it impossible to get a keylogger it's worth it.

I figured you'd say that :-D
So, I think the `env -i` workaround is something reasonable to do - given how 
things look currently, I'd say commit it and we'll see what breaks - changes 
can always be reverted, if they prove to result in more problems than expected.

I bet things like SELinux will prevent ptrace on distros using it as well, if 
they don't already have other countermeasures.
Having looked at KDE/Plasma startup *again*, I am really itching to pursue the 
startup refactoring further (rough idea is to get rid of kwrapper5, kinit, 
ksmserver and the shell scripts and have one service managing the whole 
session). That unfortunately has to wait until I have more time for it...


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88620
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables a

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

[Matthias Klumpp]

> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
> > Woundn't this break user's workflow?
> 
> Yes, but what do you prefer? Breaking user's workflows or a secure system?
> 
> There is nothing wrong of course with sourcing the env scripts in 
> startplasma again and distributions using things like /etc/profile.d would be 
> advised to do exactly that.
> 
> Alex Richardson wrote:
> I don't see how this adds any security if you still keep $PATH. what if 
> the user prepends `$HOME/my-evil-binaries/` to $PATH?
> Maybe it makes more sense to restrict which scripts are executed before 
> kwin launches?

Maybe starting a session manager as the first thing makes sense. That one can 
then spawn KWin and KWin can tell the service to start plasmashell when it's 
ready.
Reminds me that I wanted to redesign the KDE startup process a while ago, 
getting rid of most of the scripts. A `systemd --user` based startup could do 
the exact same, btw.
Unsetting most vars will break assumptions, but since this affects only 
Wayland, it's probably okay for a little bit of breakage to exist, although if 
we can avoid that we should try to avoid breaking things.
Generally I agree with Martin: Security >> Breaking Workflows >> 
Backwards-Compatibility


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

[Matthias Klumpp]

> On Nov. 19, 2015, 12:26 nachm., Sebastian Kügler wrote:
> > Possibly naive question: How would I use it with my custom-build setup, 
> > where I need vars like QT_PLUGIN_PATH, etc. set to be able to start the 
> > binaries at all?
> 
> Martin Gräßlin wrote:
> I don't have a solution for it yet and yes it also affects my setup. I 
> hope qt.conf can be used, but I don't know yet.

A possible solution to that problem is to allow setting this in a system-wide 
configuration file, or create a special KDE-specific configuration which sets 
the script to a "debug mode", which doesn't filter env vars.
The important thing is that you need root access to modify these settings (set 
it to debug mode or set additional variables).


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88591
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

[Matthias Klumpp]

> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma

Urgh, terrible! But I think this might just be the best workaround we can come 
up with, given the circumstances. It at least protects against someone adding 
new env vars which load bad code into the compositor. It might be an issue as 
soon as kwin starts to require another env var which isn't in the list, but 
that's an issue we can solve.
I wonder if we can simplify that command somehow, though, e.g. by placing the 
allowed variables in a file or new variable, to make this easier to read.
Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
someone has come up with a bettr solution to this issue).


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> -------
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without so

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

[Matthias Klumpp]

> On Nov. 19, 2015, 2:08 nachm., Matthias Klumpp wrote:
> > Did you consider running the whole script with `env -i`, or (likely the 
> > better idea) run KWin with `env -i`?
> > That should sanitize the environment (unset all env vars, except for 
> > shell-defaults). You could then set exactly the variables you need, to the 
> > exact values you want, so we don't miss unsetting anything.
> 
> Martin Gräßlin wrote:
> No I didn't consider that, because I wasn't aware that this exists.
> 
> Martin Gräßlin wrote:
> Just tried with changing directly in the wayland session file. That 
> doesn't work at all. I think the main problem is that I lose important env 
> variables related to the logind session/dbus, etc.
> 
> So only way would be for the command to start kwin_wayland. But that as 
> well would require to set quite an amount of env variables, but worth a try.
> 
> Martin Gräßlin wrote:
> Just gave a try - the command looks horrible, but I got the session 
> started and env variables are properly filtered.
> 
> Command looks like this now:
> /usr/bin/env -i KDE_FULL_SESSION=true KDE_SESSION_VERSION=5 
> KDE_SESSION_UID=${KDE_SESSION_UID} XDG_CURRENT_DESKTOP=KDE 
> QT_QPA_PLATFORM=wayland PAM_KWALLET5_LOGIN=${PAM_KWALLET5_LOGIN} USER=${USER} 
> LANGUAGE=${LANGUAGE} XDG_SEAT=${XDG_SEAT} 
> XDG_SESSION_TYPE=${XDG_SESSION_TYPE} XCURSOR_SIZE=${XCURSOR_SIZE} 
> HOME=${HOME} DESKTOP_SESSION=${DESKTOP_SESSION} 
> XDG_SEAT_PATH=${XDG_SEAT_PATH} 
> DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS} LOGNAME=${LOGNAME} 
> XDG_SESSION_CLASS=${XDG_SESSION_CLASS} XDG_SESSION_ID=${XDG_SESSION_ID} 
> PATH=${PATH} XDG_SESSION_PATH=${XDG_SESSION_PATH} 
> XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR} XCURSOR_THEME=${XCURSOR_THEME} 
> LANG=${LANG} XDG_SESSION_DESKTOP=${XDG_SESSION_DESKTOP} 
> XCURSOR_PATH=${XCURSOR_PATH} XDG_VTNR=${XDG_VTNR} PWD=${PWD} 
> XDG_DATA_DIRS=${XDG_DATA_DIRS} XDG_CONFIG_DIRS=${XDG_CONFIG_DIRS} 
> @KWIN_WAYLAND_BIN_PATH@ --xwayland --libinput 
> --exit-with-session=@CMAKE_INSTALL_FULL_LIBEXECDIR@/startplasma
> 
> Matthias Klumpp wrote:
> Urgh, terrible! But I think this might just be the best workaround we can 
> come up with, given the circumstances. It at least protects against someone 
> adding new env vars which load bad code into the compositor. It might be an 
> issue as soon as kwin starts to require another env var which isn't in the 
> list, but that's an issue we can solve.
> I wonder if we can simplify that command somehow, though, e.g. by placing 
> the allowed variables in a file or new variable, to make this easier to read.
> Apart from that, +1 from me (I'll take a look at other DEs though, maybe 
> someone has come up with a bettr solution to this issue).
> 
> Xuetian Weng wrote:
> Woundn't this break user's workflow? Since startplasma is started by 
> kwin, the environment variable for the desktop will be derived from that.
> 
> If distribution has some global configuration under /etc/profile.d (which 
> is really common, e.g. openjdk, mozilla plugin path), they will not be set.
> 
> Martin Gräßlin wrote:
> > Woundn't this break user's workflow?
> 
> Yes, but what do you prefer? Breaking user's workflows or a secure system?
> 
> There is nothing wrong of course with sourcing the env scripts in 
> startplasma again and distributions using things like /etc/profile.d would be 
> advised to do exactly that.
> 
> Alex Richardson wrote:
> I don't see how this adds any security if you still keep $PATH. what if 
> the user prepends `$HOME/my-evil-binaries/` to $PATH?
> Maybe it makes more sense to restrict which scripts are executed before 
> kwin launches?
> 
> Matthias Klumpp wrote:
> Maybe starting a session manager as the first thing makes sense. That one 
> can then spawn KWin and KWin can tell the service to start plasmashell when 
> it's ready.
> Reminds me that I wanted to redesign the KDE startup process a while ago, 
> getting rid of most of the scripts. A `systemd --user` based startup could do 
> the exact same, btw.
> Unsetting most vars will break assumptions, but since this affects only 
> Wayland, it's probably okay for a little bit of breakage to exist, although 
> if we can avoid that we should try to avoid breaking things.
> Generally I agree with Martin: Security >> Breaking Workflows >> 
> Backwards-Compatibility

@Alex: KWin is started with an absolute path now, which makes $PATH and aliases 
irrelevant. So that particular issue is solved :)


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewb

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

[Matthias Klumpp]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88597
---


Did you consider running the whole script with `env -i`, or (likely the better 
idea) run KWin with `env -i`?
That should sanitize the environment (unset all env vars, except for 
shell-defaults). You could then set exactly the variables you need, to the 
exact values you want, so we don't miss unsetting anything.

- Matthias Klumpp


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

[Matthias Klumpp]

> On Nov. 19, 2015, 12:26 nachm., Sebastian Kügler wrote:
> > Possibly naive question: How would I use it with my custom-build setup, 
> > where I need vars like QT_PLUGIN_PATH, etc. set to be able to start the 
> > binaries at all?
> 
> Martin Gräßlin wrote:
> I don't have a solution for it yet and yes it also affects my setup. I 
> hope qt.conf can be used, but I don't know yet.
> 
> Matthias Klumpp wrote:
> A possible solution to that problem is to allow setting this in a 
> system-wide configuration file, or create a special KDE-specific 
> configuration which sets the script to a "debug mode", which doesn't filter 
> env vars.
> The important thing is that you need root access to modify these settings 
> (set it to debug mode or set additional variables).
> 
> Aleix Pol Gonzalez wrote:
> Wouldn't specifying them in /etc/profile.d/ work?
> 
> Currently I use it and it works fine:
> ```
> $ cat /etc/profile.d/kde5.sh 
> source ~kde-devel/kdescripts/deploykde5.sh
> ```

Not having tried this, it *should* work.
For Limba, which had a suid-root helper a while ago which was launched by the 
user, I once wrote a wrapper which filtered the environment and allowed only 
specific env-vars/values to exist. After cleaning up the environment, the 
wrapper execv'ed the real binary, replacing the wrapper process image with the 
real process. This has now been replaced with a much better solution not using 
this hackish approach anymore, but I wonder if it's something like this that we 
actually need, since this gives us full control over the environment of new 
processes.
(I am kind of curious now how GNOME handles this... Maybe I'll ask ^^)


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88591
---


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126115: Unset environment variables before starting kwin_wayland

[Matthias Klumpp]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126115/#review88620
---


Okay, I talked to some GNOME people (thanks!) to find out how they handle this 
issue, and the short answer is: Not at all
Reason for that is that it is really hard to fully secure the compositor if we 
allow apps to arbitrarily write to config files in HOME.
For example, one process might start to ptrace kwin, catching all input sent 
through it. Or someone might install a malicious KWin script. Or the bad app 
might install a .desktop file override in .local/share/applications overriding 
e.g. Firefox and then catching all the input. Etc.
Also, if the attacker went this far, they already have access to all files in 
the home directory and likely have reached their goal already.

So, I think we can get KWin secure by adding some really heavy countermeasures 
(restricting it's access to $HOME, using a setgid bit on it's binary, ...) the 
question is: Is this effort worth it?

- Matthias Klumpp


On Nov. 19, 2015, 12:22 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126115/
> ---
> 
> (Updated Nov. 19, 2015, 12:22 nachm.)
> 
> 
> Review request for Plasma, David Edmundson and Matthias Klumpp.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Any environment variable which can be used to specify a path to a
> binary object to be loaded in the KWin process bears the risk of
> being abused to add code to KWin to perform as a key logger.
> 
> E.g. an env variable pointing QT_PLUGIN_PATH to a location in $HOME
> and adjusting QT_STYLE_OVERRIDE to load a specific QStyle plugin from
> that location would allow to easily log all keys without KWin noticing.
> 
> As env variables can be specified in scripts sourced before the session
> starts there is not much KWin can do about that to protect itself.
> 
> This affects all the LD_* variables and any library KWin uses and
> loads plugins.
> 
> The list here is based on what I could find:
> * LD_* variables as specified in the man page
> * LIBGL_* and EGL_* as specified on mesa page
> * QT_* variables based on "git grep qgetenv" in qtbase and qtdeclarative
>   combined with Qt's documentation
> * "git grep getenv" in various KDE frameworks based on ldd output of KWin
> 
> Unfortunately the list is unlikely to be complete. If one env variable is
> missed, there is a risk. Even more each change in any library might
> introduce new variables.
> 
> The approach is futile, but needed till Linux has a secure way to start
> the session without sourcing env variable scripts from user owned
> locations.
> 
> 
> Diffs
> -
> 
>   startkde/startplasmacompositor.cmake 
> 1e46e5be0a0d733fb01e1a87a34ee3c73a06bf8c 
> 
> Diff: https://git.reviewboard.kde.org/r/126115/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126102: [startkde] Move sourceing of env scripts to startplasma

[Matthias Klumpp]

> On Nov. 18, 2015, 2:57 nachm., Matthias Klumpp wrote:
> > It just wanted to write what David wrote ;-)
> > Maybe a way to resolve this is to filter environment variables in KWin or 
> > before starting KWin, so anything pointing to directories in $HOME gets 
> > stripped away (unsetting LD_* variables might also be part of that).
> 
> Martin Gräßlin wrote:
> well that are many possible variables and it might be a terrible catch up 
> game with any new variable Qt includes. It at least would affect:
> - LD_LIBRARY_PATH
> - QT_PLUGIN_PATH
> - PATH
> - LD_PRELOAD (see general LD_PRELOAD Wayland keylogger hack)
> - some QML variables which I don't know right now
> - anything else I don't remember right now
> - any aliases (one could do alias kwin_wayland="something evil"
> - any bash functions.
> 
> Ideally there just shouldn't be any scripts sourced before kwin gets 
> started

I was thinking more of an "unset all => set what's needed" workflow. Aliases 
can be worked around by giving absolute paths in the script.
Still, it isn't nice and unfortunately some of those scripts need to be sourced 
because of $HISTORIC_REASON or simply because users expect it, or - in case of 
.pam_environment - because it's a global distro default.
The only way around that would be starting KWin before SDDM starts (which would 
have it's own problems, as far as I can see).
Meh :-/


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126102/#review88528
---


On Nov. 18, 2015, 8:18 vorm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126102/
> ---
> 
> (Updated Nov. 18, 2015, 8:18 vorm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This change makes sure that the environment scripts are not sourced
> before KWin is started. No user installed scripts are allowed to modify
> KWin's environment as that opens an attack vector.
> 
> For example any binary plugin loaded into KWin (be it QStyle, QPT plugin,
> etc.) is able to become a key logger. If the env variables were allowed
> to be sourced before KWin is started a malicious application run as user
> (e.g. exploiting browser vulnerability) would be able to install a key
> logger. Required steps:
> 1. install a malicious QStyle plugin somewhere in $HOME
> 2. place a script in env to adjust variables to load the QStyle plugin
> 
> This would be enough to have a key logger on next login.
> 
> Given that the startup of KWin must not be affected by any scripts
> owned by user prior to startup.
> 
> The env scripts are now sourced as first step of startplasma, so
> for applications in the session there is no difference.
> 
> 
> Diffs
> -
> 
>   startkde/startplasma.cmake 8360a636d3f68c957a15158484360a611cfe3ff8 
>   startkde/startplasmacompositor.cmake 
> 8b5db615142455fd360c66504fc5d5a7754a029c 
> 
> Diff: https://git.reviewboard.kde.org/r/126102/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 126102: [startkde] Move sourceing of env scripts to startplasma

[Matthias Klumpp]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126102/#review88528
---


It just wanted to write what David wrote ;-)
Maybe a way to resolve this is to filter environment variables in KWin or 
before starting KWin, so anything pointing to directories in $HOME gets 
stripped away (unsetting LD_* variables might also be part of that).

- Matthias Klumpp


On Nov. 18, 2015, 8:18 vorm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126102/
> ---
> 
> (Updated Nov. 18, 2015, 8:18 vorm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This change makes sure that the environment scripts are not sourced
> before KWin is started. No user installed scripts are allowed to modify
> KWin's environment as that opens an attack vector.
> 
> For example any binary plugin loaded into KWin (be it QStyle, QPT plugin,
> etc.) is able to become a key logger. If the env variables were allowed
> to be sourced before KWin is started a malicious application run as user
> (e.g. exploiting browser vulnerability) would be able to install a key
> logger. Required steps:
> 1. install a malicious QStyle plugin somewhere in $HOME
> 2. place a script in env to adjust variables to load the QStyle plugin
> 
> This would be enough to have a key logger on next login.
> 
> Given that the startup of KWin must not be affected by any scripts
> owned by user prior to startup.
> 
> The env scripts are now sourced as first step of startplasma, so
> for applications in the session there is no difference.
> 
> 
> Diffs
> -
> 
>   startkde/startplasma.cmake 8360a636d3f68c957a15158484360a611cfe3ff8 
>   startkde/startplasmacompositor.cmake 
> 8b5db615142455fd360c66504fc5d5a7754a029c 
> 
> Diff: https://git.reviewboard.kde.org/r/126102/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: RFC: Disable DrKonqi

[Matthias Klumpp]

2015-11-17 8:52 GMT+01:00 Martin Graesslin :
> On Monday, November 16, 2015 11:58:45 AM CET Weng Xuetian wrote:
>> Just FYI, on a systemd based system, the coredump is already
>> automatically stored in journal and can be accessed easily by
>> coredumpctl.
>
> Good to know. That could make my life easier :-)

As long as that part of systemd is installed ;-) In Debian, we've
recently split it out, since the kernel can only have one coredump
handler registered at a time. That means we can reflect that at the
package-level, by having a "systemd-coredump" package conflict with
potential other coredump handlers.
That being said, I don't want to miss coredumpctl, it's a pretty great tool :-)
There is currently a discussion going on on upstream recommendations
on how to split systemd into different packages, so there is a chance
that a similar split will happen on other distros as well.

Cheers,
 Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 125198: by default do not restore the previous session on next login

[Matthias Klumpp]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125198/#review85310
---


We change this setting in Tanglu as well, because it's really confusing for 
users - they often don't know why stuff gets started automatically.
+1 for the patch, and I also really like the idea of setting a checkbox 
explicitly - then it's clear to the users why things are started automatically 
at login.

- Matthias Klumpp


On Sept. 12, 2015, 3:37 nachm., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125198/
> ---
> 
> (Updated Sept. 12, 2015, 3:37 nachm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> As requested by the VDG.
> Rationale being that starting with an empty session all the time is
> substantially less aggressive than potentially starting a gazillion
> applications slowing down startup and greeting the user with a
> cluttered desktop.
> 
> 
> Diffs
> -
> 
>   ksmserver/main.cpp 4808a80081c3f4322c0d1b3223fc65bcbfeb26c1 
>   ksmserver/shutdown.cpp 636ae66fcce1d5c39fd697925b9094abc44e4808 
> 
> Diff: https://git.reviewboard.kde.org/r/125198/diff/
> 
> 
> Testing
> ---
> 
> installed. wiped ksmserverrc. multiple logins always result in an empty 
> session.
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Splitting (Muon) Discover from muon repository

[Matthias Klumpp]

2015-08-04 21:29 GMT+02:00 Jonathan Riddell j...@jriddell.org:

 As discussed at Akademy that seems fine with me and pretty sensible.
 Muon package manager does have a use case and users, maybe this will
 help it find a maintainer.

Jup, +1 from me too! That change would help a lot in pushing Muon on
non-Kubuntu distributions, and also simplify the packaging a bit (at
least in Tanglu).

 Anyway, I'd like to leave 2 repositories:
 - muon, that will have muon-packagemanager
 - discover, that will have discover and updater. I'd also like to drop
 the Muon part from Discover eventually as well and leave Discover as
 is.

 I guess you mean I'd also like to drop the updater part

The updater was supposed to be merged into Discover, at least that's
the thing we thought about at Akademy.

 [...]

Cheers,
   Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123664: Find DBusAddons component explicitly

[Matthias Klumpp]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123664/
---

(Updated May 6, 2015, 9:47 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Changes
---

Submitted with commit e215432a039c3681d9246ce621f8f50382acc39a by Matthias 
Klumpp to branch master.


Repository: plasma-workspace


Description
---

This apparently causes trouble, since DBusAddons is required by e.g.
appmenu, and not found in every environment.

We stumbled upon this in Tanglu, where plasma-workspace failed to build.
Relevant buildlog excerpts:
```
-- Configuring done
CMake Warning (dev) at appmenu/CMakeLists.txt:24 (add_library):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run cmake --help-policy CMP0028 for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target kded_appmenu links to target KF5::DBusAddons but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at plasma-windowed/CMakeLists.txt:7 (add_executable):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run cmake --help-policy CMP0028 for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target plasmawindowed links to target KF5::DBusAddons but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at freespacenotifier/CMakeLists.txt:9 (add_library):
  Policy CMP0028 is not set: Double colon in target name means ALIAS or
  IMPORTED target.  Run cmake --help-policy CMP0028 for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  Target kded_freespacenotifier links to target KF5::DBusAddons but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.
[...]
```
```
[ 87%] Building CXX object appmenu/CMakeFiles/kded_appmenu.dir/appmenu.cpp.o
cd appmenu  /usr/bin/c++   -DKCOREADDONS_LIB -DKGUIADDONS_LIB -DQT_CORE_LIB 
-DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0 -DQT_GUI_LIB -DQT_NETWORK_LIB 
-DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_X11EXTRAS_LIB 
-DQT_XML_LIB -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -Dkded_appmenu_EXPORTS -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-D_FORTIFY_SOURCE=2  -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align 
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -fPIC 
-fvisibility=hidden -fvisibility-inlines-hidden -I. -I../../appmenu -I.. 
-isystem /usr/include/dbusmenu-qt5 -isystem /usr/include/x86_64-linux-gnu/qt5 
-isystem /usr/include/x86_64-linux-gnu/qt5/QtDBus -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtX11Extras -isystem /usr/include/x86_64-lin
 ux-gnu/qt5/QtGui -isystem /usr/include/KF5/KIOCore -isystem /usr/include/KF5 
-isystem /usr/include/KF5/KCoreAddons -isystem /usr/include/KF5/KService 
-isystem /usr/include/KF5/KConfigCore -isystem /usr/include/KF5/KIOWidgets 
-isystem /usr/include/KF5/KJobWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/KF5/KCompletion -isystem /usr/include/KF5/KWidgetsAddons -isystem 
/usr/include/KF5/KWindowSystem -isystem /usr/include/KF5/KDELibs4Support 
-isystem /usr/include/KF5/KDELibs4Support/KDE -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -isystem 
/usr/include/KF5/KCrash -isystem /usr/include/KF5/KConfigWidgets 
-I/usr/include/KF5/KCodecs -I/usr/include/KF5/KConfigGui 
-I/usr/include/x86_64-linux-gnu/qt5/QtXml -I/usr/include/KF5/KAuth -isystem 
/usr/include/KF5/KIOFileWidgets -I/usr/include/KF5/KBookmarks 
-I/usr/include/KF5/KItemViews -I/usr/include/KF5/KXmlGui 
-I/usr/include/KF5/Solid -isystem /us
 r/include/KF5/KI18n -isystem /usr/include/KF5/KNotifications -isystem 
/usr/include/KF5/KIconThemes -isystem /usr/include/KF5/KGuiAddons -isystem 
/usr/include/KF5/KUnitConversion -isystem /usr/include/KF5/KTextWidgets 
-I/usr/include/KF5/SonnetUi -isystem /usr/include/KF5/KParts-o 
CMakeFiles/kded_appmenu.dir/appmenu.cpp.o -c ../../appmenu/appmenu.cpp
In file included from ../../appmenu/appmenu.cpp:26:0:
../../appmenu/appmenu.h:29:24: fatal error: kdedmodule.h

Review Request 123664: Find DBusAddons component explicitly

[Matthias Klumpp]

-workspace_5.3.0-0tanglu1_amd64.146006.log


Diffs
-

  CMakeLists.txt 5180bac 

Diff: https://git.reviewboard.kde.org/r/123664/diff/


Testing
---

plasma-workspace compiles and works fine.


Thanks,

Matthias Klumpp

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Systemd kcm module - inclusion in Plasma?

[Matthias Klumpp]

2015-04-29 18:21 GMT+02:00 Ragnar Thomsen rthoms...@gmail.com:
 On Wed, Apr 29, 2015 at 4:10 PM, Martin Gräßlin mgraess...@kde.org wrote:
 Just run kdesrc-build and gave it a try and was greeted with an error 
 message:
 http://paste.opensuse.org/54725251

 That's on a Debian stable/testing system and the file does not exist. As that
 file is missing on that distribution an error message is wrong ;-) Otherwise 
 I
 would also suggest to not use an in-your-face dialog but rather a
 KMessageWidget.

 Thanks for the feedback, Martin. I agree with you about the error
 message and will change this to a KMessageWidget.

FYI, we patch this out of systemd-kcm in Debian at time, since
coredumps aren't (yet?) handled by our systemd.
So maybe instead of displaying an error, just hide the page for coredumpctl?
(Making a check for Debian is also not a good idea, since we might
enable coredumpctl and coredumps-in-journal support at one time in the
future)

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123283: Remove interesting ksmserver easter egg

[Matthias Klumpp]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123283/#review78626
---


:D That's an awesome feature. I guess there's an interesting story behind this, 
when it was implemented (for debugging?).

- Matthias Klumpp


On April 7, 2015, 2:25 nachm., David Edmundson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123283/
 ---
 
 (Updated April 7, 2015, 2:25 nachm.)
 
 
 Review request for Plasma and Lukáš Tinkl.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 KSMSERVER_STARTUP_DEBUGl is not defined, meaning this code currently
 exists in all our ksmservers.
 
 if you have 2 instances of gedit, konqueror and kspaceduel open in the right 
 order on session restore you get
 an error message saying drat. I'm not sure what benefit this is to society, 
 but I'm sure it was important.
 
 This feature is now obsolete as kspaceduel doesn't exist any more and would 
 require more effort to trigger
 
 
 Diffs
 -
 
   ksmserver/startup.cpp 6010eff 
 
 Diff: https://git.reviewboard.kde.org/r/123283/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 David Edmundson
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 123283: Remove interesting ksmserver easter egg

[Matthias Klumpp]

 On April 7, 2015, 2:31 nachm., Matthias Klumpp wrote:
  :D That's an awesome feature. I guess there's an interesting story behind 
  this, when it was implemented (for debugging?).

Just to be clear, that's no objection to the patch - please kill this thing ;-)


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123283/#review78626
---


On April 7, 2015, 2:25 nachm., David Edmundson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123283/
 ---
 
 (Updated April 7, 2015, 2:25 nachm.)
 
 
 Review request for Plasma and Lukáš Tinkl.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 KSMSERVER_STARTUP_DEBUGl is not defined, meaning this code currently
 exists in all our ksmservers.
 
 if you have 2 instances of gedit, konqueror and kspaceduel open in the right 
 order on session restore you get
 an error message saying drat. I'm not sure what benefit this is to society, 
 but I'm sure it was important.
 
 This feature is now obsolete as kspaceduel doesn't exist any more and would 
 require more effort to trigger
 
 
 Diffs
 -
 
   ksmserver/startup.cpp 6010eff 
 
 Diff: https://git.reviewboard.kde.org/r/123283/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 David Edmundson
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Project: libmuon package install for 3rd party applications

[Matthias Klumpp]

2015-03-13 14:32 GMT+01:00 Jonathan Riddell j...@jriddell.org:
 [...]
 PS: A good GSoC would be to make sure that Appstream can finally be
 adopted properly in Kubuntu

 While this would be lovely it would probably require a lot of
 coordination in debian, launchpad and ubuntu. It feels like a full
 time job :(

Well... I had a GSoC student last year who implemented some of tbe
parts necessary for this feature, and I just submitted a patch to
Debian's dak which will make AppStream work on Debian immediately.
Some coordination and development work is still necessary, but all the
hard parts are done.
I also wrote a Python module which makes it easier to integrate
AppStream into any Debian repository service (I am thinking about
reprepro and Launchpad here).
The Tanglu Linux distribution[1] already uses a lot of this new code
(minus the dak generator bits)
Having AppStream working well is one of my personal release goals for
Debian 9 (Stretch), so it's safe to say that we'll have it soon.
If you know anyone at Ubuntu who wants to talk about AppStream
integration, just point them at me - I'd be glad to help (although my
primary priority is Debian at time).

 Maybe it's just for full package managers that it's an issue and it
 would work fine for this use case.  The packagekit in Ubuntu is being
 held back but chatting today with ubuntu people it could be updated to
 packagekit 0.9 which is what kicker needs and I guess other places
 where this would be useful.

Yeah, annoyingly the support for plugins was removed in PK 1.0. We had
a chat about that upstream, especially since my 3rd-party
app-installer Listaller depended on this feature for system
integration[2]. But the PK maintainer really wanted to get rid of that
feature for stability reasons. Unfortunately, Ubuntu's Click
installer uses the old Listaller code to hook into PackageKit as a
plugin, that's why Ubuntu can't live without it.
When Jessie was pre-freeze I had the nice option of including 1.0 and
breaking Listaller and other stuff, or not including it and having to
maintain 0.9 (1.0 has the much nicer codebase).
In general, there are issues at Ubuntu, but I believe all of that can
be solved relatively easily. In any case, it's safe to use
libpackagekit-glib2 and libpackagekit-qt there :)

Cheers,
Matthias



[1]: http://tanglu.org/download/ - we also build snapshots with
Plasma5, full AppStream support is only visible in the GNOME flavor at
time
[2]: This removal, together with a few other reasons, lead to me
rewriting Listaller as Limba, which now needs integration into
software installer clients like GNOME-Software and Muon, instead of
using PackageKit. GNOME meanwhile started some serious work on XdgApp,
so GNOME-Software has the necessary interfaces to support 3rd-party
app-installers. Having support for these projects in KDE/Muon would be
a useful future goal.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Project: libmuon package install for 3rd party applications

[Matthias Klumpp]

2015-03-12 21:00 GMT+01:00 Jonathan Riddell j...@jriddell.org:
 On Thu, Mar 12, 2015 at 08:40:46PM +0100, Matthias Klumpp wrote:
 2015-03-12 20:34 GMT+01:00 Jonathan Riddell j...@jriddell.org:
 [...]
 What's the difference between this and the already existing
 PackageKit(-Qt) and PackageKit session interface? (and the combination
 of it with AppStream to avoid hardcoding a list of packages, as it
 seems to be the plan here (?))

 Mostly it would keep Debian and Kubuntu happier who aren't great fans
 of PackageKit.

Yeah, I am still waiting for bug reports and feature requests for that ;-)
The only thing where PK falls short is for advanced package managers
like Synaptic on Debian, because it doesn't support features like
holding packages etc. But it was never designed for that. (although to
my suprise someone recently submitted a patch to PK to allow
downgrading of packages)

 Using appstream seems sensible, how do I use it to
 find the name of e.g. the samba package?

It would require the distributor or upstream vendor to ship the
metadata[1]. If upstream projects do that, everyone has the required
information, and getting the packages
(e.g. via libappstream-qt) is as simple as
 Database::componentById(samba)-packageNames()

AppStream was not only designed for applications, but also to fetch
metadata about any software component. E.g. it is already used for
input-methods, fonts and firmware.

 The other half of the
 project would be to implement this in the various places that KDE
 software needs it which nobody seems to have done yet.

Finding places where KDE software could benefit from it would also be
quite a challenge (it's not documented, and lots of software silently
works around missing components).

Cheers,
Matthias

[1]: 
http://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Project: libmuon package install for 3rd party applications

[Matthias Klumpp]

Hi!

2015-03-12 20:34 GMT+01:00 Jonathan Riddell j...@jriddell.org:
 Aleix et al: what do you think of this?

 https://community.kde.org/GSoC/2015/Ideas#Project:_libmuon_package_install_for_3rd_party_applications

 adapting muon so its library can be used by external apps to install
 packages?

What's the difference between this and the already existing
PackageKit(-Qt) and PackageKit session interface? (and the combination
of it with AppStream to avoid hardcoding a list of packages, as it
seems to be the plan here (?))

Cheers,
Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Muon and kde-gtk-config moved to kde/workspace - was - Re: Moving repositories in the module structure

[Matthias Klumpp]

2014-10-06 19:57 GMT+02:00 Albert Astals Cid aa...@kde.org:
 El Dilluns, 6 d'octubre de 2014, a les 01:30:47, Aleix Pol va escriure:
 [...]
 I don't expect to compete with Apper. Muon Discover is a software center
 and that's the main solution I'm pushing here, as I explained in Plasma.
 Apper is a package manager. That is, a way where we can display to our
 end-users what software there's available and also lets us a couple of
 tricks to get biased.
I (as Apper contributor) would disagree with that - Daniel renamed
KPackageKit to Apper years ago to stress that Apper is not about
packages, but especially about applications. Unlike Muon or GNOME
Software, the goal for Apper is to manage packages and apps in one UI
though - and of course, Apper provides the session interface for
PackageKit, which Muon does not (yet?).
Does Muon work well with PackageKit on !Debian-based distros? I had
lots of trouble with porting the Ubuntu Software Center to PK, since
PK uses a completely different paradigm and API, compared to the
Aptdaemon interface the USC used, so it would have required a complete
rewrite.
Last time I looked at QApt, it looked slightly more similar to Aptd
compared to the PK API.
(I'll soon test Muon on Fedora by myself, but more from an what can
be improved in AppStream? PoV)

 I think this is very important, because it opens an opportunity to offer
 the end-user the full KDE experience we've been talking about. So far, the
 way everyone had to expose software was by creating a (usually spin-off)
 distribution where there was tons of software pre-installed. By providing a
 software center we open channels to communicate with the user where he can
 leverage on previous' users experience, as well as our own.

 I'm not sure I understand the difference between a Software Center and a
 Package Manager, can you elaborate what is the difference?
Software Center almost always means that it shows GUI apps instead of
packages, where app is more tightly defined as stuff which ship a
.desktop file in share/applictions with Type=application.
Package Managers display all kinds of packages on the system,
including debug symbol packages and e.g. header packages.
The Software Centers are generally thought to be more end-user
friendly, while package managers have a technically advanced user as
target audience.
Cheers,
Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Moving kde:muon repository to kde/workspaces

[Matthias Klumpp]

2014-09-26 16:50 GMT+02:00 David Edmundson da...@davidedmundson.co.uk:
 Makes sense to me.

 Gnome are touting their app installer, so it won't be particularly
 controversial for upstream to start doing package management UIs.
Actually, this is pretty welcomed! :-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120318: PoC: Package Manager integration for the AppsModel

[Matthias Klumpp]

 On Sept. 22, 2014, 3:38 nachm., Martin Gräßlin wrote:
  I like the idea!
  
  Suggestion for the which package manager to use part: add a package 
  manager selection to the defaults application KCM and use the one which is 
  configured there. Distros should be able to easily configure the one they 
  are using then.
 
 Aleix Pol Gonzalez wrote:
 Why would distros need a GUI for configuring it?
 
 Martin Gräßlin wrote:
 distros don't need the GUI, but the kconfig key. Some distros provide 
 multiple tools, though and then the user might want to be able to configure 
 it.
 
 Eike Hein wrote:
 I was planning to add a config key to Kicker for now, but I agree a more 
 canonical workspace-level key and an API in KToolInvocation would be cool. 
 Next Frameworks release maybe?

In theory, a call on the PackageKit interface should trigger whatever 
implements the PackageKit session DBus interface (on KDE that's only Apper at 
time) to display any GUI dialogs.
But probably showing the application prior to removing it in a software center 
is a good idea anyway :)
Would it make sense to send the application-name to the software center, and 
have it figure out the package name, instead of doing that prior to calling the 
SC? Might be a bit nicer...

As a sidenote: Using LibAppstreamQt could be a future option for resolving 
application-names to packages - depending on the distribution's 
package-manager, calls to SearchFiles() could be a bit slow. Drawback of using 
that lib is that distros need to ship with AppStream metadata, which currently 
only OpenSUSE and Fedora do - Debian will support is soon, and Ubuntu maybe as 
well (both distros currently have partial support via AppInstall data).

That feature looks great, I hope it doesn't conflict with 
http://dantti.wordpress.com/2010/11/25/yup-laziness-is-a-virtue/ , although 
honestly I need to check if that Apper feature actually still works...


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120318/#review67209
---


On Sept. 22, 2014, 3:34 nachm., Aleix Pol Gonzalez wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120318/
 ---
 
 (Updated Sept. 22, 2014, 3:34 nachm.)
 
 
 Review request for Plasma and Eike Hein.
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 I've been discussing with Eike having something like that for a while, I 
 finally managed to put something together that we could use in a future.
 
 It adds an entry on the menu that is called Remove 'packagename' that 
 opens a software center. I set it to muon-discover for now, but this should 
 be iterated over.
 
 To do the lookup, it uses PackageKitQt. It probably should be an optional 
 dependency, but I want Eike to look into it first and decide how to do it 
 best.
 
 
 Diffs
 -
 
   CMakeLists.txt 7b794ff 
   applets/kicker/CMakeLists.txt 0688732 
   applets/kicker/plugin/appsmodel.cpp b88d711 
   applets/kicker/plugin/findpackagenamejob.h PRE-CREATION 
   applets/kicker/plugin/findpackagenamejob.cpp PRE-CREATION 
   config-workspace.h.cmake 58a11d4 
 
 Diff: https://git.reviewboard.kde.org/r/120318/diff/
 
 
 Testing
 ---
 
 I uninstalled openarena, selfcompiled software cannot removed.
 
 The locking is not really noticeable on my system. We still probably want to 
 improve that but I don't think it would be terrible like this, only bad.
 
 
 Thanks,
 
 Aleix Pol Gonzalez
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120318: PoC: Package Manager integration for the AppsModel

[Matthias Klumpp]

 On Sept. 22, 2014, 3:38 nachm., Martin Gräßlin wrote:
  I like the idea!
  
  Suggestion for the which package manager to use part: add a package 
  manager selection to the defaults application KCM and use the one which is 
  configured there. Distros should be able to easily configure the one they 
  are using then.
 
 Aleix Pol Gonzalez wrote:
 Why would distros need a GUI for configuring it?
 
 Martin Gräßlin wrote:
 distros don't need the GUI, but the kconfig key. Some distros provide 
 multiple tools, though and then the user might want to be able to configure 
 it.
 
 Eike Hein wrote:
 I was planning to add a config key to Kicker for now, but I agree a more 
 canonical workspace-level key and an API in KToolInvocation would be cool. 
 Next Frameworks release maybe?
 
 Matthias Klumpp wrote:
 In theory, a call on the PackageKit interface should trigger whatever 
 implements the PackageKit session DBus interface (on KDE that's only Apper at 
 time) to display any GUI dialogs.
 But probably showing the application prior to removing it in a software 
 center is a good idea anyway :)
 Would it make sense to send the application-name to the software center, 
 and have it figure out the package name, instead of doing that prior to 
 calling the SC? Might be a bit nicer...
 
 As a sidenote: Using LibAppstreamQt could be a future option for 
 resolving application-names to packages - depending on the distribution's 
 package-manager, calls to SearchFiles() could be a bit slow. Drawback of 
 using that lib is that distros need to ship with AppStream metadata, which 
 currently only OpenSUSE and Fedora do - Debian will support is soon, and 
 Ubuntu maybe as well (both distros currently have partial support via 
 AppInstall data).
 
 That feature looks great, I hope it doesn't conflict with 
 http://dantti.wordpress.com/2010/11/25/yup-laziness-is-a-virtue/ , although 
 honestly I need to check if that Apper feature actually still works...
 
 Aleix Pol Gonzalez wrote:
 @Klumpp: Well, we still want to do the lookup on the kicker side, because 
 we don't want to show the option in case its not removable. Otherwise we 
 would be rising the user's hopes for little reason.

Ah, right - didn't think about that possibility.


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120318/#review67209
---


On Sept. 22, 2014, 3:34 nachm., Aleix Pol Gonzalez wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120318/
 ---
 
 (Updated Sept. 22, 2014, 3:34 nachm.)
 
 
 Review request for Plasma and Eike Hein.
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 I've been discussing with Eike having something like that for a while, I 
 finally managed to put something together that we could use in a future.
 
 It adds an entry on the menu that is called Remove 'packagename' that 
 opens a software center. I set it to muon-discover for now, but this should 
 be iterated over.
 
 To do the lookup, it uses PackageKitQt. It probably should be an optional 
 dependency, but I want Eike to look into it first and decide how to do it 
 best.
 
 
 Diffs
 -
 
   CMakeLists.txt 7b794ff 
   applets/kicker/CMakeLists.txt 0688732 
   applets/kicker/plugin/appsmodel.cpp b88d711 
   applets/kicker/plugin/findpackagenamejob.h PRE-CREATION 
   applets/kicker/plugin/findpackagenamejob.cpp PRE-CREATION 
   config-workspace.h.cmake 58a11d4 
 
 Diff: https://git.reviewboard.kde.org/r/120318/diff/
 
 
 Testing
 ---
 
 I uninstalled openarena, selfcompiled software cannot removed.
 
 The locking is not really noticeable on my system. We still probably want to 
 improve that but I don't think it would be terrible like this, only bad.
 
 
 Thanks,
 
 Aleix Pol Gonzalez
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Compatibility problems with latest GTK+ applications

[Matthias Klumpp]

2014-05-08 9:31 GMT+02:00 Martin Gräßlin mgraess...@kde.org:
 Martin GräßlinOn Wednesday 07 May 2014 10:11:37  wrote:
 Any advice on how to handle this situation is appreciated.

 As several people responded that I should report the issues I just did that
 and reported the following bug reports against GTK:

 * CSD styled windows don't react on compositing changes [1]
 * Double decorated windows [2]
 * CSD styled windows do not detect when re-parented to a decoration [3]
 * CSD context menu ignores _NET_ALLOWED_ACTIONS [4]
 * CSD context menu doesn't use _NET_DESKTOP_NAMES [5]
 * CSD context menu doesn't honor _NET_DESKTOP_LAYOUT [6]
 * Shadow included in CSD window [7]
 * Window disappears when middle clicking client side decoration [8]
 * Missing maximize and minimize buttons in client side decoration [9]
 * Decoration buttons do not follow custom specified layout in desktop
 environment [10]
 * A hung GTK application cannot be closed [11]
 * Context menu on window decoration is not the one of the environment [12]
 * No time based drag delay on window moving [13]
 * No drag delay on window resize [14]
That is pretty great, thank you for taking the time! Some of these
things unfortunately are design-decisions by GNOME, which I raised in
IRC discussions a while ago, and where I think the interest is pretty
low for fixing them (after getting some feedback on e.g. the CSD
menus).
However, to support the cross-desktop efforts, the GNOME people should
maybe make a few compromises (e.g. make GTK+ behave differently on
other DEs), especially since GTK+ is not just for GNOME but also used
by other projects.
Let's see what happens :-)
Cheers,
   Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Re: An alternative for XEmbed

[Matthias Klumpp]

2014-04-15 15:03 GMT+02:00 Mark Gaiser mark...@gmail.com:
 [...]

 Idea..

 Can you somehow detect if an application wants to do XEmbed stuff? If
 it wants to while there is no wmsystemtray configured you should
 annoy the user and ask if we should enable the wmsystemtray for him
 automatically since an app wants to make use of it. Obviously if other
 apps also use xembed and wmsystemtray is enabled then you should not
 bother the user.

 I think this gives the best of both worlds.
 - wmsystemtray is gone by default but added when needed
 - those apps that still use xembed will remain working just fine
 - novice users don't have to bother about manually installing wmsystemtray

 You should definitely not place the burden of installing wmsystemtray
 on the user imho.
It's more for putting pressure on the developers, I guess. If there is
an easily accessible workaround, developers will not switch to a
modern solution quickly, because a workaround is trivial to do for the
users.
Also, users don't put pressure on e.g. vendors of proprietary applications.
What might make sense is that the distributor installs this stuff
automatically in case some application is installed which won't ship
without XEmbed stuff in the near future.
It would be interesting to know how many apps would be affected by
missing XEmbed-systray. If it's not many, adding and easy workaround
is IMHO not a good idea. If there are more of these apps, I think
adding your solution temporarily would make seome sense indeed.
Cheers,
Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 117312: Disable PackageKit integration

[Matthias Klumpp]

 On April 2, 2014, 9:44 a.m., Marco Martin wrote:
  Now no packagekit warning should happen anymore, even with the integration 
  enabled

Good :-)
With my PK-upstream hat on:
If you have problems with integrating PackageKit or miss functionality, please 
let me know.
(the issue above looked like a missing check before performing a PK query)


- Matthias


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117312/#review54854
---


On April 1, 2014, 9:48 p.m., Hrvoje Senjan wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/117312/
 ---
 
 (Updated April 1, 2014, 9:48 p.m.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-framework
 
 
 Description
 ---
 
 imho, it doesn't make sense at this stage, and just spams people that have PK 
 installed...
 
 
 Diffs
 -
 
   src/plasma/CMakeLists.txt 90c020e 
 
 Diff: https://git.reviewboard.kde.org/r/117312/diff/
 
 
 Testing
 ---
 
 builds. before the patch -DPLASMA_ENABLE_PACKAGEKIT_SUPPORT=1 definition was 
 added, no definition w/ patch
 
 
 Thanks,
 
 Hrvoje Senjan
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: kill the systray?

[Matthias Klumpp]

2013/9/25 Martin Gräßlin mgraess...@kde.org:
 On Thursday 26 September 2013 01:27:54 Aaron J. Seigo wrote:
 On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote:
  When I asked Martin if he knew a way to do the xembed, he replied (being
  Martin ;)) asking if we can just kill it and quoted starwars. I wonder:
  Can
  we kill it yet?

 I just had a discussion on G+ with a couple of our friends with GNOME about
 this matter[1]. Apparently they are thinking of just dropping support for
 system tray icons altogether, and deprecating the API in Gtk+. If that does
 indeed happen, then that is a major step towards being able to kill support
 for it.
 the bad part of the discussion is that it looks like they want to reinvent the
 wheel and given some statements lately (e.g. GTK+ is just for developing for
 GNOME Shell) I'm not every optimistic that they will even hardly think about
 anything than their system.
I also fear that, but this was a statement by single developers, which
I don't think is true.
It would make sense to at least try to discuss stuff and try to find a
consent, and I am willing to try that (there would be no harm done if
this attempt fails).
There are some things which GNOME does great at time (notifications,
IMHO) and which might be worth looking at and working on a common
spec.
The problem with GNOME is that it is now design-driven, and everyone
and everything has to accept a subordinate role to that. So, in order
to convince the GNOME folks, you have to give them a usecase which
matches their design goals.

 The only remaining problem then becomes Qt5. QSystemTrayIcon does not
 support the DBus protocol .. it should, really, since the two largest Linux
 desktop envs built on Qt use it ;)
 looks like we need to fix that for 5.3 :-)
Indeed :-)
Cheers,
Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kill the systray?

[Matthias Klumpp]

2013/9/26 Aaron J. Seigo ase...@kde.org:
 On Wednesday, September 25, 2013 23:06:42 Matthias Klumpp wrote:
 I also fear that, but this was a statement by single developers, which
 I don't think is true.

 it is the developer responsible for the component in question, and apparently
 he’s already doing work to create new incompatibilities in the messaging spec.
That is indeed bad if it comes from the person responsible for the
feature. Incompatibilities are okay, IMHO, as long as they really
provide improvements and are not just bikeshed about e.g. function
naming or wheel-reinventing of working specs.
So let's see what will be proposed at XDG.

 if that is indeed what happens and it becomes a GNOME Shell specific thing, i
 don’t think we should implement support for it for all the same reasons we’re
 not implementing support for Mir.
Jup, we shouldn't do that then. But I can't see what is GNOME-specific
about it (yet).
Maybe the persistent-notifications-after-reboot thing will be a
(solvable) issue.

We would still have a problem with applications which only provide a
tray icon for interaction... It would be nice to solve that.
Unfortunately, I am busy with AppStream and Listaller stuff, but I
would love to help with the
notification/tray/GNOME-KDE-XDG-communication issues. I think I will
have some time in mid-October.
Meanwhile I will ask some people at GNOME about placing the tray
data at different positions and implementing a tray XDG spec in line
with GNOME design principles. But I don't expect much success there -
it's worth a try anyway ;-)
Cheers,
Matthias


-- 
Debian Developer | Freedesktop-Developer
KDE-Developer| GNOME-Contributor
I welcome VSRE emails. See http://vsre.info/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kill the systray?

[Matthias Klumpp]

GNOME embeds the tray Icons in it's norification area, supporting xembed
right now. In future, they want a different notification system, which is
used exclusively (design docs are available, i will look them up at home)
However, I assume GTK+ will have a systray implementation (at least for
Xfce), so it makes much sense to discuss post-x systray now and create a
Freedesktop document for it - maybe just use DBusmenu...
Cheers,
Matthias
(Sorry for the not-inline reply, sent from my phone)
Am 24.09.2013 09:51 schrieb Martin Graesslin mgraess...@kde.org:

 On Tuesday 24 September 2013 18:04:55 Aaron J. Seigo wrote:
   * Qt5 doesn't seem to have the API we need to do our xembed tricks
   anymore,
  
 especially QX11EmbedContainer is gone.
 
  it’s missing more than gone; i’ve heard several times that someone or
  another was working on it.
 which wouldn't be in time for Qt 5.2 anymore. So earliest is Qt 5.3 which
 might be too late for our needs.
 
 If we even get it to work under
  
   X11, it seems entirely futile to expect this to be feasible in a
 Wayland
   world.
 
  agreed ...
 well for supporting legacy applications it would be needed in the same way
 as
 for supporting GTK+ application on X11.

   When I asked Martin if he knew a way to do the xembed, he replied
 (being
   Martin ;)) asking if we can just kill it and quoted starwars. I wonder:
   Can
   we kill it yet?
 
  if Gtk+ supported status notifiers natively, then i’d say “yes”. it
 doesn’t,
  so anyone who uses a Gtk+ application with a system tray icon will
 suddenly
  not be able to access it. i’m pretty sure that’s going to cause
  problems.
 what's the status of the Ubuntu implementation? Is it that an app has to
 explicitly link against it?
 
  as the GNOME devs are currently porting to Wayland as well, now would be
 a
  good time to find out what they plan to do with their xembed system tray.
 I just tried to find some information on how they are using it and somehow
 I'm
 not sure whether the xembed systray is available at all in GNOME...
 
  oh, and the tasks widget ought  to gain support for application based
 status
  notifiers (so that the system tray can opt out of them) as well as
  skiplists. what i’d really like to see is this become a part of the
 wayland
  specific support that  we can build around the “every window has an
  associated .desktop file” thing. Martin?
 sounds good to me.

 Cheers
 Martin
 ___
 Plasma-devel mailing list
 Plasma-devel@kde.org
 https://mail.kde.org/mailman/listinfo/plasma-devel


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kill the systray?

[Matthias Klumpp]

Sorry, I confused the naming here... And I am aware offen the previous
discussion (followed it, but was not involved) I just think that it might
make sense to start a New attempt on this, now that everyone is working
towards wayland. Talking to Xfce is a good idea too, imho. I can ask around
on this.
Cheers,
Matthias
Am 24.09.2013 10:35 schrieb Marco Martin notm...@gmail.com:

 On Tuesday 24 September 2013, Matthias Klumpp wrote:
  GNOME embeds the tray Icons in it's norification area, supporting xembed
  right now. In future, they want a different notification system, which is
  used exclusively (design docs are available, i will look them up at home)
  However, I assume GTK+ will have a systray implementation (at least for
  Xfce), so it makes much sense to discuss post-x systray now and create a
  Freedesktop document for it - maybe just use DBusmenu...

 dbusmenu has nothing to do with systemtrays.
 we do have a post-x systemtray and is StatusNotifier, the one that ubuntu
 uses
 as well. (so some gtk apps supports it upstream, some have patches on
 ubuntu
 side)
 and yes, it has been discussed on freedesktop literally to death, years
 ago.

 --
 Marco Martin
 ___
 Plasma-devel mailing list
 Plasma-devel@kde.org
 https://mail.kde.org/mailman/listinfo/plasma-devel

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: naming the next major release

[Matthias Klumpp]

2013/8/21 Martin Graesslin mgraess...@kde.org:
 On Wednesday 21 August 2013 19:36:21 Daniel Nicoletti wrote:
 [...]
 Ok, then what am I doing wrong in calling my stuff KDE stuff?
 http://manifesto.kde.org/benefits.html lists what I do on my
 projects, I was arguing about Martin saying that I talk KDE as software
 but KDE projects are mostly software no? This is too controversial,
 I know the idea is the we KDE are a community, but it's a community
 that have projects and software hence why am wrong in saying
 KDE software? It's software made by KDE people.
 Look for example at your rant about switches. It's always saying KDE 4.11,
 which is just wrong. That's what I meant. Just by scrolling down your blog I
 see two posts with KDE 4.11 in the title. This is working against the
 rebranding. How are we supposed to have the media get it right, if even the
 developers continue to use the old wording.
It is simply convenient to use KDE meaning the Frameworks,
Plasma-Workspaces etc. Saying KDE is much easier than distinguishing
between the different parts, and it has been used like this for years.
But I assume that this will change with the availability of KF 5 etc.
As soon as the stuff is released at different times and in different
packages, people will adapt to it and use the right names. (e.g.
New features in Plasma or API will be available in KDE-Frameworks
5.4, etc.)
IMHO saying that my software is part of KDE is still correct, since
KDE can mean the community as well in this context, in the same way
Firefox is part of (the) Mozilla.
(Project).
Cheers,
Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma Workspaces 4.11: the last feature release in the 4.xseries for kde-workspace

[Matthias Klumpp]

@Kevin: I am only remotely following this issue, but as PackageKit
developer, I would of course like to see our project in Plasma
Workspaces as soon as possible. But I don't know the exact issues
here. Also, having KSecrets merged would be a nice goal too. (The
SecretService API is very stable, and has the potential to become a
new de-facto XDG standard soon)
So, why not work on merging all this stuff into Workspaces 5 as early
as possible, so it is present there?
(With having WS 4.11 frozen, it IMHO does not make any sense at all to
develop new features for it, unless the new feature works on both
Workspaces versions with less modifications)
Cheers,
Matthias
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel