On Thu, Jan 10, 2013 at 4:07 PM, Aaron J. Seigo <ase...@kde.org> wrote:
> 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 > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > Yes, the screen locker is a good place for it. In Android they did it this way [1] and it works really well. Having different things in the same process is ok it's a technical detail that makes sense, what worries me is that we get a button for things we're not looking for only because of technical reasons. For example, I never understood why the system activity is there, GUI-wise. Aleix [1] http://i1.sinaimg.cn/IT/cr/2012/1113/3344057262.jpg
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel