[referencer] lyx plugin

[Aurélien Naldi]

Le vendredi 04 janvier 2008 à 21:38 +0000, John Spray a écrit :
> 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.

You are right, I would love a new release of referencer with all this in
time for the next release of my distrib ;)

> 
> > 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...

Here is an updated version, which adds the sensitivity stuff and reworks
the button text and tooltip as you asked. I've not yet added the UI
removal, I need to get some sleep first.

-- 
Aurélien Naldi <aurelien.naldi at gmail.com>