[referencer] lyx plugin

[John Spray]

On Fri, 2008-01-04 at 21:55 +0100, Aurélien Naldi wrote:
> About the sensitivity mechanism: I have not looked at it at all. Which
> part of the code is responsible for changing sensitivity of UI parts ?
> 
> I think we could add a "isActive" method in the plugin, were the default
> implementation always returns true and put some glue in PythonPlugin to
> call a python method instead if it is defined. If this is fine with you
> I can do this.
> To make it more usefull, we may want to add some stuff to the referencer
> python module: "is_online" and "get_selected_documents_count" comes
> first to my mind.

The sensitivity stuff lives in RefWindow::docSelectionChanged.  I would
suggest that for the moment you set the GtkActions associated with
DOCUMENT_ACTION plugins to be sensitive when there is anything selected,
and otherwise to not be sensitive.  This should be the most
straightforward way.  It does not grant the python side any control,
which is deliberate; I want to keep the first iteration of this plugin
stuff as simple as possible.  If the sensitivity logic is on the python
side then plugins need access to the DocumentView status as you say, and
I think that would be over-reaching for the first version of this stuff.
Summary: let's get something working first.

I appreciate that ultimately it is desirable to grant the plugins
themselves the flexibility to set their own sensitivity policies, but
right now my intention is to have metadata plugins and document action
plugins for the next release within two weeks.  I've been breaking the
"release early release often" rule for too long.  More API can be
exposed to python in subsequent releases.

> I don't see any getPluginInfoField, so I'm not sure to understand: do
> you want to make the two accessor functions purely virtual in order to
> remove the members (which would force to implement them in each C++
> plugin, which I wanted to avoid) or to completely remove it in favor of
> a more generic function ?

Look at the implementation of PythonPlugin::getLongName, that's what I'm
suggesting for getTooltip et al.  Avoids keeping a copy of the string,
and also avoids touching the initialisation logic.  The less stateful
the C/Python interface is the better.

Just got your following email, glad you like UIManager, it is pretty
neat.  I'll leave you to work out the details of keeping the UI
consistent while I continue learning to wrap C++ objects for python...

John