Should favourites be shared between launchers, and launcher instances?

[Eike Hein]

So here's my notes on this, summarized from the earlier thread:

* Plasma generally allows multiple instances of the same widget
   with independent configuration. Straying from this introduces
   an element of uncertainty for users, where they can no longer
   be certain if things they change apply to all instances or
   just one instance.

* Shared state between widget instances introduces the problem
   of synchronization. In this particular case we have a system
   framework for it, but I'm concerned that if the "role model"
   widgets we ship waver on shared-vs-independent state, third-
   party widgets will waver too, and won't get synchronization
   right because it's hard.

* Shared config also isn't well-supported by the Plasma plat-
   form from the POV of ISVs: Widget-specific preconfiguration
   is consistently handled via Plasma desktop scripting, but
   here we're introducing a random rc file that some widgets
   use. We have no well-established means to document which
   config is stored where.

   (Side note: For distros Plasma 4 was sometimes hugely frus-
   trating because of the poor consistency of configuration
   handling in Plasmoids. A lot of them implemented the config
   handling pattern incorrectly and weren't prepared to handle
   external changes of config data, and thus couldn't be
   scripted. Others, well, did this random rc file thing. I
   ended up having to patch several of them. Plasma 5 does much
   better here because the declarative nature of the new config
   API makes it much harder to get it wrong. Along those lines
   the fact that Kickoff currently does it differently is tech-
   nically a legacy bug and shouldn't be seen as a precedent
   for practices.)

* For the concrete example of launchers, users may legitimately
   want different favorites per instance, e.g. in the case of
   setting up per-monitor instances with different favorites.
   I've seen this both for menus and for the SAL containment
   launcher. It's even more obvious/common if you consider
   pinned tasks in the Task Manager favorites as well, though
   this might not be the right way to think of them.

OTOH:

* It may be that favorites are special because they are not
   launcher config at all, but an extension of the menu data,
   which is already shared state between launchers.

* I can think of use cases where favorite sync between
   launchers seems desirable, particularly thinking about
   shell switching - going from Desktop to a tablet shell
   I'd likely want my favorites to come along in some way.

I think the launchers-per-activity thing is somewhat ortho-
gonal, in the sense that widgets with independent state
could still maintain different favorite lists per activity.
OTOH, if we decide that launchers should be synchronized,
then per-activity launchers add pressure to make all menu
customization per-activity (since you could conceivably
want a different menu structure in each).


Cheers,
Eike