If you click on the edit button now in the Graphics dialog the
server application is launched by the LinkBack framework and the
LinkBack data is sent back to it for editing. After modifying and
saving, the updated LinkBack data and the updated PDF is sent back
to LyX. LyX will update the files and redisplay the PDF (see P.S.).
I am wondering... Why not just stay with LinkBack data and use the
external framework a la XFig? If you define a converter from
LinkBack to pdf then the Converter cache will automatically takes
care of monitoring file on disk.
There is no way to make a PDF (or anything else understandable) out of
the linkback data (without going via the LinkBack/PasteBoard bridge).
So in any case we have to store the PDF and the linkback data.
* Implementation
The Implementation is based on the official Objective-C framework
which I wrap in a C++ LinkBackProxy class.
With InsetExternal I guess you wouldn't need that...
Looking into that. Looks interesting.
This is used in CutAndPaste.cpp (to get the LinkBack data from the
clipboard into the foo.pdf.linkback file) and in the EmbeddedFile
objects in Buffer::embeddedFiles() (to hold the connection when
editing a .linkback graphic, and to handle the updated data).
I think this part must stay within the clipboard code. That is the
part that saves the data into a file. CutAndPaste should remain
focused on LyX data only IMHO.
I think it's the natural place to handle non-text pastes as well. It's
where text is pasted into the buffer, and in the same way graphics
fits there which is pasted into the buffer.
Stefan
