Push or Pull for selections?

Marek Jasovsky jasovsky.marek at gmail.com
Sun Aug 24 12:19:07 UTC 2008


2008/8/24, Andreas Pakulat <apaku at gmx.de>:
> On 24.08.08 13:33:06, Manuel Breugelmans wrote:
>> On Sunday 24 August 2008 12:00:35 Andreas Pakulat wrote:
>> > On 24.08.08 11:38:42, Marek Jasovsky wrote:
>> > > 2008/8/24, Andreas Pakulat <apaku at gmx.de>:
>> > > > Hi,
>> > > >
>> > > > after comitting the proxy-selection-model last night I couldn't
>> > > > really
>> > > > sleep and thought about how to allow plugins to know the selections
>> > > > in
>> > > > other plugins. Or rather, they want to know the selections in the
>> > > > toolviews and views.
>> > > >
>> > > > Now I'm a bit undecided wether to use a push or a pull strategy to
>> > > > make
>> > > > the information available. The push strategy would mean a new
>> > > > virtual
>> > > > on IPlugin and a public method on IPluginController to notify all
>> > > > plugins of changes in the selection. So each plugin interested in
>> > > > knowing the "last" selection in the GUI would need to re-implement
>> > > > the
>> > > > virtual
>>
>> Any reason to not use a signal for this instead? PluginController (or some
>>
>> other) emits a selectedContextChanged(), interested parties subscribe to
>> it.
>> More elegant and powerful imo, but maybe I'm missing the obvious.
>
> No reason not to do that.
>
I not very familiar with concept of signals (are we speaking about
linux level, kde level, qt level, or what level are those signals
implemented at) but from what I understand, these are quite close to
events.

Marek

> Andreas
>
> --
> You'll feel much better once you've given up hope.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>




More information about the KDevelop-devel mailing list