krunner qml

Aaron J. Seigo aseigo at kde.org
Thu Jan 10 15:07:19 UTC 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130110/d28dc411/attachment.sig>


More information about the Plasma-devel mailing list