appstream in Plasma

[Matthias Klumpp]

2016-04-10 0:06 GMT+02:00 Thomas Pfeiffer <thomas.pfeiffer at kde.org>:
> 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 emails. See http://vsre.info/