GNOME Bugzilla – Bug 626561
SyncView does not work for a brief amount of time after EvWindow registers in DBUS.
Last modified: 2011-07-14 08:14:26 UTC
Since the ev-window register in DBUS in the init, and the document is only set in the open_uri method, there is a brief amount of time (some miliseconds), where the SyncView method does not work (since the document pointer is null). This causes problems if I want to Spawn an Evince instance using FindDocument(uri, Spawn = True) and then right away get the window list and do a SyncView. So, in practice, the first time I do SyncView, it does not work. I really don't know how to fix this.
Created attachment 168435 [details] [review] Preliminary patch. So I opted for the queue methods calls until the doc has loaded instead of adding a DocumentLoaded signal. Afterall, I think this is better for clients (not overcomplicating the DBUS api). Issues not (yet) addressed: - What happens if a doc is never loaded and you queue some method calls (this should never happen since there is no way of getting the unique name of a Evince instance with an empty window, but, I raise the concern nevertheless). - (this probably belongs to a new bug) With the patch attached, Evince now performs the ForwardSearch as expected, but the EvView widget does not ensure that the result is visible.
the second issue occurs since the syncview and therefore ensure_rectangle_is_visible is called before the View widget has allocated space (and hence the GtkAdjustments values are not correct)
Created attachment 169292 [details] [review] patch as discussed in IRC, the previous patch has problems. We opted for emitting a DocumentLoaded DBus signal when the window finishes loading and subscribing to this signal in the Evince Daemon, so the evince daemon replys to FindDocument calls with spawn=true only after the window has loaded. Preventing the async issues of this bug. The patch attached add this signal. A patch to the daemon follows
Created attachment 169299 [details] [review] patch to the daemon
Review of attachment 169292 [details] [review]: Pushed, thanks!
(In reply to comment #4) > Created an attachment (id=169299) [details] [review] > patch to the daemon I've pushed a slightly different version of this patch. Instead of subscribing to the signal globally, we can do it per document, and since the signal will be emitted only once we can unsubscribe it as soon as we received it.
I dont think this bug is fixed. I'm developing this gVim plugin https://github.com/peder2tm/sved/blob/master/tex_evinceSync.vim And I have discovered that when using the FindDocument method asynchronously with spawn=True, I will first receive the signal DocumentLoaded and then the FindDocument reply. As my plugin is now, it doesn't work correctly, because it is issuing the SyncView method too quickly, when the Evince window need to spawn. It works correctly if the document is already loaded. If I add time.sleep(0.2) after line 149 in the .vim file, it also works when spawning, so it seems like there still is a race condition going on. I'm using Evince 3.0.2 on Arch Linux.
(In reply to comment #7) > I dont think this bug is fixed. I'm developing this gVim plugin > https://github.com/peder2tm/sved/blob/master/tex_evinceSync.vim > > And I have discovered that when using the FindDocument method asynchronously > with spawn=True, I will first receive the signal DocumentLoaded and then the > FindDocument reply. > > As my plugin is now, it doesn't work correctly, because it is issuing the > SyncView method too quickly, when the Evince window need to spawn. It works > correctly if the document is already loaded. > > If I add time.sleep(0.2) after line 149 in the .vim file, it also works when > spawning, so it seems like there still is a race condition going on. > > I'm using Evince 3.0.2 on Arch Linux. OK, the bug I am referring to is really Bug #628375 so just forget comment #7