On Monday 14 July 2014 13:15:32 John Layt wrote: > Over on the Windows list we've been discussing about KCM's for > configuring common services/frameworks like this when running apps > under non-Plasma desktops, including Gnome, Windows, Mac, etc. > General gist is that we don't want to have systemsettings installed in > non-Plasma platforms to gain access to them, so they need to be > accessed through the apps config dialog or help menu instead. This > implies a few things: > > 1) That the KCM's are located somewhere easily packaged for > stand-alone app installers to include > 2) That an app can figure out what KCM's it needs access to when > running non-native > 3) That at runtime the app can detect it is running in non-native mode > and find and load the required external KCMs that it needs > [...] > Thoughts?
Or maybe it is that an application which depends on such a KCM to be present to be configured is not portable? After all, it is a sign of a direct dependency on a low level setting from the application. Maybe that's fine, maybe not all applications are meant to run outside of a Plasma workspace. What's not fine IMO is to turn a framework into a bit of workspace with UI to workaround that. From what I kept above, I got that feeling that we end up in that situation mainly because: we got some settings which should be application settings but end up appearing in systemsettings instead and we got applications/frameworks reading settings from our low level settings unconditionally while they should read from the platform settings instead (Plasma being one among several). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel