On Thursday, January 10, 2013 15:24:58 Aleix Pol wrote: > Hmm.. why do you think user switching belongs to KRunner? Did I miss > anything? If anything, I'd say it can be a runner, but do we need specific > UI for this?
krunner does a few things: * show the task manager dialog (KSysGuard) * provide the "gui command line" (KRunnerManager and friends) * provide UI for user switching (re-uses "gui command line" for this currently) * autostart feedback (StartupId class) it also used to do: * lock screen (now handled by ksmserver) this is because we wished to ballance how many processes were running (memory and startup overhead) with stability. fewer processes is good, unstable things should be kept from things that require 100% stability, things that can block CPU should be kept from things that require low latency response time. the easiest answer to get going was to pour things into krunner. remember that we were working our asses off trying to get a basic desktop shell assembled with very few people contributing. thankfully we had a much larger # of people telling us what a bunch of deluded assholes we were while we were doing that work, which certainly helped ;) in the end, given that people don't even realize that all of those things are part of krunner at least shows that putting them in krunner was not the worst possible decision. ;) that said, just as we did with the lock screen in 4.10, we can move pieces around now that we have more space to think these kinds of things through to a greater degree. for instance: it may make more sense to put the switch user UI into the locker. why? * the locker also provides a Switch User functionality (though it just starts the DM for that), so a unified UI would be good * when you switch sessions, the current session is (or at least should be?) locked behind you, which means the locker needs to come into play anyways that means that this UI could be moved into the screen lock UI (which is already QML) and could be triggered by ksmserver. this will keep ksmserver stable (it doesn't load any UI) and responsive (it doesn't load any UI ;). it will allow us to put the switching and locking in one place. regardless, a new fast user switching UI needs to be done for this. whether it goes into the krunner process or elsewhere, it needs doing. on that note, startup stuff should probably move into kwin since it also provides the visual effect for it. it's probably also more future proof with Wayland's security model coming at us in the future... dunno what Martin G. thinks about that idea? that would leave us with the task manager UI and the "gui command line" (gcli? :) in krunner, which to me seems pretty decent. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel