Push or Pull for selections?

[Manuel Breugelmans]

On Sunday 24 August 2008 14:19:07 Marek Jasovsky wrote:
> 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) 

Qt signals and slots


Manuel