[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: Martin_Gräßlin <kde () martin-graesslin ! com>
Date: 2009-07-28 9:36:30
Message-ID: 20090728093630.19735.47865 () localhost
[Download RAW message or body]
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1133/#review1819
-----------------------------------------------------------
/trunk/KDE/kdelibs/plasma/runnermanager.cpp
<http://reviewboard.kde.org/r/1133/#comment1186>
I think here a d->prepped = true; is missing.
Nevertheless even if I add it the teardown signal is never fired. I added a matchSessionComplete() \
call in RunnerManager::run which fired the signal when you executed a match. If you use escape the signal \
isn't fired :-(
- Martin
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