> needs to be the store for / provider of that shared state, > but it's one of the options on the table ..
One of the possibilities (if we choose to do it via kamd) is to have the kamd plugin loaded on request - when there is a client that desires it. The mechanism for that is already in place - a few plugins already use it. Cheers On 22 October 2014 12:31, Eike Hein <h...@kde.org> wrote: > > > On 10/22/2014 11:43 AM, Ivan Čukić wrote: > >> If there is no other place where the new-app thingie is used, I'd leave >> it inside the launcher. But, I am open to be convinced otherwise. >> > > Hmm well, the thing is that it's a bit similar to all the > arguments for making favorites shared state (which seem to > be winning out, ironically against my reservations :) - > being "new in the menu" is a property of the apps more than > an individual launcher, and we make it easy to switch laun- > chers via Alternatives now, so not losing the data by doing > so would be good. That doesn't necessarily mean that KAMD > needs to be the store for / provider of that shared state, > but it's one of the options on the table .. > > > Cheerio, >> Ivan >> > > Cheers, > Eike > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- KDE, ivan.cu...@kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
