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 previous evince_forward_sync and evince_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 in Xreader, but that is unnecessary because FindDocument 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 like wmctrl can be considered too. I extended the support to XReader, so now the setting is called bring_forward (but for evince, it will fallback to bring_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 from BaseViewer 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, the EvinceViewer 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 to bring_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?
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.dbus_viewers/syncwhich 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_syncandevince_backward_searchdid, with some tweaks:GetWindowList, because it seems that is not implemented inXreader, but that is unnecessary becauseFindDocumentwill anyways give us the opened document, and from there we can get the main window (which is in both cases at index 0)bring_evince_forwardin the same way as before, that is, calling Evince and hoping that it will not create duplicate windows. Maybe other alternatives likewmctrlcan be considered too. I extended the support toXReader, so now the setting is calledbring_forward(but for evince, it will fallback tobring_evince_forward)syncscript) 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.BaseDBusViewer, which inherits fromBaseViewerand 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, theEvinceViewerwill 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:
bring_evince_forwardtobring_forwardin this way?Let me know what you think :)