GNOME Bugzilla – Bug 165119
wishlist-a reload button
Last modified: 2005-12-18 14:21:40 UTC
A pdf viewer is useless for LaTeX work unless it has a reload button. (La)TeX production work involves repeated cycles of edit compile view either the pdf file must be monitored for updates or the viewer must have a re-load button. good luck, adrian
Good idea. I have seen requests for file monitoring but am not sure that what we want to do. Changing the document from under someone without their knowledge doesn't seem like the best idea. Even if the document changed on the file level doesn't actually mean it changed in a useful way to the person. I think the reload is a fine option, View -> Reload (Ctrl-R) would probably work for you in this situation really well. I don't think the reload belongs on the toolbar; seems pretty obvious it is not a usual user operation. This would make your production operation: edit compile (Ctrl-R) View Sound good?
Perfectly reasonable. The entry should probably be in the File menu, since it's a file operation (change the file we are looking at). That's where ggv puts it. xpdf puts it in the context menu, which also has the "open" command so that's similar. gpdf simply follows the file and updates when it changes. --adrian
Great. Well the GNOME standard is Reload/Refresh in the View menu. Check out the HIG under "generic View menu". http://developer.gnome.org/projects/gup/hig/draft_hig_new/menus-standard.html
Well, wouldn't it be appropriate to monitor for updates and if they occur present a dialog asking whether to reload? Perhaps too "helpful", requiring this to become an option...but if we make it an option we might as well have auto-reload. I'm guessing you don't want a lot of options, but this seems like one that is called for. I, as an author, would greatly appreciate automatic reloads.
I don't think the auto-reload is a good idea for reasons I said in comment 1 Presenting a dialog to ask about reloading would give a person the option, but it's not a question that people really want to answer. Most won't care or don't know the right answer; so they'd rather not have evince ask a question like that. And as you said (the user this action really targets) you would rather it just reload automatically instead of ask. We don't have *any* options for evince right now and I'd like to keep it this way. It seems that only LaTex users need a reload function and I think having Ctrl-R (plus the View->Reload menu item) work for that is the best way to do it for everyone. In the LaTex use case you know exactly when a change was made, so having to manually reload isn't much of a hassle, it's probably just a pain in the very long run of the use. Perhaps once we have per-document settings remembered then we could do something like this on a per-document basis through the page properties window. An interesting idea could be to ask for auto-reload monitoring after 3 or so manual loads and save it as a per-document option, which could be enabled/disabled from the document properties window. But that's blue sky at the moment.
Using "automatic reload" as the only option would occaisionally be a real problem. There are times when I need to compare two versions of the same set of equations so I need an old version and a new version. Allowing a manual reload would let me have two windows open, one with the old version, the other with the various new versions. Ctrl-R is a minor annoyance but since we are batting around issuing commands to the editor, command-line, and viewer, it is not a big deal. Ideally we could have some way of setting the preference such as having an auto-reload state like the view sidebar on/off state. cheers, adrian
Some of the backends (such as the .ps backend, iirc) go to the disk when they read new pages. I think we're going to have to watch the document anyway, as we'll end up in an inconsistent state there.
It's hard to get this right it seems. Bryan is on to something with the per-document thing I think. A perfect reload would remember the page you were on before the reload took place and load it again (i.e., the page number, not necessarily the same content). As Jonathan points out, some backends will need monitoring either way, as the file may have changed and not reloading it will wind up with the document not being displayed at all. It is unclear to me what solution fits best in this case. OK-dialog for most users I suppose ("Oh no! It seems the document has changed! We will have to reload for continued viewing pleasure.") but I'd find that annoying myself after a while...
Created attachment 37870 [details] [review] Proposed patch This patch adds a "Reload" menu item to the view menu which reloads the document. Using ev_window_open feels hackish, but it also seems to be the most robust way to reload the document. This doesn't implement any kind of file-watching, auto-reloading or anything else. Of course, the reload action should be the same regardless of how it's triggered.
Comment on attachment 37870 [details] [review] Proposed patch + g_object_unref (ev_window->priv->document); + ev_window->priv->document = NULL; I dont think you need this. ev_window_open should deal with it... + uri = g_strdup (ev_window->priv->uri); + ev_window_open (ev_window, uri); + ev_window_open_page (ev_window, page); + + g_free (uri); The dup/free seem unnecessary
An alternative could be to implement a _reload function in the backends. Though I'm not sure there is much to gain... so I think this is ok, at least for now.
Created attachment 37896 [details] [review] Updated patch You're right about the document unref, but the dup/free is needed because ev_window_open does: g_free (ev_window->priv->uri); ev_window->priv->uri = g_strdup (uri);
Comment on attachment 37896 [details] [review] Updated patch Thanks!
Hey all, congratulations on the patch. One question though. Does this restore the focus and zoom on the page as well? If one is working on an equation, one is zoomed in all the way on some detail (like seeing if a subscript looks okay). Ideally, in that situtation, the reload doesn't change the zoom. More critically, it's nice to navigate a doc zoomed in on the text rather than on the whole page. Reloading should not change that. cheers, adrian
These are details that we can sort out later... In general this is a stop gap patch. Once we branched we need to rethink the whole thing and come with a complete solution (see file changes problems etc...) kaiw do you have a cvs account or should we check it in for you?
No, I don't have a CVS account - cheers. As far as zoom maintenance goes, I had hoped that when someone implemented zoom-persistance on a per-file level (bug #168285) this would automatically start working.
Checked in, please open separate bugs about the aspects that needs improving.
*** Bug 304249 has been marked as a duplicate of this bug. ***
*** Bug 312025 has been marked as a duplicate of this bug. ***
I would like to point at that for non-LaTeX use-cases, the file rarely changes underneath, so it may not be as big a problem as depicted in this thread to pop up a dialog and ask whether to reload, and whether to remember this answer (for this document, generally, etc)... In the LaTeX use-case though, it *is* counter-productive to have to do ctrl+R, since that means ctrl+tab, ctrl+R, ctrl+tab, were it could simply show up when you do :mak in your vim :-). My RSS-suffering fingers appreciate not having to do that too much. My 2 cents,
I have a suggestion It is possible to automatically distinguish the latex and non-latex use cases, at least for postscript files. The file I compiled a while back has the comment %DVIPSSource: TeX output 2005.12.18:1945 So evince could simply watch the file for changes, and when a change occurs look at the timestamp and check if it has been compiled from dvi source after the file was previously read. If so, then auto-reload, else let the user manually reload. Cheers