Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Xreader, refresh support for Evince #1557

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

5p4k
Copy link

@5p4k 5p4k commented Mar 16, 2022

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:

  1. Is is reasonable to replace the current Evince support? It might need a bit more testing than n=1.
  2. Is it ok to transition bring_evince_forward to bring_forward in this way?
  3. 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)
  4. I'm looking for at least some test on some other platform also for Xreader if possible?

Let me know what you think :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant