appstream in Plasma

Sat Apr 9 18:32:24 UTC 2016

On Saturday, April 9, 2016 3:48:33 PM CEST Alexander Potashev wrote:
> Martin,
> 
> Please find my comments below.
> 
> 2016-04-08 8:55 GMT+03:00 Martin Graesslin <mgraesslin at kde.org>:
> > On Thursday, April 7, 2016 11:28:17 PM CEST Alexander Potashev wrote:
> >> What if
> >> 
> >>  1. I don't use a desktop environment, but I need a way to setup
> >> 
> >> localization for KDE applications?
> > 
> > Ever heard of setting the LC_LANG env variables? Yes, nowadays KDE
> > applications use the standard Linux way for localization and not a custom
> > thing where one needs a special configuration module.
> 
> Localization section in System Settings also includes spellchecker KCM
> that writes to ~/.config/KDE/Sonnet.conf. There is no other place to
> configure spellchecker for KF5-based applications.

ah well, then just like in the Baloo/Dolphin case the applications using 
Sonnet need to include the KCM in their configuration.

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.

> 
> >>  2. I have GNOME installed, but can't figure out how to use its tools?
> >> 
> >> The way out from this situation is that I install systemsettings5 and
> >> use it to configure localization while in a GNOME shell session.
> > 
> > Report a bug against GNOME then, if their software is unusable.
> 
> GNOME software might be OK, but I don't want to spend time on learning it.
> 
> Everyone should be free to use systemsettings5. What you suggest is
> not freedom [1].

You have all the rights to use systemsettings in GNOME. I don't care, nobody 
cares. But that doesn't mean that we have to provide appdata to make it 
installable in GNOME Software (apt install systemsettings still works after 
all). There's nothing in the GPL saying so. Sorry, but we are not here to 
serve everybodys "right of choice". We are not restricting anybodys freedom 
here, not violating the GPL or working against our vision. A good read in that 
regard is this weeks blog post about the right of choice in libinput: http://
who-t.blogspot.de/2016/04/why-libinput-doesnt-have-lot-of-config.html

It's a good read on why one shouldn't make everything in the world 
configurable. Adding appdata for something that shouldn't have it, is in the 
same category: it means we need to maintain it. That's a burden on our 
shoulders.

> 
> >> > Erm no. I just did a search for Akonadi in systemsettings and it
> >> > returns
> >> > nothing. Even if it were in systemsettings it would be wrong. That
> >> > needs
> >> > to be offered from the applications.
> >> 
> >> Please search for "PIM Accounts and Resources" in systemsettings.
> > 
> > doesn't exist on my system.
> 
> OK, I might have an old version of KDE PIM.
> 
> >> >>  - Baloo,
> >> > 
> >> > Use the DEs search tool
> >> 
> >> What if I want to use Dolphin? It only integrates with Baloo, thus I'm
> >> forced to use it. Editing baloorc is not very user-friendly.
> > 
> > Then dolphin needs to make the baloo configuration accessible. Expecting
> > users to know that they need to install systemsettings is no solution.
> 
> Reported against Dolphin: https://bugs.kde.org/show_bug.cgi?id=361557
> 
> >> >>  - systemd
> >> > 
> >> > There is no such thing as a systemd kcm in systemsettings
> >> 
> >> Please see https://quickgit.kde.org/?p=systemd-kcm.git
> >> You can install it and find it in systemsettings root menu.
> > 
> > 3rd party modules are not a reason for us to do things.
> 
> OK, then it's a problem in Systemd KCM.
> Reported: https://bugs.kde.org/show_bug.cgi?id=361558
> 
> >> Is your vision that writing third-party KCMs should be forbidden? (By
> >> "third-party" I mean those that are not released as part of Plasma.)
> > 
> > Everybody is free to write 3rd party KCMs to integrate with Plasma. But
> > it's no reason to make Plasma applications available to non-Plasma users.
> > 
> > To make it clear: we care here about the Plasma workflows and a good
> > integration of Plasma inside Plasma. You are free to use Plasma tools
> > outside Plasma, but that is not what we aim for. If you want to use
> > systemsettings outside of Plasma: do so! But that doesn't mean that we
> > want to expose systemsettings to non-Plasma users. Just like we don't
> > want GNOME's settings tool exposed to Plasma users.
> 
> 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.

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.

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. 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.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160409/1cf23918/attachment.sig>