Push or Pull for selections?

[Andreas Pakulat]

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
> 
> what do you mean "last selection" ? My question aims here: do all
> plugins, views, everything that can select anything imaginable, have
> common interface?

Last selection means this: You click on a project in the project tree
and thus it gets selected. The project treeview now asks the plugin
controller to notify all plugins of this new selection. The plugins
react according to their interest. Then the user does a selection inside
the editor, for example selects a word. This is again send to the plugin
controller and hence all plugins are notified. So the plugins can always
just know the "last" selection done in all kdevelop mainwindows. And
any plugin that is interested in re-acting to selections needs to store
the information.

> > method and then read the data about the selection (I was going to re-use
> > the Context class as it really already has all the needed data).
> >
> > Pull would mean we provide access to the currently focused view/toolview
> > and have a "current selection" method there that retrieves a Context.
> > I'm not sure yet how to best map that to the toolview factory though,
> > but this might get easier if/when Alexander is finished with his
> > shell/sublime re-design.
> >
> > Thoughts? Comments?
> >
> > Andreas
> >
> 
> (Eclipse has ISelectionService interface and rest is implemented
> through listeners. plugin interested in selection would register
> handler and then the handler could decide, based on type of selected
> object (all such objects would then have to implement same interface)
> what to do with the selection.

Yes and in fact it also has support for fetching the current selection
in any widget. So maybe it would be good to have both: Allow to fetch
selections of a toolview somehow and also notifying everything about
changes in selection.

Hmm, of course this only works when there's only one widget in a
toolview that can carry a meaningful selection. But I guess we can worry
about that when we have an actual use-case for it - AFAIK so far there's
only 1 widget that really provides selections in all our toolviews.

Andreas

-- 
What happened last night can happen again.