[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Review Request: Allow runners to do quick prepare and teardown
From: "Aaron Seigo" <aseigo () kde ! org>
Date: 2009-07-28 3:38:07
Message-ID: 20090728033807.12896.70636 () localhost
[Download RAW message or body]
> On 2009-07-27 16:57:22, Ryan Bitanga wrote:
> > I like the concept. I can't think of better names for the methods either. How \
> > about setupMatchSession() instead?
i've committed with this name as it is slightly better indeed
- Aaron
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1133/#review1808
-----------------------------------------------------------
On 2009-07-27 00:19:26, Aaron Seigo wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1133/
> -----------------------------------------------------------
>
> (Updated 2009-07-27 00:19:26)
>
>
> Review request for Plasma.
>
>
> Summary
> -------
>
> Right now runners have only one opportunity to set themselves up: when init() is \
> called. It has become apparent that for _some_ runners it is advantageous to do a \
> bit of set up before a matching session starts and teardown afterwards. For \
> instance, the new window runner needs to keep track of the windows that exist and \
> it shouldn't be getting that information constantly as the user types; equally so, \
> it shouldn't be holding onto and keeping this information up to date even when the \
> krunner interface isn't shown.
> This patch provides a set of signals that runners may optionally listen to. A user \
> of RunnerManager may call prepareForMatchSession and matchSessionComplete itself, \
> or just let RunnerManager call prepareForMatchSession itself if it doesn't care \
> about resource usage.
> Users of AbstractRunner which aren't using RunnerManager to do so can "fudge" this \
> by connecting a local signal to the AbstractRunner signal and then emitting the \
> local signal inside the local code. Not overly elegant, but certainly an edge case \
> (and one we don't have right now). All AbstractRunner usage really should be going \
> through RunnerManager.
> I'm still looking for better names for the new methods/signals, so suggestions \
> welcome there, too! Wanted to get some feedback on the design earlier, though.
>
> Diffs
> -----
>
> /trunk/KDE/kdebase/workspace/krunner/interfaces/default/interface.cpp 1002691
> /trunk/KDE/kdebase/workspace/krunner/krunnerdialog.h 1002202
> /trunk/KDE/kdebase/workspace/krunner/krunnerdialog.cpp 1002202
> /trunk/KDE/kdelibs/plasma/abstractrunner.h 1002205
> /trunk/KDE/kdelibs/plasma/runnermanager.h 1002205
> /trunk/KDE/kdelibs/plasma/runnermanager.cpp 1002205
>
> Diff: http://reviewboard.kde.org/r/1133/diff
>
>
> Testing
> -------
>
> built, ran krunner ...
>
>
> Thanks,
>
> Aaron
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic