[referencer] lyx plugin

[Aurélien Naldi]

Le vendredi 04 janvier 2008 à 12:33 -0500, jcspray at icculus.org a écrit :
> Quoting Aurélien Naldi <aurelien.naldi at gmail.com>:
[..]
> > * It doesn't strip UTF-8 characters as my installation of lyx (1.5)
> > deals properly with them. I would encourage anyone still using an older
> > version of lyx to upgrade. I have not tested it with kile yet.
> 
> Really?  Are you sure you're not just happening to give it characters  
> in the first 128 byte range?

I don't think that accentuated characters, cyrillic and kanjis all fall
in this category ;) Once again, this is with Lyx 1.5.x, older version
doesn't enjoy UTF-8 at all!

> 
> > * it is lacking in error reporting (only appear on console). Is it OK to
> > put a dialog using pygtk directly from the plugin ?I would much prefer
> > something less intrusive (i.e. error bar ala firefox/gedit) but this
> > requires more work in the core.
> 
> Re pyGtk, the short answer is "I don't know".  Initialisation/event  
> loops may well conflict.  I would avoid it until we know.  gedit gives  
> its plugins PyGtk, perhaps you could see how they do it.  For the  
> moment I would have perform_action simply return 0 or 1 and do  
> non-specific error reporting from the C++ side.
> 
> Being verbose on the console is a Good Thing, since it gives  
> straightforward debugging info if the user just runs referencer from a  
> console instead of their applications menu.

Right, I forgot about the potential main loop conflict stuff.

>  From looking at the attachment:
>   - Calling referencer.get_selected should be replaced with an  
> argument to the perform_action function.  That way the plugin doesn't  
> have to talk to DocumentView, just gets a Document object.

That's what I intended to do at first, but we may want plugins that
don't care about the selected document(s), so an API to allow the plugin
to ask for them if needed seems more generic to me. Anyway it is easy to
remove it and switch to an argument once we have a python representation
of a document list.

>   - In general file operations should be in try{} blocks, although at  
> present it's not clear how we're dealing with exceptions.  One  
> possibility is to let fatal exceptions propagate to the C++ side where  
> they can be munged into an error dialog.  Although dialogs are in  
> general not terribly desirable, as long as exceptions really are  
> exceptional they shouldn't get in the way.  For instance the metadata  
> plugins wouldn't pass "not found" exceptions to the C++ side, they  
> would silently fail.  On the other hand, passing a "I can't open the  
> lyx pipe" exception up to the C++ side for display would be reasonable.

Right, I just wanted to check that everything was working as expected.
In the final version I'll catch the exception in python and interrupt
the script.


> That's all that springs to mind just now, watch this space for a  
> python interface for Document.

Yes, I can't wait to see it ;)


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.

You wrote in the other thread:
> The actionText_ and actionTooltip_ members of Plugin are
unnecessary,  
> these values should be returned using getPluginInfoField.  Therefore  
> they should be defined as {} in Plugin, with the real
implementations  
> in PythonPlugin.

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 ?

About making the UI fully dynamic: I completely agree but I have never
used the UIManager stuff (I'm mostly coding in java/swing :/). But I'll
be happy to learn this as well if it is necessary and sufficient to get
this thing in svn! Do you have a pointer to a good tutorial about this ?

Thanks for helping me scratching my itches ;)

To put everything in the same thread, here is an slightly updated
version of the patch: I corrected the coding style, sorry for the
tab/space mess, I blame my laziness to properly configure vim.

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