krunner qml

[Aleix Pol]

On Thu, Jan 10, 2013 at 4:07 PM, Aaron J. Seigo <aseigo at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130111/a50b1c7f/attachment.html>