On 14 July 2014 11:46, David Faure <fa...@kde.org> wrote: > On Monday 14 July 2014 12:34:44 Eike Hein wrote: >> Hi David, >> >> I'd like to port the ebrowsing KCM and move it to >> plasma-desktop or -workspace, since it has plenty >> of users outside of Konq (e.g. Konvi, Konsole and >> Okular, the first two of which have ports now). >> >> Thoughts? > > The whole split between workspace and applications seems to generate more > issues than we thought..... we're going to miss a place for shared runtime > deps. > > If someone uses konvi, konsole, okular, or konqueror outside of plasma- > workspace, (e.g. in gnome, Mac or Windows), then they are not going to be able > to configure cookies, internet keywords, useragent, proxies ..... if these > things are part of the workspace. > > Given that the kurifilter plugins themselves are in KIO for this same reason, > maybe the ebrowsing and the kio (cookies,proxies,useragent) KCMs should go > into KIO as well?
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 Preferably this would all be as automated as possible. The obvious place for the KCM's to live would be in the Framework that they configure, but we have to think how that would affect the dependency tree. Tier 1 is fine, as it can't use KConfig anyway (but how then do they handle config, if any need to?). Tier 3 is fine, as it can depend on KConfigWidgets/KCMUtils, albeit at the cost of a more complicated dependency diagram. Tier 2 could be an issue, as it cannot depend on KConfigWidgets/KCMUtils. For those we'd need separate repos (yet more repos?) or one shared repo (at the expense of more dependencies and installing extra stuff you may not need for your app), or perhaps a configure flag that enables building the KCM if you need it (a disable flag may be a good idea at Tier 3?). Thoughts? John. P.S. This and other cross-platform issues that need work are listed at https://community.kde.org/KDE_Applications/Cross_Platform_Issues _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
