lyx plugin

[Aurélien Naldi]

Here is a lyx plugin to quote selected documents.

features:
* reads the path to the lyxpipe in lyx config file. This can be
overriden in the script, waiting for a configuration mechanism for
plugins
* write a "cite" command to the lyx pipe
* requires a yet unfinished patch to referencer, so that it can add a
button to the toolbar and know which documents are selected.

quick comments:
* 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.
* for now it always pushes some dumb test citation for testing, waiting
for the real list of selected documents
* 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.
* afterwards I have read about a lyxclient in python, maybe we should
reuse it ? http://wiki.lyx.org/Tools/PyClient

Attached is only the python plugin, the unfinished patch (with a stub of
the plugin) can be found in the medline thread.

I'll be waiting a bit more before going on with the main patch, waiting
for your comments.

Regards.

[jcspray]

Post by Aurélien Naldi
Here is a lyx plugin to quote selected documents.
* reads the path to the lyxpipe in lyx config file. This can be
overriden in the script, waiting for a configuration mechanism for
plugins
* write a "cite" command to the lyx pipe
* requires a yet unfinished patch to referencer, so that it can add a
button to the toolbar and know which documents are selected.
* 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?

Post by Aurélien Naldi
* 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.

Post by Aurélien Naldi
* afterwards I have read about a lyxclient in python, maybe we should
reuse it ? http://wiki.lyx.org/Tools/PyClient

Up to you. I'm only interested in defining the Python/C++ interface;
how the plugin works is your prob^H^H^H^H challenge.

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

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

John

[Aurélien Naldi]

[..]

Post by jcspray

Post by Aurélien Naldi
* 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!

Post by jcspray

Post by Aurélien Naldi
* 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.

Post by jcspray
- 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.

Post by jcspray
- 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.

Post by jcspray
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.

Post by jcspray
The actionText_ and actionTooltip_ members of Plugin are

unnecessary,

Post by jcspray
these values should be returned using getPluginInfoField. Therefore
they should be defined as {} in Plugin, with the real

implementations

Post by jcspray
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.

[John Spray]

Post by Aurélien Naldi
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.

Post by Aurélien Naldi
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

[Aurélien Naldi]

Post by John Spray

Post by Aurélien Naldi
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 ;)

Post by John Spray

Post by Aurélien Naldi
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]

Post by Aurélien Naldi
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.

And here it is with dynamic UI. I added a map in RefWindow to store the
mergeid. It uses it to update everything when the list of disabled
plugins changes.

A few quirks remain:
* the plugin does not set it's icon. I could add one more field for
this, defaulting to stock:execute as now. Being limited to stock icons
would be a good start, especially as we would have to deal with
dependencies/installation for non-stock ones.
* When enabling a plugin in the pref ui, it's icon is enabled even if no
document is selected. I tried launching onDocumentSelectionChanged but
it crashes at startup.

Do you have any other problem with it, or is it ok to go in once you
have a working python class for documents ?

Regards

[John Spray]

Post by Aurélien Naldi
* the plugin does not set it's icon. I could add one more field for
this, defaulting to stock:execute as now. Being limited to stock icons
would be a good start, especially as we would have to deal with
dependencies/installation for non-stock ones.

I'd be happy with letting the plugins give an icon name relative to the
referencer data directory, and looking it up in
onEanbledpluginsPrefChanged using Utility::findDataFile. Obviously it's
not very useful for third-party plugins, but for stuff included in
referencer it'll do. An empty string would mean "use some default
icon", which could be the stock execute icon as it is now.

The UI should go into the Documents menu as well as the toolbar, I think
-- that should just require adding a bit to the UI XML.

Post by Aurélien Naldi
Do you have any other problem with it, or is it ok to go in once you
have a working python class for documents ?

I've committed it, with a couple of naming changes, and modified it (as
well as the metadata plugin stuff) to use a python document class
(PythonDocument.[Ch]). It's getting the keys correctly, but I'm getting
"no pipe defined. Is lyx configured ?". Could be because I never set
the pipe location explicity that lyx is using a default location which
isn't stored in the config file?

I've sorted the sensitivity issue by moving the plugin ui initialisation
out of constructMenu and to the end of constructUI, so that it's set up
after docview_ and can query whether any docs are selected.

In the spirit of emulating every other maintainer I've ever had to deal
with, I'm nitpicking coding style. In if statements, please keep the
"{" on the same line as the if, not on the next line.

Todos before release:
* Show UI for exceptions raised by python plugins
* Sort out sensitivity and icons for document action plugins
* Add a bunch of checking in python calls for correct types etc,
and give errors for bad plugins rather than segfaulting.

Good stuff.

John

[John Spray]

Post by John Spray
I'd be happy with letting the plugins give an icon name relative to the
referencer data directory, and looking it up in
onEanbledpluginsPrefChanged using Utility::findDataFile. Obviously it's
not very useful for third-party plugins, but for stuff included in
referencer it'll do. An empty string would mean "use some default
icon", which could be the stock execute icon as it is now.

Speaking of which, might I suggest the cheeky little number at the
bottom of this page?
http://wiki.lyx.org/LyX/Icons

John

[Aurélien Naldi]

Post by John Spray

Post by Aurélien Naldi
* the plugin does not set it's icon. I could add one more field for
this, defaulting to stock:execute as now. Being limited to stock icons
would be a good start, especially as we would have to deal with
dependencies/installation for non-stock ones.

I'd be happy with letting the plugins give an icon name relative to the
referencer data directory, and looking it up in
onEanbledpluginsPrefChanged using Utility::findDataFile. Obviously it's
not very useful for third-party plugins, but for stuff included in
referencer it'll do. An empty string would mean "use some default
icon", which could be the stock execute icon as it is now.
The UI should go into the Documents menu as well as the toolbar, I think
-- that should just require adding a bit to the UI XML.

I will have a look at this, the icon you quoted in your other mail is
fine.

Post by John Spray

Post by Aurélien Naldi
Do you have any other problem with it, or is it ok to go in once you
have a working python class for documents ?

I've committed it, with a couple of naming changes, and modified it (as
well as the metadata plugin stuff) to use a python document class
(PythonDocument.[Ch]). It's getting the keys correctly, but I'm getting
"no pipe defined. Is lyx configured ?". Could be because I never set
the pipe location explicity that lyx is using a default location which
isn't stored in the config file?

Yep, but I'm not sure what is the default behaviour of lyx, does it have
a default path or does it only enable the pipe if the config option is
set ?

Do you have a files named ~/.lyxpipe.in/out or ~/.lyx/lyxpipe.in/out ?
I don't have any of them if I comment out the line from the config
file...

Post by John Spray
I've sorted the sensitivity issue by moving the plugin ui initialisation
out of constructMenu and to the end of constructUI, so that it's set up
after docview_ and can query whether any docs are selected.
In the spirit of emulating every other maintainer I've ever had to deal
with, I'm nitpicking coding style. In if statements, please keep the
"{" on the same line as the if, not on the next line.

Great for these two things. Usually, I always let the opening "{" on the
same line.

Post by John Spray
* Show UI for exceptions raised by python plugins
* Sort out sensitivity and icons for document action plugins
* Add a bunch of checking in python calls for correct types etc,
and give errors for bad plugins rather than segfaulting.

All of this would be very nice, but what is the remaining problem with
sensitivity ? Do you want to add a single/multiple document and a custon
sensitivity test before release ? I don't see a problem with this but
without a more complete python API this would be useless. Maybe making a
release to spread the world and encouraging plugin writers to discuss
the API for another release would be better.

I'll do a clean svn checkout to test it and maybe look at the icon and
document menu stuff. Don't expect much though: I'm away on sunday and
back at work next week...

[John Spray]

Post by Aurélien Naldi
Yep, but I'm not sure what is the default behaviour of lyx, does it have
a default path or does it only enable the pipe if the config option is
set ?
Do you have a files named ~/.lyxpipe.in/out or ~/.lyx/lyxpipe.in/out ?
I don't have any of them if I comment out the line from the config
file...

I don't have a .lyxpipe* or a .lyx/.lyxpipe*.

Post by Aurélien Naldi
Great for these two things. Usually, I always let the opening "{" on the
same line.

Post by John Spray
* Show UI for exceptions raised by python plugins
* Sort out sensitivity and icons for document action plugins
* Add a bunch of checking in python calls for correct types etc,
and give errors for bad plugins rather than segfaulting.

All of this would be very nice, but what is the remaining problem with
sensitivity ? Do you want to add a single/multiple document and a custon
sensitivity test before release ?

Oops, the point about sensitivity was written before I fixed the
enabling/disabling glitch. Never mind. The single/multiple distinction
can indeed wait.

John

[Aurélien Naldi]

Post by John Spray

Post by Aurélien Naldi
Yep, but I'm not sure what is the default behaviour of lyx, does it have
a default path or does it only enable the pipe if the config option is
set ?
Do you have a files named ~/.lyxpipe.in/out or ~/.lyx/lyxpipe.in/out ?
I don't have any of them if I comment out the line from the config
file...

I don't have a .lyxpipe* or a .lyx/.lyxpipe*.

Then you should probably set lyx up, I guess it doesn't do anything when
it is not configured... The config option is in the "directories"
section (not sure of the english name).
Can you add your version of the lyx plugin to svn, so that I get the
fully working version ?


PS: I added the action to the document menu, it was indeed
straightforward. I'll send you another patch if I get the icon thing
working.

[John Spray]

Post by Aurélien Naldi
Then you should probably set lyx up, I guess it doesn't do anything when
it is not configured... The config option is in the "directories"
section (not sure of the english name).

It would be vastly preferable to be able to be able to do this without
the user having to alter their lyx configuration. Could you perhaps ask
on lyx-devel about this?

To clarify, if I start lyx 1.5.1 with no .lyx directory, it runs through
its configuration script, and by default creates no pipes. Seems rather
perverse behaviour to me, but this is lyx so I wouldn't be too
surprised...

Post by Aurélien Naldi
Can you add your version of the lyx plugin to svn, so that I get the
fully working version ?

Done, sorry.

John

[John Spray]

Post by John Spray

Post by Aurélien Naldi
Then you should probably set lyx up, I guess it doesn't do anything when
it is not configured... The config option is in the "directories"
section (not sure of the english name).

It would be vastly preferable to be able to be able to do this without
the user having to alter their lyx configuration. Could you perhaps ask
on lyx-devel about this?

Hrmpy, according to this
http://wiki.lyx.org/LyX/LyXServer
it is necessary to set that setting to activate lyxserver. How
annoying.

John

[Aurélien Naldi]

Post by John Spray

Post by Aurélien Naldi
Then you should probably set lyx up, I guess it doesn't do anything when
it is not configured... The config option is in the "directories"
section (not sure of the english name).

It would be vastly preferable to be able to be able to do this without
the user having to alter their lyx configuration. Could you perhaps ask
on lyx-devel about this?
To clarify, if I start lyx 1.5.1 with no .lyx directory, it runs through
its configuration script, and by default creates no pipes. Seems rather
perverse behaviour to me, but this is lyx so I wouldn't be too
surprised...

I'm not going to start a flamewar about this :D
I could ask if they are willing to create the pipe by default, but this
would probably take ages. In the meantime, as long as we document that
this does not work unless lyx is configured I find it reasonable. I
would much prefer lyx adding dbus support or similar, but let's not
dream ;)
At least this way it needs to be configured only in lyx, that already
better than what I used before!

Post by John Spray

Post by Aurélien Naldi
Can you add your version of the lyx plugin to svn, so that I get the
fully working version ?

Done, sorry.

Thanks. And while I am at it, could you please remove the "print l" line
printing my whole lyx config file on the console ? It is not a big deal
but still bad looking.

[John Spray]

I've found that I can use the lyxclient tool that comes with lyx to
insert citations without altering my lyx configuration. I believe it
uses sockets rather than pipes. I've hacked the lyx plugin to use
lyxclient instead of pipes (sorry for demolishing your code). Using an
external tool is not ideal, but I think it's important to "Just work"
rather than needing to provide instructions on altering lyx config. I
believe lyxclient is part of a default lyx install, at least on linux
(which is currently the only place referencer runs).

I've committed your code for setting icons, thanks. It is a bit
convoluted but I think that's more GTK's fault than yours. Anyway, it
works and it's self-contained, so I don't think it's a problem. I've
added data/lyx.png.

Perhaps the python code that the lyx people have would let us do this
without using external program, in which case that would be a neater
way.

I've taken the random print statements out of lyx.py, although you'll
find that the between-release svn code is often thick with overly
verbose stuff like that. That one was a little gratuitous, I agree.

I think we're pretty much good to go, apart from a bit more error
handling stuff that I'll do on the C++ side.

John

[Aurélien Naldi]

Post by John Spray
I've found that I can use the lyxclient tool that comes with lyx to
insert citations without altering my lyx configuration. I believe it
uses sockets rather than pipes. I've hacked the lyx plugin to use
lyxclient instead of pipes (sorry for demolishing your code). Using an
external tool is not ideal, but I think it's important to "Just work"
rather than needing to provide instructions on altering lyx config. I
believe lyxclient is part of a default lyx install, at least on linux
(which is currently the only place referencer runs).

As I mentioned, kile does support quoting through the lyxpipe as well,
getting a working citation to kile with the same code would be nice :)
I have just looked at it, it looks like kile uses ~/.lyxpipe.in/out by
default. So the quotation plugin could check lyx config file. If
something is found here, test if the file exists. If they do, use it. If
they don't test if ~/lyxpipe.in exist and use it if it does. If all of
the above fail, then it can use lyxclient.
I don't have time right now to do this (I'm supposed to have left
already) but I'm willing to do it tonight or early next week, if you
agree.

Post by John Spray
I've committed your code for setting icons, thanks. It is a bit
convoluted but I think that's more GTK's fault than yours. Anyway, it
works and it's self-contained, so I don't think it's a problem. I've
added data/lyx.png.

Thanks, I'll look at ways to improve/clen it up ASAP.

Post by John Spray
Perhaps the python code that the lyx people have would let us do this
without using external program, in which case that would be a neater
way.
I've taken the random print statements out of lyx.py, although you'll
find that the between-release svn code is often thick with overly
verbose stuff like that. That one was a little gratuitous, I agree.
I think we're pretty much good to go, apart from a bit more error
handling stuff that I'll do on the C++ side.

I bet I'll let you handle this one.

Thanks again for your work on it, I can't wait for the next release!

[Aurélien Naldi]

Post by Aurélien Naldi

Post by John Spray
I've found that I can use the lyxclient tool that comes with lyx to
insert citations without altering my lyx configuration. I believe it
uses sockets rather than pipes. I've hacked the lyx plugin to use
lyxclient instead of pipes (sorry for demolishing your code). Using an
external tool is not ideal, but I think it's important to "Just work"
rather than needing to provide instructions on altering lyx config. I
believe lyxclient is part of a default lyx install, at least on linux
(which is currently the only place referencer runs).

As I mentioned, kile does support quoting through the lyxpipe as well,
getting a working citation to kile with the same code would be nice :)
I have just looked at it, it looks like kile uses ~/.lyxpipe.in/out by
default. So the quotation plugin could check lyx config file. If
something is found here, test if the file exists. If they do, use it. If
they don't test if ~/lyxpipe.in exist and use it if it does. If all of
the above fail, then it can use lyxclient.
I don't have time right now to do this (I'm supposed to have left
already) but I'm willing to do it tonight or early next week, if you
agree.

Here is a patch to the lyx plugin putting back the lyxpipe code.
I also moved the lyxClientBinary detection to the initialisation part
of the plugin, It is not going to slow down things too much but do we
really want to try to detect it at every run ? If you want referencer
to find a lyxclient installed after its startup, I can add a function
for the detection and run it whenever we are trying to use lyxclient
and we don't have a path to the file.

Back to the actual patch: as I said it adds a default path to the
lyxpipe, which is the one used by kile. This will first try to use a
lyx-configured pipe. If it is not configured or not present, it will
try the default one, and then fallback to lyxclient. It does quote
properly in kile and in lyx using either the pipe or lyxclient.

[Aurélien Naldi]

Post by Aurélien Naldi
Here is a patch to the lyx plugin putting back the lyxpipe code.

And here is the patch itself...

[John Spray]

Works for me, committed.

John

[Aurélien Naldi]

Post by John Spray
I've committed it, with a couple of naming changes, and modified it (as
well as the metadata plugin stuff) to use a python document class
(PythonDocument.[Ch]). It's getting the keys correctly, but I'm getting
"no pipe defined. Is lyx configured ?". Could be because I never set
the pipe location explicity that lyx is using a default location which
isn't stored in the config file?

I'm affraid you forgot to svn add the lyx plugin.

[Aurélien Naldi]

Post by John Spray

Post by Aurélien Naldi
* the plugin does not set it's icon. I could add one more field for
this, defaulting to stock:execute as now. Being limited to stock icons
would be a good start, especially as we would have to deal with
dependencies/installation for non-stock ones.

I'd be happy with letting the plugins give an icon name relative to the
referencer data directory, and looking it up in
onEanbledpluginsPrefChanged using Utility::findDataFile. Obviously it's
not very useful for third-party plugins, but for stuff included in
referencer it'll do. An empty string would mean "use some default
icon", which could be the stock execute icon as it is now.
The UI should go into the Documents menu as well as the toolbar, I think
-- that should just require adding a bit to the UI XML.

Here is another patch adding custom icon for plugins (and an entry in
the document menu).
It is a bit messy, but I haven't found any cleaner way to do it (taken
and adapted from http://lugod.org/presentations/gtkmm/menus.html )

It can probably be a bit improved, especially by avoiding creating a
stock icon each time, but by testing first if one exists:
* if a stock icon with the name specified by the plugin exists, take it.
This will allow plugin to use whichever stock icons they want.
* if the plugin has been enabled, disabled and enabled again, we can
probably avoid recreating it again.

Is there a better way to do it or can it go with these improvements ?

[John Spray]

Post by Aurélien Naldi
Here is another patch adding custom icon for plugins (and an entry in
the document menu).

You forgot to attach it.

[Aurélien Naldi]

Post by John Spray

Post by Aurélien Naldi
Here is another patch adding custom icon for plugins (and an entry in
the document menu).

You forgot to attach it.

Indeed.

[Aurélien Naldi]

Just discard my previous patch and question about the UIManager, it is
damn simple. Now we just need one more field in the plugin to store the
merge id and remove it from the ui on plugin unload (I guess we would
still have the action somewhere, until referencer is restarted). This
thing is soooo cool.