Web Shortcuts KCM

[John Layt]

On 14 July 2014 11:46, David Faure <faure at 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