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