LaTeXTools
LaTeXTools copied to clipboard
Support Xreader, refresh support for Evince
I use Mint which by default ships with Xreader (and a symlink evince
-> xreader
), so I was looking to add Xreader support for #1366 . Xreader seems to be just a fork of Evince, so most of the previous script works, but not completely. So I ended up rewriting it completely to support both, also because it was quite old.
- Now there is a unique python script
dbus_viewers/sync
which can open a document, check if the document is open, do forward search, or wait for sync source signals and call back ST, or any combination of the previous. It does everything via DBus, like the previousevince_forward_sync
andevince_backward_search
did, with some tweaks:- it uses synchronous calls which are easier to handle
- it's a unique codebase for forward and backward, Xreader and Evince, might be used also to support to other editors that support Dbus
- it does not use
GetWindowList
, because it seems that is not implemented inXreader
, but that is unnecessary becauseFindDocument
will anyways give us the opened document, and from there we can get the main window (which is in both cases at index 0) - it does not need a bash script as an entry point, it will open the document via DBus
- it's python3
- I could not find any way better way to bring the viewer window forward, so I implemented
bring_evince_forward
in the same way as before, that is, calling Evince and hoping that it will not create duplicate windows. Maybe other alternatives likewmctrl
can be considered too. I extended the support toXReader
, so now the setting is calledbring_forward
(but for evince, it will fallback tobring_evince_forward
) - It spawns one monitor process (the
sync
script) per PDF file which stays alive and calls back sublime text when the synchronization is requested. If the user closes the viewer and the reopens it, the monitor process reattaches and is able to synchronize. - Evince and Xreader share the same base,
BaseDBusViewer
, which inherits fromBaseViewer
and gives them the same behavior, except for the different DBus name and command. In the case of Mint, if Xreader is used in lieu of Evince, theEvinceViewer
will adjust the DBus name for running correctly.
I tested this on Mint 20.2, with ST4 build 4126, Evince 3.36.10, XReader 3.0.2. I use Cinnamon as desktop. I tested all combinations of usage parameters for the script (with and without fwd sync, with and without bwd sync, with and without opening the document, with both editors), jump/build/view pdf with both editors, and backward sync from both editors.
I'm looking for feedback especially on the following:
- Is is reasonable to replace the current Evince support? It might need a bit more testing than n=1.
- Is it ok to transition
bring_evince_forward
tobring_forward
in this way? - Which minimum python version should be supported for the synchronization script? I run python 3.8.10 on my machine, and that is what I coded the script for, but I'm somehow expecting that I will have to go down at least one minor (3.7 seems to be still receiving security support)
- I'm looking for at least some test on some other platform also for Xreader if possible?
Let me know what you think :)