GNOME Bugzilla – Bug 543503
Support for SyncTeX
Last modified: 2011-04-08 08:41:47 UTC
forward and backwards synchronization for pdf and dvi with TeX source
Some context: SyncTeX [1] by Jérôme Laurens provides a means for synchronization between input (i.e. (La)TeX) and output (i.e. pdf or dvi). SyncTeX was merged into the modern LaTeX processors pdfTeX and XeTeX in TeXlive 2008. If enabled it will establish a map between lines and words in the input source document and boxes and word nodes in the output document. This is achieved by hooking into the compilation process and recording the map as a '.synctex' text file next to the output PDF (or DVI). This process is described in detail in a video recorded during the TUG 2008 conference [2]. The purpose of synchronization: There are many people using free desktops who type their technical/scientific/scholarly/private documents with (La)Tex. These documents can get very long and involved (think PhD theses). When revising, redacting and tuning these documents one has to jump between the source and the output often to check the effect of a change in the source. (Sometimes documents even have to be "debugged", i.e., they can break.) Synchronization is a real time saver, because it allows to jump from output to source and from source to output by a simple click, without scrolling or searching, because the synchronization is a unique mapping. A scenario of usage: 1. The author detects misplaced figure while proof-reading the PDF output in Evince. He ctrl-clicks the figure caption in Evince. Via a Dbus signal the editor is focused and navigates cursor in the source to the position declaring the figure in question and highlights it. 2. The author corrects the error and recompiles the document. A moment later Evince reloads the document automatically, but the viewport does not display the figure anymore, because the document was reflown in the process. 3. The author ctrl-clicks the caption in the source and via a Dbus signal Evince is instructed to navigate to the position in question (and to optionally highlight the text affected) Why now? There were a few earlier approaches to this feature, but they were encumbered with problems. The most widely known technique were "source specials" in DVI output. But only few authors nowadays rely on DVI output and direct PDF output with pdfTeX is much more common today. Another approach was the pdfSync technique, but it relied on inserting nodes into the PDF, which led to changing line breaks and other compatibility problems. SyncTex has been officially endorsed and integrated in the TeX engines. It is available by default in TexLive 2008, which is not yet in many distros, but an installed base will appear in a few months. Why Evince? Evince is the premier document viewer in the Gnome desktop. Users typesetting documents in the Gnome desktop are likely to use Evince to view their output. Other available viewers are Xpdf, xdvi, and Adobe Reader. All of those pose severe usability or functionality limitations. On the KDE desktop there are many options to typeset documents with LaTeX like Kile, TexMaker, or LyX. These programs are typical KDE tools with three lines of crowded toolbars and many panels, making them full blown expert IDEs. This is not needed in a Gnome desktop. It would suffice if Evince read the SynTeX file with the help of the parser written in C available at [1] and to expose a Dbus interface that enables synchronization with the text editor, be that e.g. Gedit or Gvim. No GUI or preference settings are expected to be necessary for this. Evince already features a transparent feature that monitors changes in the PDF document and refreshes it. It just works. A synchronization feature should follow the same principle. Reference implementation There are a few other viewers which implement SyncTex already. The most interesting is a new integrated TeX editor called TeXworks that uses Qt and Poppler written in C++ available at [3]. It is an integrated solution so apparently no Dbus interface is used, but the code in the poppler-based viewer may be instructive. There is also a presentation video available at [4]. Who can do it? Obviously there are two sides to this feature. The output viewer and the source editor. A good deal of thought has to be devoted to design the proper Dbus interface and the implementation is not really trvial. Perhaps this is something for a Google Summer of Code student. [1] http://itexmac.sourceforge.net/SyncTeX.html [2] http://river-valley.tv/conferences/tug2008/#0302-Jerome_Laurens [3] http://code.google.com/p/texworks [4] http://river-valley.tv/conferences/tug2008/#0103-Jonathan_Kew
Something like that would be welcome for sure.
+1, this is really important to me.
http://code.google.com/p/lundgaard/
Created attachment 132885 [details] [review] The patch from the above project
Created attachment 133238 [details] [review] improved synctex patch Clean up the synctex patch a bit. * Applies to the current SVN trunk. * Use g_snprintf instead of sprintf to prevent possible buffer overflow. * Use GFile APIs to get file path / directory. Use the directory as the working directory when invoking synctex. * Don't hardcode editor to invoke. Let synctex use the environment variable SYNCTEX_EDITOR.
Just a bit extra info on the patch from http://code.google.com/p/lundgaard/ I made a website with a little guide to getting synctex working in evince. It doesn't use the improved patch, but instructions should be very similar. http://lundgaard.wep.dk/index.php?page=synctex There's a script that will compile your latex documents and open synctex for you, and a patch for geany so it will support synctex it as well.
Another different patch is here: http://mail.gnome.org/archives/evince-list/2009-May/msg00022.html with support for both dvi specials and synctex. We really need to review one of them and apply I think.
Here’s a problem. Many Latex writers leave a paragraph of text on one line and let the editor do soft-wrapping. This is helpful for sharing with collaborators and for later editing of the text, because the paragraph will be reflown automatically. It’s not line-based source code after all. Unfortunately just opening the source file only at a specific line number is not enough if this method is used, because a line might be very long. I would think it’s necessary to also supply the column number and best of all highlight the text in question. Neither Vim nor Gedit can open a file specifying a column number as far as I know. Both only support the +%{line} syntax. So, if synctex is called with SYNCTEX_EDITOR only I think it’s not enough.
It would definetly be nice to have syncronization by column, but the synctex commandline tool doesn't support it either. It should be possible to do with synctex and the author of the synctex CLI-tool once said he would implement syncronization by column later on, but he didn't do it yet. If the synctex commandline tool had support for columns, it should be fairly simple to patch gedit and/or vim to support opening files at a specified column number or an editor that already supports it could be used. The text editor Geany has a --column argument that could be used. (I use Geany for latex editing, since it plays well with synctex and has as-you-type spellchecking).
*** Bug 584998 has been marked as a duplicate of this bug. ***
Dongsheng Xing's patch referred to above (http://mail.gnome.org/archives/evince-list/2009-May/msg00022.html) needs some minor updates to apply cleanly to evince 2.27.90. I'm attaching the updated version. Could someone please review this patch?
Created attachment 141787 [details] [review] Dongsheng Xing's patch, updated for evince 2.27.90
Yozo Hida's patch also has some nice features, such as adding a command-line option to highlight part of a page. I'm attaching an updated version of that patch as well. If I get some spare time, I'll look into integrating the two patches.
Created attachment 144755 [details] [review] Yozo Hida's patch, updated for evince 2.28
Created attachment 144856 [details] [review] Patch combining Dongsheng Xing's and Yozo Hida's patches Here's a first attempt at a combined patch that has Dongsheng Xing's inverse search patch along with Yozo Hida's and Thomas Lundgaard's code for forward search. Seems to work for me.
I forgot to mention that there's a small issue with the current directory that needs to be worked out. Also, instructions for usage will follow soon.
Created attachment 145000 [details] [review] Patch combining Dongsheng Xing's and Yozo Hida's patches
Do distributions have already packages for TexLive 2008? ubuntu doesn't seem to have it. I would like to include SyncTex support for 2.30 (it's in our RoadMap indeed http://live.gnome.org/Evince/Roadmap) but in this moment it's not easy to test it . . .
Debian has pre-release packages for texlive 2009 at http://people.debian.org/~preining/TeX/ These work pretty well for me. I've done some testing and the above patch works well. I've been very busy but will post my methods and scripts as soon as I have some spare time.
Johan, what happened to the use-absolute-page parameter? Without it Evince will interpret the page number from synctex as the page label, which is not necessarily congruent with the physical page because often the page label numbering starts at the main matter in a document.
I took that out when I first merged the patches. I tried a bunch of documents (including ones with page numbering not starting at 1), and it didn't seem to make any difference to me. But it could always be added back in.
I really think you should add it again. When using latex for large documents, you often have the first few pages numbered with roman numbers. On these pages you have the table of contents, foreword, etc. On these pages, the page label is set to the roman numbers, and the page with page label 1, thus doesn't begin on page 1.
Patch need updating for 2.29.x
(In reply to comment #19) > Do distributions have already packages for TexLive 2008? ubuntu doesn't seem to > have it. I would like to include SyncTex support for 2.30 (it's in our RoadMap > indeed http://live.gnome.org/Evince/Roadmap) but in this moment it's not easy > to test it . . . Fedora 13 will have TexLive 2009 support. TexLive2009 packages are currently available for Fedora 11, 12 and Rawhide. The current patch seems to execute a command to synchronize with the editor instead of using D-Bus. Is this preferable to using D-Bus? I am thinking a Dbus signal should be emitted by evince when you Ctrl-clik in the doc with the proper data. Then, editors should listen to this signal to synchronize... Thinking a little bit more, it seems that we need both approaches, since we would also like to support this in the windows port (which I presume does not need dbus) and/or editors that don't use DBUS or can't be patched.
(In reply to comment #25) > (In reply to comment #19) > > Do distributions have already packages for TexLive 2008? ubuntu doesn't seem to > > have it. I would like to include SyncTex support for 2.30 (it's in our RoadMap > > indeed http://live.gnome.org/Evince/Roadmap) but in this moment it's not easy > > to test it . . . > > Fedora 13 will have TexLive 2009 support. TexLive2009 packages are currently > available for Fedora 11, 12 and Rawhide. > > The current patch seems to execute a command to synchronize with the editor > instead of using D-Bus. Is this preferable to using D-Bus? No it's not. > I am thinking a Dbus > signal should be emitted by evince when you Ctrl-clik in the doc with the > proper data. Then, editors should listen to this signal to synchronize... Exactly that's the idea. This way we don't depend on any editor. > Thinking a little bit more, it seems that we need both approaches, since > we would also like to support this in the windows port (which I presume does > not need dbus) and/or editors that don't use DBUS or can't be patched. Well, I would focus on implementing this for unix and we'll see if it's possible to port it to windows.
The problem right now is also that configuring the editor to use with --editor is rather hard to do. I don’t think we can expect to do this from normal users. For example: evince --editor="synctex edit -o %p:%x:%y:%o -x 'gedit +%%{line} "$directory/"%%{input}'" MyDocument.pdf Is it preferable to keep relying on an external binary to do the mapping, or to somehow include the code that[1] in the package? But independently from the implementation, I find the functionality rather cool. It is really helpful when working with a markup language like LaTeX that you can jump back and forth easily. [1] http://itexmac.sourceforge.net/SyncTeX.html
Regarding implementation, I am trying to rewrite the patch to: 1. include the synctex library source (taken from pdftex) 2. modify evview and evdocument so evview sends a signal when a synctex sync is performed. 3. Modify shell so it listen for the previous signal and propagates the widget signal as a DBUS signal.
Some updates, part 1 and 2 are mostly done. So I started to work in part 3 aka Dbus signal for view-to-source syncrhonization and also DBUS for source-to-view sync, so I am wondering which is the best in terms of DBUS interface. So would be nice if we can make an spec for view-to-source synchronization, and also controlling a view remotely by dbus (including source-to-view syncrhonization)... I added bug #606223 to track this more general feature
Created attachment 151906 [details] Sequence of patches to synctex pdf support Here there is an updated set of patches to add synctex support to Evince through DBUS. For the moment, only view to source sync is implemented and only for pdfs.
Created attachment 157658 [details] [review] Updated patch Updated patch against current master. Sync to source is using a DBUS signal.
Created attachment 158239 [details] [review] Updated patch Updated patch containing forward and backward sync using DBus + new method in the Evince Daemon to get the evince process runing a given uri. I think this patch is in good shape, so please review when possible.
Review of attachment 158239 [details] [review]: Jose, thank you very much for the patch. Some general comments: - Follow coding style: space between function name and (, blank line between variable declaration block and function body, etc. - Do not include in the patch changes not related to this bug, like including deprecated flags in Makefile.am Some more comments inline. ::: backend/pdf/ev-poppler.cc @@ +328,3 @@ + tmp = g_strdup(uri); + if (uri != NULL) { + pdf_document->scanner = synctex_scanner_new_with_output_file(tmp+7, NULL, 1); tmp + 7? why? @@ +331,3 @@ + if (pdf_document->scanner) { + synctex_scanner_display(pdf_document->scanner); + } You are leaking tmp here. Why do you need to duplicated it indeed? @@ +898,3 @@ + } + return result; +} Those methods (pdf_document_sync_to_source and pdf_document_sync_to_view) don't use anything from the backend, I guess they can be implemented in libdocument so that they can be used for any backend where synctex is supported, like dvi. ::: libdocument/ev-document.c @@ +349,3 @@ + EvDocumentClass *klass = EV_DOCUMENT_GET_CLASS (document); + + return klass->sync_to_source (document, page, h, v); What is h and v? You are assuming all backends implement sync_to_source method, however only pdf backend implements it, fo the other backends, sync_to_source will be NULL and this will crash. @@ +360,3 @@ + EvDocumentClass *klass = EV_DOCUMENT_GET_CLASS (document); + + return klass->sync_to_view (document, file, line, col); Same here. @@ +362,3 @@ + return klass->sync_to_view (document, file, line, col); +} + Again, I'm not sure we need to implement these methos in the backends, it might be enough to have a method to know whether syntex is supported for the given backend, something like ev_document_support_synctex() or something like that ::: libdocument/ev-document.h @@ +118,3 @@ + + GList ** (* sync_to_view) (EvDocument *document, + gchar *file, Use const gchar *file ::: libview/ev-view.c @@ +1742,3 @@ + EvSourceLink *source = (EvSourceLink *) list_source->data; + g_signal_emit (view, signals[SIGNAL_SYNC_SOURCE], 0, source->uri, source->line, source->col); + } list_source is leaked here ::: shell/ev-daemon.c @@ +68,3 @@ +static gboolean ev_daemon_get_viewer_for_uri (EvDaemon *ev_daemon, + const gchar *uri, + DBusGMethodInvocation *context); I don't like the word viewer in this context, what about ev_daemon_find_document()? it's what we are doing indeed. ::: shell/ev-window.c @@ +103,2 @@ #endif /* ENABLE_DBUS */ I would like to have dbus stuff separated from ev-window.c.
Hey Carlos, thanks for the review. (In reply to comment #33) > Review of attachment 158239 [details] [review]: > > Jose, thank you very much for the patch. Some general comments: > > - Do not include in the patch changes not related to this bug, like including > deprecated flags in Makefile.am > I don't get what you mean... I tried to include only changes related to the bug. The changes in the Makefile.am are to compile the synctex parser that the patch adds. > Some more comments inline. > > ::: backend/pdf/ev-poppler.cc > @@ +328,3 @@ > + tmp = g_strdup(uri); > + if (uri != NULL) { > + pdf_document->scanner = synctex_scanner_new_with_output_file(tmp+7, > NULL, 1); > > tmp + 7? why? tmp is an uri, so it contains "file://" the + 7 is just to get this string out. Please advice for better solution. > > @@ +331,3 @@ > + if (pdf_document->scanner) { > + synctex_scanner_display(pdf_document->scanner); > + } > > You are leaking tmp here. Why do you need to duplicated it indeed? > > @@ +898,3 @@ > + } > + return result; > +} > > Those methods (pdf_document_sync_to_source and pdf_document_sync_to_view) don't > use anything from the backend, I guess they can be implemented in libdocument > so that they can be used for any backend where synctex is supported, like dvi. > > ::: libdocument/ev-document.c > @@ +349,3 @@ > + EvDocumentClass *klass = EV_DOCUMENT_GET_CLASS (document); > + > + return klass->sync_to_source (document, page, h, v); > > What is h and v? You are assuming all backends implement sync_to_source method, > however only pdf backend implements it, fo the other backends, sync_to_source > will be NULL and this will crash. > > @@ +360,3 @@ > + EvDocumentClass *klass = EV_DOCUMENT_GET_CLASS (document); > + > + return klass->sync_to_view (document, file, line, col); > > Same here. > > @@ +362,3 @@ > + return klass->sync_to_view (document, file, line, col); > +} > + > > Again, I'm not sure we need to implement these methos in the backends, it might > be enough to have a method to know whether syntex is supported for the given > backend, something like ev_document_support_synctex() or something like that > I sort of agree, I was worried about adding exactly the same implementation in the dvi backend. However, synctex is somehow specific to dvi and pdf... Also in dvi the sync method could be more specific to the backend by using source specials if these are available and synctex not. So I am not really sure about which is the best option. I will correct all other things and split the DBUS methods out of ev-window. However, I don't know how to do this for the signals, since they must be created in the init_class method
Created attachment 159125 [details] [review] Latest synctex patch Carlos, here is an updated patch with all comments addressed and some refactoring. Please review when possible. Please observe that I didn't include the directory cut-n-paste/synctex (which only contains the synctex parser) in the patch to make it smaller.
Created attachment 159130 [details] [review] Latest synctex patch Sorry, there were some crashes in the previous patch. Here there is an updated one.
I've been trying to apply the patch to evince_2.30.0-0ubuntu1 for testing purposes With difficulty... Am I doing the right thing in grabbing https://bugzilla.gnome.org/attachment.cgi?id=159130 and only the cut-n-paste/ directory bit from https://bugzilla.gnome.org/attachment.cgi?id=158239 ?? As of now I get this (initial error) when I try to build the package: ev-document.c:28:28: error: synctex_parser.h: No such file or directory (I have confirmed that cut-n-paste/aynctex_parser.h _does_ exist) I've also tried with git and applying the patches, it instead stalls at make[3]: *** No rule to make target `../cut-n-paste/synctex/libsynctex.la', needed by `libevdocument.la'. Stop. Is this just me going about things wrong? (And if so, any hints?)
(In reply to comment #37) > I've been trying to apply the patch to evince_2.30.0-0ubuntu1 for testing > purposes > With difficulty... the patch is supposed to be applied against master, so maybe there are problems with 2.30.0. > > Am I doing the right thing in grabbing > https://bugzilla.gnome.org/attachment.cgi?id=159130 > and only the cut-n-paste/ directory bit from > https://bugzilla.gnome.org/attachment.cgi?id=158239 > ?? > > As of now I get this (initial error) when I try to build the package: > ev-document.c:28:28: error: synctex_parser.h: No such file or directory > (I have confirmed that cut-n-paste/aynctex_parser.h _does_ exist) > > I've also tried with git and applying the patches, it instead stalls at > make[3]: *** No rule to make target `../cut-n-paste/synctex/libsynctex.la', > needed by `libevdocument.la'. Stop. > > Is this just me going about things wrong? (And if so, any hints?) Sorry, the last patch is only meant to Carlos for Review, since I didn't include the directory cut-n-paste/synctex to make it shorter. I will try to attach a proper patch for you to test (against gnome 2.30) but now I am away from work and my inet access is very limited.
(In reply to comment #37) > I've been trying to apply the patch to evince_2.30.0-0ubuntu1 for testing > purposes > With difficulty... > Ok, I updated my github branch so you can try from there. Let me know if you still have issues. My branch is in github.com/jaliste/evince
(In reply to comment #39) > My branch is in github.com/jaliste/evince I've compiled your current git branch (3ce6cec6385d), but I have no idea how to use it. Can you give a hint, how to make evince to actually jump to some position, or, for the other direction, what combination of modifier keys and mouse clicks triggers the synchronization of the editor. Thanks, Jan
(In reply to comment #40) > (In reply to comment #39) > > My branch is in github.com/jaliste/evince > > I've compiled your current git branch (3ce6cec6385d), but I have no idea how to > use it. > Can you give a hint, how to make evince to actually jump to some position, or, > for the other direction, what combination of modifier keys and mouse clicks > triggers the synchronization of the editor. > > Thanks, > Jan Hi Jan, thanks for your interest in synctex support. Unfortunately, my work is at the moment useless, since the idea was that the user needs to do nothing to have synctex support. It's up to the editor app to add the proper code to comunicate with Evince. I plan (and I think Carlos won't merge synctex support until I fix this) to do a simple gedit plugin for that and in this way synctex support will just work on Gnome. Greetings, José
(In reply to comment #41) > > Can you give a hint, how to make evince to actually jump to some position, or, > > for the other direction, what combination of modifier keys and mouse clicks > > triggers the synchronization of the editor. > > Hi Jan, thanks for your interest in synctex support. Unfortunately, my work is > at the moment useless, since the idea was that the user needs to do nothing to > have synctex support. It's up to the editor app to add the proper code to > comunicate with Evince. I plan (and I think Carlos won't merge synctex support > until I fix this) to do a simple gedit plugin for that and in this way synctex > support will just work on Gnome. Chicken and egg... How would editor and evince communicate then? By dbus? If so, is the dbus interface for this already implemented in your code? I understand auctex, the latex mode of emacs, is already able to do forward/backward synchronisation via dvi and source specials. Now that newer emacs versions support dbus, I'd be happy to try to implement the editor part in emacs as well, and thereby get a bit more momentum to this effort. I'd be glad to help testing your gedit plugin as soon as it takes shape. Cheers, Jan
(In reply to comment #41) > (In reply to comment #40) > > (In reply to comment #39) > > > My branch is in github.com/jaliste/evince > > > > I've compiled your current git branch (3ce6cec6385d), but I have no idea how to > > use it. > > Can you give a hint, how to make evince to actually jump to some position, or, > > for the other direction, what combination of modifier keys and mouse clicks > > triggers the synchronization of the editor. > > > > Thanks, > > Jan > > Hi Jan, thanks for your interest in synctex support. Unfortunately, my work is > at the moment useless, since the idea was that the user needs to do nothing to > have synctex support. It's up to the editor app to add the proper code to > comunicate with Evince. I plan (and I think Carlos won't merge synctex support > until I fix this) to do a simple gedit plugin for that and in this way synctex > support will just work on Gnome. Have you considered working with the author of GeditLatexPLugin ? http://www.michaels-website.de/gedit-latex-plugin/ I use this daily, it is a really good plugin, definately the best Latex editor for GNOME at the moment.
(In reply to comment #42) > (In reply to comment #41) > > > Can you give a hint, how to make evince to actually jump to some position, or, > > > for the other direction, what combination of modifier keys and mouse clicks > > > triggers the synchronization of the editor. > > > > Hi Jan, thanks for your interest in synctex support. Unfortunately, my work is > > at the moment useless, since the idea was that the user needs to do nothing to > > have synctex support. It's up to the editor app to add the proper code to > > comunicate with Evince. I plan (and I think Carlos won't merge synctex support > > until I fix this) to do a simple gedit plugin for that and in this way synctex > > support will just work on Gnome. > Chicken and egg... > How would editor and evince communicate then? By dbus? Yes, If so, is the dbus > interface for this already implemented in your code? Yes, my patch adds exactly that. > I understand auctex, the latex mode of emacs, is already able to do > forward/backward synchronisation via dvi and source specials. Now that newer > emacs versions support dbus, I'd be happy to try to implement the editor part > in emacs as well, and thereby get a bit more momentum to this effort. Great to hear that, normally I am at #evince chanel on irc.gnome.org if you need some help. But in my branch you can look for the ev-window-service.xml in the shell/ directory. It has the interface you need. To get a path to the windows dbus object you need to spawn a evince instance and then connect to the evince daemon DBUS interface to get the dbus interface (see the ev-daemon-service.xml file in shell directory) > I'd be glad to help testing your gedit plugin as soon as it takes shape. > Cheers, > Jan Cheers Jan
(In reply to comment #43) > Have you considered working with the author of GeditLatexPLugin ? > http://www.michaels-website.de/gedit-latex-plugin/ > I use this daily, it is a really good plugin, definately the best Latex editor > for GNOME at the moment. John, I already work with him to add synctex support with evince (the internal preview already supports synctex). However, gedit-latex plugin is hardly going to become GNOME maintained. So some of us think that a new gedit plugin that after some time can get into the standard plugins distributed and maintained by GNOME would be a better choice, so synctex will just work in gnome. Greets Jose
Created attachment 162985 [details] [review] second patch. Patches rebased against master and ported to gdbus.
Created attachment 162986 [details] [review] third patch.
Created attachment 162987 [details] [review] Fourth patch. Add DBUS - Synctex glue
Created attachment 162988 [details] [review] First patch. Add synctex parser to cut-n-paste directory.
(In reply to comment #49) > Created an attachment (id=162988) [details] [review] > First patch. Add synctex parser to cut-n-paste directory. Hi Jose, care to push your updated patches to your git repository? It's so much easier to apply stuff from there, than to download and fiddle around with patches :-) Cheers, Jan
Created attachment 163326 [details] [review] Second patch. Add synctex support to libdocument Updated patch to libdocument. Corrected style, renamed sync_to_edit->backward_search and sync_to_view->forward_search, and assume that backward_search always return ONE result node.
Created attachment 163327 [details] [review] third patch. add synctex_support to libview. Updated patch.
Created attachment 163328 [details] [review] fourth patch. Add DBUS - Synctex API to the shell Updated patch
Created attachment 164711 [details] [review] First patch. Add synctex parser to cut-n-paste directory.
Created attachment 164712 [details] [review] Second patch. Libdocument.
Created attachment 164713 [details] [review] third patch. libview
Created attachment 164714 [details] [review] fourth patch. Shell + ev-daemon part.
I updated the patches according to comments on IRC.
Created attachment 164718 [details] [review] third patch. libview Sorry for the noise. in my previous patch I was leaking the sync_rects hashtable.
Created attachment 164719 [details] [review] fourth patch. Shell + ev-daemon part. same as before. fixes a leak.
I've applied all patches (with some modifications) to git master expect the ev-daemon part. We are still discussing the interaction with the clients. Thanks José, great work!.
There is a basic evince Dbus controller coded in python that we can use to discuss interaction with the clients. You can grab it at http://github.com/jaliste/gedit-synctex-plugin
Created attachment 164918 [details] [review] Last patch adding missing DBUS api. This last patch adds the following DBbus API to evince. * FindDocument method to ev-daemon that returns the instance of evince showing a given uri. * GetWindowList method to ev-application that returns an array of EvWindow DBUS paths. * WindowClosed signal on ev-window so that DBUS clients can know when the user has closed an Evince window.
Created attachment 165112 [details] [review] new DBUS API Here there is a new patch with minor corrections. it should be ready. Please review.
Review of attachment 165112 [details] [review]: Thanks for the patch, I've just pushed it to git master with several modifications, see comments below. ::: shell/ev-application.c @@ +753,3 @@ + if (g_strcmp0 (interface_name, APPLICATION_DBUS_INTERFACE) != 0) + return; I don't think we need to check this @@ +800,3 @@ + } else if (g_strcmp0 (method_name, "GetWindowList") == 0) { + GList *windows = ev_application_get_windows (application); + GVariantBuilder *builder; I prefer to use a stacked builder to avoid an allocation. @@ +814,3 @@ + + g_list_free (windows); + g_dbus_method_invocation_return_value (invocation, g_variant_new ("(as)", builder)); Does this work for you? have you tested it? it expects and array of strings, you are giving a builder. You need to call g_variant_builder_end to get the variant. @@ +826,3 @@ "</method>" + "<method name='GetWindowList'>" + "<arg type='as' name='window_list' direction='out'/>" There's a specific type for dbus object paths, 'o' that we should use instead of 's' ::: shell/ev-daemon.c @@ +337,3 @@ + } + + g_dbus_method_invocation_return_value (invocation, g_variant_new (doc->dbus_name)); This is wrong, g_variant_new() expects a format string as first argument, and dbus methods should always return a tuple, so it should be g_variant_new ("(s)", doc->dbus_name) ::: shell/ev-window.c @@ +338,3 @@ gpointer user_data); static void ev_window_update_max_min_scale (EvWindow *window); +static void ev_window_on_close (EvWindow *window); This should be protected by #ifdef ENABLE_DBUS too. Also I would use another name like ev_window_emit_closed()
Just a quick info since this bug has been fixed. I filed bug #623048 to track development of a synctex plugin for gedit.
This might not be the right place to ask... I'm trying to implement a vim plugin based on the outline of your gedit plugin. Progress so far is good, but I've come to the conclusion that the current evince dbus api requires polling, which could be avoided by using signals. Easily explained by an example: The editor is editing a latex project with a corresponding main.pdf file. The editor wants to SyncView, but theres no evince window with main.pdf open. The editor creates a proxy to org.gnome.evince.Daemon. The editor listens on dbus for NameOwnerChanged signal and starts evince with the pdf file as argument. The editor has to wait until the new evince window is ready. The problem is that, there is no way to tell when this happens. It is still not ready when it gets it's service name on dbus, because the only way to tell if it is the right window is by the FindDocument method on the evince.Daemon, so we have to wait until it has called the RegisterDocument method. If there had been a "DocumentRegistered" signal on the evince.Daemon interface, it would be problem solved. Currently you have to keep polling the FindDocument method. Please correct me if I've overlooked something. I hope it made any sense.
Peter, yes, currently you need to poll FindDocument. However, we will add an option to FindDocument so that ev-daemon spawns evince and only return after evince has registered it-self to the EvDaemon, see bug #625971. This still does not solve the whole problem, since evince calls RegisterDocument before loading the pdf, see bug #626561. To solve #626561, we'll probably use signals.
I've noticed that the problem stated in comment #67 has now been fixed. I still see a problem in relation to syntex in the current git version of Evince: SyncView needs absolute path to source file, but the SyncSource signal only gives the path relative to the pdf file and there is no way to get the uri of the pdf file, even if you know the name of the dbus window object from which the signal was send. To solve this SyncSource could give the absolute path, or there could be a getURI method on the window object. Otherwise the editor has to figure out the uri of the pdf file on its own.
Peter, your Concern about the signal not giving you the uri of the input source it's fair, and I will change it so the input_source is an URI. However, Please file new bugs (including this one) with the issues you are encountering. Thanks for implementing this in vim.
*** Bug 375539 has been marked as a duplicate of this bug. ***
*** Bug 380008 has been marked as a duplicate of this bug. ***
It would be very helpful if there were a non-dbus version of backward search too, in the form of an external editor command that could be specified as a commandline parameter to evince. e.g. when viewing a file, LyX could launch evince as: evince /path/to/file.pdf --backward-search-cmd="lyxclient -g %f %l"
Also, for non-dbus-based forward search: It would be helpful if evince could take some parameters that specified a rectangle on a specific page of a document that should be scrolled to the center of the window upon opening the document, so that synctex output could be used with greater accuracy than just jumping to the right page. Currently LyX has as its default forward search command something like: synctex view -i $$n:0:$$t -o $$o -x "evince -i %{page+1} $$o" It would be helpful if you could do: synctex view -i $$n:0:$$t -o $$o -x "evince -i %{page+1} $$o --jump-to-rect=%{x},%{y},%{h},%{v},%{width},%{height}" The point %{x},%{y} would be displayed at the middle of the page specified with the -i switch, and the rectangle %{h},%{v},%{width},%{height} could be selected by default to draw the user's eye to the text unit that the forward search point is contained within. For reference, here is the relevant output from "synctex help view": -x viewer-command Normally the synctex tool outputs its result to the stdout. It is possible to launch an external tool with the result. The viewer-command is a printf like format string with following specifiers. %{output} is the name specifier of the main document, without path extension. %{page} is the 0 based page number specifier, %{page+1} is the 1 based page number specifier. To synchronize by point, %{x} is the x coordinate specifier, %{y} is the y coordinate specifier, both in dots and relative to the top left corner of the page. To synchronize by box, %{h} is the horizontal coordinate specifier of the origin of the enclosing box, %{v} is the vertical coordinate specifier of the origin of the enclosing box, both in dots and relative to the upper left corner of the page. They may be different from the preceding pair of coordinates. %{width} is the width specifier, %{height} is the height specifier of the enclosing box. The latter dimension is naturally counted from bottom to top. There is no notion of depth for such a box. To synchronize by content, %{before} is the word before, %{offset} is the offset specifier, %{middle} is the middle word, and %{after} is the word after.
Since this bug is closed, I created a new bug for these requests, Bug 647146.