Should favourites be shared between launchers, and launcher instances?

[Eike Hein]

On 09.10.2014 23:02, David Edmundson wrote:
> How are we doing with:
>
>>regardless what method will be used, there should be an api for that in the
> scripting api
>
>
> I don't want this missed, as it will mess up certain important distros
> that configure their favourites.

This also interacts with review request 120538, where a need
for complex defaults came up - a "default browser" launcher.

C++ code embeds in KConfigXT don't work in Plasma of course,
so we have two options: Either we do it in scripting (which
means we need API to do it), or the magic preferred:// URL
scheme hack that libtaskmanager has been using for default
app launchers for a few years.

The latter has the significant advantage that rather than
figuring out the default browser at init time the notion
of "favorite default browser" can be stored permanently
and the favorite can update automatically when the user
changes their default application. The downside is that
this needs to be implemented comprehensively, e.g. Kicker
has a "Remove as Favorite" action for general menu actions
when the app is already in the faves, and so the ability
to resolve the magic favorite to an actual app for compa-
rison has to be available at that point as well.

At the bottom line we could lob favorites for default
browser, file manager, mailer and terminal into the default
set and distros wouldn't actually have to customize them
beyond setting up those different default apps.

(Personally I still have certain reservations of going this
shared favorite route at all, but I can see both sides and
am not too emotional about it - here it provides the advan-
tage of implementing default launchers once and getting it
right, vs. every menu trying to do something like this just
by itself.)


Cheers,
Eike