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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
