GNOME Bugzilla – Bug 304249
Monitor document changes
Last modified: 2018-05-22 13:01:25 UTC
It would be nice if evince will automatically reload document on changes. This can be easily implemented with GnomeVfsMonitor.
I think this was already discussed in another bug...
Could be dupe of bug 171582
No problem. *** This bug has been marked as a duplicate of 171582 ***
Actually this is about the reload vs. monitor see bug 165119
*** This bug has been marked as a duplicate of 165119 ***
Well, Bryan there was the following arguments against monitoring and reload: 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. First of all, will anyhow will get such user request, like this one: http://mail.gnome.org/archives/evince-list/2005-May/msg00040.html and in general, since there will be movement to spatial anyhow http://bugzilla.gnome.org/show_bug.cgi?id=168285 and http://live.gnome.org/ThreePointZero the automatic reload without notification will be extremely needed.
Created attachment 46494 [details] [review] Patch so it won't get lost
There is problem with file monitoring that it related to number of bugs in gnome. Look at 1. Thumbnailing while copying file 2. EggRecent still crashes What is going on there - 1. One application monitor file changes 2. Second starts to modify file, but this modification is not atomic. 3. First get "file changed" signal, while second only starts to write file. Thus first reads unfinished file, process uncomplete data and we see crash. Currently EggRecent just uses timeout 200 ms to let second program update file. of course, this hack doesn't work in all cases. Probably if we'll start to use gtkbookmars file, we'll get the same problem. I think that there should be some API for locks of file, that would prevent like gnome_vfs_monitor_block (char *uri) gnome_vfs_unblock (char *uri) but this solution isn't optimal, I think. Note here, that we can't modify all programs, for example file could be overwritten by some external non-gnome application. In general this leads to change of design pattern - "Don't use file monitoring at all. Create daemon instead, since it allows more gentle change monitoring" Any other ideas?
Hi Nickolay, I'm a little confused on your responses in comment 6 but I'll respond here. The requests for file monitoring don't mean that we have to honor that. We'll probably get requests that Evince be able to read email eventually and we should say no to that as well. ;) From talking to people doing pdflatex work I've found that they don't actually need file monitoring. It can actually be the wrong thing for them sometimes. If they are working on a document and have changed it from underneath the view, they know they have changed it and can then use Ctrl-R to reload the document. Also, often times they want to compare the old document to the new changes, so they'd like to have two copies of the document open at the same time. With automatic refresh you wouldn't be able to do this. Now you could make the argument that we do some kind of option per window that would allow people to set auto-refresh or manual-refresh and that would solve that problem. All of this is extra complication that doesn't actually help this situation our users are having. Plus, and worst of all is that we're putting in settings/options that our target user may have to deal with. i.e. If we had an option to turn auto-refresh on/off we'd need some fairly easy way for people to find it and then we'd be exposing those options to our target users. Plus Evince has no options right now and we don't want any, it's part of our design. Good defaults and comprises, no settings. :-)
Well, I agree. What about addition of gconf key, hidded from UI to enable this functionality?
When evince would offer instant reload on a document change, that would obsolete the "Print Preview" function in many GNOME applications. Simply print to PDF, open it in evince, and watch your changes happen when you "print" again. So I guess I'm requesting this feature to be reconsidered. :-)
FWIW That's not necessarily the only way to implement it. The application could notify evince that it needs to reload.
I use evince to preview my pdflatex docs and yes, the "watch file" functionality is exactly why I still have gv on my box. If evince had a "watch file" check box that would solve my problems. Re Bryan Clarke argument that sometimes people want to compare old versions against new ones: yes, that is what the unchecked "watch file" option would achieve. Obviously evince only should show valid documents, ie gv sometimes gets its wrong while latex is still writing out the pdf file and complains about an invalid document.
I am in the same boat as Sebastian. I too use GGV (2.8.1 because laters versions broke the "Watch File" feature) to view my documents created by PDFLaTeX and MetaPost. It works well. I would love to see Evince incorporate this feature. I just don't understand it being a feature that could be turned on and off. A comment was made above that "under someone without their knowledge" is a bad idea. If you give the user the option of using the feature, then it's not without their knowledge. I think that manual reload is important, but for my use, I would like to see an automatic reload feature as well.
Nope, sorry we don't allow anymore hidden gconf keys and we can't add anything else to the menus of Evince without taking a menu item out. And we don't have (nor will have) preferences or settings. No features are free, please read or re-read these links: http://ometer.com/free-software-ui.html http://ometer.com/features.html There is a way to do this via a D-BUS from the app that you edit your LaTeX files, I'd look into having that app make a call to refresh Evince. think this method is perfectly inline with the vision of Evince, adding extra gconf or checkboxes is not.
I really appreciate the open mindedness here. This seems like a *great* (stated sarcastically) way to accomidate the users. Thanks again!!!
Requiring other applications tell Evince to reload sounds like the horse behind the carriage to me. A lot of tried and tested tools were created before D-BUS existed, and they're not going away any time soon. Implementation issues aside, it is quite obvious to me that a window that offers a view on some object, should dynamically update once the state of the object changes. Not doing so is equivalent to not telling the user the truth. (And please, let's not get too emotional over this. Remember, it's just software.)
Reinout, I agree with you that I shouldn't get so emotional about this. The problem that I'm running into is that GGV broke their "autoreload" feature around versino 2.8.3 (or so), and I've been having to use 2.8.1 since then. When asking about them fixing it in #gnome on GimpNet, they told me that GGV was obsolete and that Evince should be used. Then I find out that Evince doesn't have this feature, and (essentially) the developer(s) think the feature is not needed. I agree with you that if the document changes and an old version is still being displayed, then the software is essentially lying to you about the view. Anyway, something tells me that we're not going to convince them. They're gonna have to convince themselves.
Troy, Reinout: I understand the desire for this feature and I have not said that I'm completely opposed to having it. I've offered a solution that doesn't suite you or this tried and true software ;-) Now it's up to you to figure out a way to do it. I've stated how I won't allow this feature to happen and tried to give a suggestion to how it could happen. This is not the definition of closed minded, but guided. Basically, if you want the feature you need to figure out how it works such that it doesn't have the problems I stated. It's not like I'm blocking on this idea completely, but we need to figure out the best way to do it within the guides. And total aside to this monitor, this is _not_ equivalent to lying to people. If we were interested in telling the complete truth to users we wouldn't give them a graphical interface, we'd let them change the ones and zero's on the CPU, because that's the truth of how things really happen. ;-) Part of application design is to hide the nasty guts of what's happening on the lower levels.
Bryan, I appologize for the hasty words. I was just really feeling frustrated from GGV and took out my frustration on you. I would *LOVE* to help determine the best way to implement this feature. I (being somewhat of a programmer myself on the side) appreciate the *best* way to perform a task. I have some ideas, but perhaps we should discuss it in #evince on GimpNet. I'm in there as "tlhiv". Feel free to message me at any time. If I'm active (that is, at my computer), I'll be more than happy to respond. FYI, in GGV the feature appears under "Edit->Preference" (which seems to be the natural place to put it). Let it be an optional preference for which there may be other optional ones. Anyway, I'll keep thinking about a suitable solution for you and us.
Bryan, would you mind providing a command line version of using DBUS to force Evince to reload? Do you use dbus-send? If so, how might I accomplish this? Thanks!
Created attachment 49587 [details] [review] A patch that adds ReloadURI dbus method This patch adds a ReloadURI method, allowing other apps to reload a document by using the evince dbus interface
Created attachment 49588 [details] Command line tool for testing the previous patch I also attach a command line tool for testing the patch
Carlos, Thanks for the patches and the command line tool. I'm having trouble with both. Could you recommend a solution. First of all, do you know if there's an ebuild available for Gentoo to emerge the latest CVS (could be done daily or even multiple times per day) of Evince? Second, I'm having trouble building your `reload` command line tool. I followed the directions in the .c file, but it's complaining about not having dbus/dbus-glib-bindings.h. I can't seem to find that file even in FreeDesktop's CVS. I did notice that the patch has already made its way into the CVS, so you can see why I'd like an ebuild for the CVS.
which dbus version are you using? I think dbus/dbus-glib-bindings.h is a generated file, so it isn't in CVS.
dbus-0.23-r3 (Gentoo). I guess I don't need the CVS ebuild of Evince since evince-0.32 seems to have your patch built into it. I just need to use it now (by getting your "reload" command compiled and working).
Carlos, I upgrades to dbus-0.34 and was able to build your program. However, when I do something like ./reload thesis.pdf I get the message ** (process:18211): WARNING **: D-BUS error org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.evince.ApplicationService was not provided by any .service files I have placed ev-application-service.xml in /usr/share/dbus-1.0/services and restarted dbus, but that doesn't seem to work. Any ideas?
You need to open evince with thesis.pdf before launching the reload command.
Carlos, I did this. I did evince thesis.pdf & ./reload thesis.pdf and that's when I get that error!
Are you sure you have compiled evince with dbus? The problem is that reload doesn't found the evince dbus service. When you run evince, it should display on console something like: ** (evince:6066): WARNING **: Starting evince process.
Carlos, perhaps that's the problem. I'm using Gentoo's `emerge` to build evince. I didn't see any USE flag that would enable/disable dbus in evince. I'll keep looking into that.
Ctrl-R doesn't work so well for ps files (generated with latex/dvips). For pdf files (generated with pdflatex) it seems to works, but reloading always brings you to the top of the current page which is very annoying if you are working on something at the bottom of the page. It changes the context for the author which is very undesirable, especially when working on formulas. It seems safe to say that most people in academia want the automatic reload feature. It worked pretty well in gv.
*** Bug 315569 has been marked as a duplicate of this bug. ***
Sometimes I wish that Joel Spolsky hadn't written that book, which all these opinions on "no options" finally link back to no matter where you find them. It must be the most misunderstood document ever. Joel is saying that stupid options are bad, not that all options are. Actually, he says the exact opposite if you read it all. He also says that users shouldn't be presented with choices they aren't interested in, but that on the other hand users should be able to make choices they are interested in. All too many projects extrapolate those arguments to mean that options are bad, which is absolute bullcrap. Relevant options are excellent! What is also often forgotten is that in the same book, chapter one, he talks about tiny frustrations that add up. And this is an excellent example of this, where a small feature could save lots of unnecessary small frustrations. If you are going to adopt Joels philosophies, IMO you should adopt it all, because it's all connected. Anyway, to the case at hand: I think autoreload would be a very worthwhile feature, and it should not need to be an option or anything, actually it probably shouldn't be an option because it's not the normal case for every document. What is needed is a way to set an open document in auto-reload mode, probably best done via a checkbox entry in a menu such as File->Autoreload. Unobtrusive, out of the way, everybody is happy and can get their job done. One tiny frustration gone.
*** Bug 322333 has been marked as a duplicate of this bug. ***
Kristoffer, Thanks for the insight. We'll see if it ever happens in Evince. Of course I would love to see it, but I'm not holding my breath. The developers seem pretty adamant regarding this feature.
Personnaly I have nothing against this change. But the most important problem that is rised here is the problem with update from partially-written document. Current backends will most probably crash on partial document. We need to catch signal that document is fully updated, not document is changed. And I don't know how we can get it. Any suggestions will be appreciated.
I would also love to have this feature, it would be great to se changes in documents generated by latex or printed to a file! but two problems appear in this discussion: - it should wait for the document changes to be finished - sometimes the user does _NOT_ want evince to reload the file an added checkbox "monitor file" does solve the second problem but adds some often un-needed UI and does not solve the second one. perhaps evince could just detect file changes without reloading automatically, and inform the user that the file has changed and could be reloaded. Lots of applications behave this way and I like the idea but not the UI: a dialog is often used, I think an additional button somewhere would be better: nicer, less "in your way". a bar like the search bar perhaps: [ the doc has changed, reload it ? [never for this doc] [ignore] [reload now] ] what do you think about it ? I don't feel it is a perfect solution, but it would be much better than what we have now :)
Can anyone with the privilege please reopen the bug? I have followed bug 165119, which has no attempt to "monitor" changes. Hence, this bug is NOT a duplicate of that. For those of us who use LaTeX to edit our documents and preview them in PS/PDF format, we really need auto reload, whether it is determined by Evince (preferred but clutters the UI) or triggered through dbus (a bit troublesome but still acceptable in some sense). Of course, we respect that most people not needing this, hence we proposed a checkbox, but not changing the default behavior.
Agreed. The fix for bug 165119 still leaves issues open from this bug.
(In reply to comment #37) > But the most important problem > that is rised here is the problem with update from partially-written document. > Current backends will most probably crash on partial document. We need to catch > signal that document is fully updated, not document is changed. And I don't know > how we can get it. ggv also occassionally crashes upon auto reload, probably because on this. I think we can accept this potential problem by well documenting it.
*** Bug 330400 has been marked as a duplicate of this bug. ***
*** Bug 339816 has been marked as a duplicate of this bug. ***
What about a reload on getting focus, if the file-time is later than the actual time (stored on the last reload)? I often write documents in emacs, compile in emacs and then press alt-tab to switch to the viewer. This works perfectly with xdvi and gv. Sure you have to wait 'till compilation has finished - but you can decide when to reload without pressing a dialog button. Btw. when changed a pdf file on disk, without refreshing it in evince I get blank pages when scrolling some pages up or down - You have to reload the document to correct it.
Epiphany auto-reloads files that have changed on disc. The reload is delayed a bit thought (exponential backoff) so that the file is not read while it's being written too. The code is in epiphany/src/ephy-tab.c.
(ignore the typos in my previous comment please, thought->though, too->to... ;)) FYI: the url is http://cvs.gnome.org/viewcvs/epiphany/src/ephy-tab.c?view=markup
Just my 0.2€, IIRC emacs asks the user (File has changed on disk, reload y/n) Couldn't evince do this? If you don't want to change the view, you just answer No, if you do then evince stores what page you where on and reloads the file and jumps to that page.
hmm, IMHO a popup could be really annoying.
That would be really annoying. Editors NEED to ask because they act with files in a read/write way. Viewers only read files so there's no risk of data loss (as would be in editors)
*** Bug 343333 has been marked as a duplicate of this bug. ***
https://launchpad.net/distros/ubuntu/+source/evince/+bug/57931/comments/3 has a description on how the current reload behaviour is buggy with .dvi files. If you want me to file this as a separate bug, I'm happy to do so.
Daniel, we have no automatic reloading yet. Can you please check ubuntu package sources if they add some patches?
> Daniel, we have no automatic reloading yet. Can you please check ubuntu package sources if they add some patches? Oh, it's mine mistake, sorry, forget about it
I would also like to use evince to preview documents that I compile with pdflatex. I know that refreshing the view is as simple as "Ctrl+R", but depending on the editor this might be in addition to several other keystrokes. Evince should know what to do in this case and do it. I currently use kile as my editor, but I am switching to gedit as the new LaTeX plugin improves. These editors (and others) feature a "build" command that executes (pdf)latex and associated programs a number of times, and then invokes the appropriate viewer. Since this is how people usually build their documents, it seems like we could get away with just telling evince that, when told to open a document that is already open in another evince window, to just refresh the existing display. That way you don't have the problem of refreshing on a document that isn't finished compiling; the viewer isn't invoked until pdflatex (or whatever) has finished its job. So, instead of "auto-refresh", it seems like most LaTeXers would be happy if invoking "evince foo.pdf" at the end of their build checked to see if foo.pdf is already being displayed by evince, and refreshed that view if it is.
I'm another LaTeX who would be happy if invoking "evince foo.pdf" at the command line could refresh the view of foo.pdf. I would add this to my LaTeX build script, giving me most of the benefits of auto-refresh in evince itself.
I guess comment 45 provided a good framework on how reload should happen. After evince detected an opened file has changed, it should "attempt" to reload it (in the background). If this fails, it should continue to try, with expotential backoff. No error message should be shown when these reloads fail, until the user pageup/down to a page where evince must query the document on disk again. This makes sense since a document is already displayed, and it should still be kept there until something updated is available, or we can no longer display it properly. When the updated file is has been reloaded in the background, either update in the front-end or show a popup to confirm before doing so. Best if this behavior is configurable. Personally I prefer no pop-up because: 1. this is the old behavior of ggv 2. evince re-positions the previous location of the document before refreshes, so probably it cannot be too disastrous to the viewer 3. the very likely reason for the file to be updated is the user editing the file, hence hopes to see the new version now
Since now you after evince $uri document will be reloaded, so it's probably have sense to insert such command in latex build script. Of course, it won't solve all problems but at least makes work easier
(In reply to comment #57) > Since now you after > > evince $uri > > document will be reloaded, so it's probably have sense to insert such command > in latex build script. Of course, it won't solve all problems but at least > makes work easier > Nickolay, Which version of evince is this implemented in?
It's in HEAD, will be in 0.6.1
Tried in Ubuntu Edgy that it works, although the window list entry flashes after the command is executed. Now at least we have a workaround for evince not able to "monitor document changes". Still, from the amount of duplicates this bug got, not few people do expect evince to monitor file changes like ggv does.
The window flashing is intentional. It is called "urgency hint" and means "hey look I got something for you, look at me, I want attention".
I understand what a "urgent hint" is, but I don't think my intentional telling evince to refresh warrant any "urgency" to me. Perhaps this is the mentality difference between a refresh-by-monitoring and refresh-as-told. I guess I feel less annoyed if I know that evince want my attention because it detected a change in the document.
*** Bug 399511 has been marked as a duplicate of this bug. ***
Looks like no one listened to comment 62. There are 2 problems with this "fix" to reloading evince by a script which loads the document again. 1. If evince is running in another workspace, it will be "moved" into the workspace that my script (that tries to refresh it) is executed. This defeats the purpose that I use one workspace to edit a document and another one to preview it. Perhaps this should be filed as a separate bug. 2. If evince is running in another monitor or another location inside a big monitor, I do not want the flashing window title, since the evince window is fully within my sight, and I can view and even scroll without focusing it. I need an option to tell it not to set the urgent hint in the wm.
*** Bug 446044 has been marked as a duplicate of this bug. ***
*** Bug 449468 has been marked as a duplicate of this bug. ***
Yikes, didn't pay much attention to this bug lately. I don't think the goal here is to derail this feature, I agree with comment 37 that I'm not against this feature. However the initial guidelines were that we couldn't add settings or preferences, especially hidden ones! Of course this isn't trying to ignore the need for settings like comment 34 seems to suggest that we're idiots who've gotten the design all wrong. The suggestions I was trying to get around before was a per file setting that was approached from the file properties dialog or some other hidden (by hidden I mean a level deeper than the current window) window. And the command line only feature might as well be a hidden gconf key, I like the command line feature because I think it solves several situations people I talked to about Latex work had, however I was thinking of a different type of solution. I made some mockups recently to push towards something I thought might be another way to approach this problem. I've stolen some excellent work done from the GEdit folks, perhaps we can steal their code as well if this looks like a good idea to others. (attachments to follow)
Created attachment 95077 [details] evince asking to reload the current document Here I've used the GEdit / Firefox type insert to show that Evince has a problem with the current document. The options we give are Reload, Cancel, and an [x] Always Reload this File. I'm not sure how Cancel will work, nsh or someone should probably talk about what happens when you don't actually reload the file and try to continue. If there is a real problem here perhaps we should be using some kind of a temp file solution (doesn't have to be a temp file, read into what problem it would solve not what it could create) or not offering to cancel the reload. The Reload button would reload the file within Evince, this is fairly straight forward. If the person checks the [x] Always auto-reload this file the file will be reloaded every time it changes without asking. It might be a good idea to check the auto-reload by default, it seems like that would be a reasonable default for what people are doing here. After clicking either the Reload or Cancel button the information area goes away and the respective action is performed. This information area is probably best if it doesn't actually move the document, but instead covers over the top area.
Created attachment 95078 [details] evince after auto-reloading the current document Once we've created the option for auto-reloading, we need some kind of obvious feedback for the user that it's working and a way for them to turn it off. Using the same info area I think we can offer a small an unobtrusive information area that shows an auto-reload took place, while also offering a way to turn off the auto-reload of a document. Unchecking the checkbox would cause the earlier reload information area question to appear the next time evince wants to auto-reload the document. SIDE NOTE: This interaction does give rise to questioning checking the auto-reload by default. i.e. if you wanted to stop the auto-reload you would uncheck at this window and then be prompted for reload each time there after. If there exists a significant case of people wanting to manually cause the reload they would have to keep unchecking the box at the reload / cancel dialog. This info window probably needs a close button or perhaps clicking anywhere on it closes it. However it should also probably disappear on it's own after a short timeout such that it doesn't keep around very long, negating the feedback effect it could have for telling the user a reload just happened.
*** Bug 500348 has been marked as a duplicate of this bug. ***
*** Bug 505514 has been marked as a duplicate of this bug. ***
I would like to say (as yet another [pdf]latex) user) that I won't be happy with less than what xdvi does, which is basically what is described in comment #56. In particular, I do not want to have to issue a separate command to trigger the reload; it needs to be automatic upon the document changing. Furthermore, there should be no popups, and (for my workflow) if we must have a mode in which the document is not reloaded when it changes on disk, that mode should not be the default. If I wanted to preserve the old contents of a file I would copy it to another name.
kpdf provides this feature as a default, can be turned off in settings. Looking for problems with this, I could only find one bug report: http://bugs.kde.org/show_bug.cgi?id=139629 Which states that in case of compiling a very large pdf files you may have to wait a long time seeing only a white update screen until you get the updated document displayed. This means that kpdf tries to reload a document right at the moment it finds the document changed. A better behavior for evince would probably be to wait until the file was completely written before attempting to reload it. I'm using pdflatex quite frequently so monitoring a file like kpdf does is really a big gain of comfort for me. Evince should provide it by default too. My suggestion is to have a check box "Monitor file" in the File drop down menu, that is checked by default or an "automatically reload" checkbox right over the reload button in the view drop down menu.
Now that we have the gedit message error bar, we might (ab)use it to notify the user in case the document changes. The message bar should provide a Reload button, so people can easily reload the document.
(In reply to comment #73) > A better behavior for evince would > probably be to wait until the file was completely written before attempting to > reload it. The problem is, how do you know that the document has been completely written? There are a lot of PDF and PS documents that don't have the EOF mark at the end of the document.
(In reply to comment #75) > The problem is, how do you know that the document has been completely written? > There are a lot of PDF and PS documents that don't have the EOF mark at the end > of the document. 1. I thought the EOF is mandatory by the PDF specification? 2. We might use exponentional backoff. Epiphany has this as well for the auto-reload local .html file stuff.
(In reply to comment #75) > > The problem is, how do you know that the document has been completely written? > There are a lot of PDF and PS documents that don't have the EOF mark at the end > of the document. > How about just checking file size and if it does not change for some time, consider document to be completely written?
Inotify tells you when an application opened the file, when it changed size, and when the application closed the file. Should be pretty straight forward.
(In reply to comment #78) > Inotify tells you when an application opened the file, when it changed size, > and when the application closed the file. Should be pretty straight forward. pdfLaTeX processes a file multiple times, so a single close event doesn't indicate whether the file has been fully updated.
(In reply to comment #77) > How about just checking file size and if it does not change for some time, > consider document to be completely written? That's what the exponential backoff I mentioned in comment #76 does in a smart way.
Just want to mention the macos x viewer named Skim. http://skim-app.sourceforge.net/ When the "Check for changes"-setting is activated and an opened document changes, Skim asks the user via a popup menue, if he/she wants to keep the old document, load the new one or autoreload on coming changes. Because of the no-settings design philosophie in evince, it would be best to have only that popup without having to activate a "Check for changes"-setting first. I think some others have suggested this before, I just wanted to point out a pdf viewer that actually implements this suggestion. Technically it's surely not hard to use gnomevfs/gvfs (or inotify directly) to monitor changes. If you receive a MODIFIED, wait a certain amount of time and for further MODIFIED events (pdflatex processes a pdf file many times). Some time after the last MODIFIED event, try to render the new pdf file and when done, show it. This avoids the annoying waiting while showing a white page that kpdf users have to live with.
I originally suggested that when evince is invoked with a file that is already being displayed, it should reload the file. This is perfect for editors that invoke pdflatex via a script or build system, as they always invoke the viewer at the end of the script. So why is this still an issue? I use this feature all the time and nothing goes wrong with other evince windows on other desktops (as claimed in comment #64). I can't comment on the multi-monitor issue. Adding a pop-up is obtrusive and does more to interrupt the work flow than manually auto-refreshing via Ctrl+R. Adding a one time prompt (maybe one time per document) about whether auto-refresh should be turned on is okay, I guess. But what's wrong with the default behavior? It doesn't ask any questions, it happens in the background, and you don't have to worry about whether or not a file has finished compiling (the script or build system does this).
(In reply to comment #82) > But what's wrong with the default behavior? My workflow does not involve a script. (I use C-c C-f in Emacs, which just runs [pdf]latex.) I want evince to notice the file change without any external intervention. xdvi does this, and until evince does it too, I will continue to use xdvi, despite the many infelicities (e.g. I still have to have both PDF and EPS versions of all included graphics); that's how important this is to me.
Ah...good point about Emacs. While we're waiting for a solution that works for everyone, isn't it possible to append an "evince $uri" to the command that emacs executes? I agree that this sort of thing should just happen, and happen the right way, without everyone having to write scripts and tweak things.
I'd *like* to do something like that as a stopgap but it doesn't appear to be easy; the configurable in Emacs is the name of the command, not the full command line. I would have to write an entire wrapper script, which is nontrivial.
(In reply to comment #83) > My workflow does not involve a script. (I use C-c C-f in Emacs, which just runs > [pdf]latex.) I want evince to notice the file change without any external > intervention. Not using a script doesn't work for any non-trivial document (triple negation, yay!). For instance, documents that use a bibliography or an index need a script anyway. I'm not really convinced the "pdflatex document.tex" case is the typical workflow evince is aiming to support.
(In reply to comment #86) > Not using a script doesn't work for any non-trivial document (triple negation, > yay!). Sure it does. For instance Emacs' tex-mode has C-c TAB to run bibtex. It doesn't appear to have a keystroke to run makeindex out of the box, but I could easily create one if I ever needed it (much more easily than writing a wrapper script smart enough to run all these things itself). > I'm not really convinced the "pdflatex document.tex" case is the > typical workflow evince is aiming to support. The comment history suggests that, while not the number-one use case, it is significant enough to be worth supporting.
*** Bug 532948 has been marked as a duplicate of this bug. ***
(In reply to comment #86) > I'm not really convinced the "pdflatex document.tex" case is the > typical workflow evince is aiming to support. > Then, what Gnome application supports us? PDF producing user may not be too many, but we are heavy users and that should count for something. I guess I use Evince more in a week than my mum will in her life time. I am currently using the script method, and it works kind of, but not for my work flow. Evince keeps jumping to the current workspace. So that is a problem contrary to what Comment #82 says, he is probably not using Gnomes default WM. Comment #37 raises a valid issue obviously, but what about a flag like this evince --reload uri and then evince would reload the documant given in the window already containing it, but without grabbing wm focus. I would be content with such a soulution, at least as a temporarily one. This bug is now 3 years old, so even a temporarily solution wolud be welcomed by me.
(In reply to comment #37) > Personnaly I have nothing against this change. But the most important problem > that is rised here is the problem with update from partially-written document. > Current backends will most probably crash on partial document. We need to catch > signal that document is fully updated, not document is changed. And I don't know > how we can get it. > > Any suggestions will be appreciated. You can do that using inotify (and gvfs). You'd be using g_file_monitor_file(), and checking for G_FILE_MONITOR_EVENT_CHANGED (you'll probably get a few of those), usually followed by a G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT. So the code would probably be something like: - we've changed! add an timeout for in a few seconds, to reload the file - we've changed again! remove the previous timeout, and setup a new one - receive _CHANGES_DONE_HINT, or timeout after a certain period of time (~5 seconds? would need testing to see what the sweet value is) we should be done, reload Also, any crashes caused by incomplete documents should probably be filed as bugs, and evince have a better way to dump incomplete documents to a file whilst crashing, for debugging purposes.
Created attachment 112533 [details] [review] New patch This patch does exactly what Bastien proposes. Please try it out and let me know whether it works. If it works fine I'll commit it, but we also need to agree on how to notify the user about it. I like what Bryan proposed on comments #68 and #69, what do you guys think?
(In reply to comment #91) > I like what Bryan proposed on comments #68 and #69, what do you guys think? I haven't tested your patch yet but that UI looks sane to me.
(In reply to comment #91) > This patch does exactly what Bastien proposes. Please try it out and let me > know whether it works. Thanks!! It work great so far (tested with a few hundred compilations of a 10 page LaTeX document, while switching between workspaces and windows and doing other stuff). The Evince window doesn't grab WM(Metacity) focus and it doesn't move to other workspaces, which is great. I only have one minor issue with the current behavior, the window is moved to the front when reloading conten. That might not be optimal.. When it comes to UI i do not really have any preferences as long as it works. I think it should be turned on by default, and beeing able to disable it in gconf would be sufficient to me. Can't see any use cases where autoreloading would be not desirable, given it doesn't increase chances for crashing.
The patch doesn't seem to work when the file creation process takes a while. [~]$ time ps2pdf file.ps file.pdf real 0m50.989s user 0m37.378s sys 0m0.623s This results in a error message in Evince: Unable to open document PDF document is damaged
For the reason in comment #94 I suggest to make a test for the patch before applying it.
Seems like 5 seconds isn't quite enough. Carlos, would you mind adding timing output in ev_file_monitor_changed_cb()?
Created attachment 112604 [details] [review] Updated patch Ok, I have a new patch. Please try again, it should work now.
(In reply to comment #97) > Created an attachment (id=112604) [edit] > Updated patch > > Ok, I have a new patch. Please try again, it should work now. > This doesn't work either, same error. Not, sure why the timeout has to be there at all? I just increased the value significantly (in the the first version ot the patch) and then it worked flawlessly for both small and large files. Anyway, guess it is a good reason behind it. Here is a large PS to reproduce the error with, if you would like to do that, so you do not have to go trough the hassle of creating one yourselves. The PS contains the the same page twice to make it huger, just in case your computers are way faster than mine. The file was to large to attach on bugzilla, so here is a link(53MB): http://nedrebo.org/dump/huge_20080612.ps
Forgot to say how to reproduce (kind of obvious, but for completeness ...) ps2pdf huge_20080612.ps evince huge_20080612.pdf & ps2pdf huge_20080612.ps # Watch Evince complain
It works for me. . .
(In reply to comment #100) > It works for me. . . > Me to ... :/ Sorry! I applyed the old patch when rebuilding Evince. The new patch seems to work great!! Nicely done!
I've just finally committed the patch, so that it will be tested by more people. I'm leaving the bug open since we still have to implement the user notification stuff (based on Bryan mockups)
Came here as I had an academic note that they were still using a DVI-based workflow as Evince couldn't/wouldn't do the auto-reloading for them. I found a FAQ that states that auto-reloading does work: http://live.gnome.org/Evince/FrequentlyAskedQuestions A: Evince automatically reloads the document when it has changed on disk Regarding comment #37, or how to monitor a file. If a current reloading detection method works, I don't see a need to re-invent it. Troy@14 notes that ggv 2.8.1 works, but that ggv 2.8.2 onwards didn't. Gnome GV v2.8.1 is doing a check: #define GGV_WATCH_TIMEOUT 2 if((info.mtime != win->mtime) && (time(NULL) - info.mtime >= GGV_WATCH_TIMEOUT) && (NULL != win->control)) { Gnome GV versions 2.8.2 upwards (that weren't apparently working) are doing: res = gnome_vfs_monitor_add(&(win->monitor), win->filename, \ GNOME_VFS_MONITOR_FILE, monitor_callback, win))) ... /* perform a short sleep, just in case if the file "just started to be * changed"; naturally, this method is not 100% accurate, but suffices * for most of the cases... */ usleep(250000); So it's possible that vfs_monitor, followed by mtime-comparison, followed by a short delay would be better. I think the only true better method is finding a way to count the number of open file-handles on a file, and watch for a rise (open), followed by a fall (closure). However, as noted before, sticking with a known working solution is better than nothing. To paraphrase; "you have to join them before you can beat them!".
I didn't exactly got what happened here. I liked evince NOT reloading my files automatically. It was like that until some weeks ago in my system. I think it changed when I updated from Ubuntu 8.04 to Ubuntu 8.10. Now, everytime I change a pdf file, evince automatically reloads it, goes to foreground and, while trying to load a partially finished file, it displays a lot of errors. This happens because in Latex one is used to compile the document twice (pdflatex doc.tex; pdflatex doc.tex) in order that references get correctly numbered. Therefore, when it finishes the first time, evince starts to reload the file, which is being already modified by the second compilation (that's why it shows a lot of error messages, I guess, but finally it ends with the last file oppened). Anyway, I don't want this to happen: I many times compile the latex document only to check if my latex code is OK. So, I don't need evince to reload the pdf automatically and, more importantly, I don't want it to come to foreground. As I said, this started to happen last week, upon Ubuntu update. Can I switch off this behaviour? I was fine with Control-R! Thanks, Leandro.
Just to add something. In the case were one does has an error on the latex code, the pdf file generated will be incomplete and, then, evince will finally open a broken pdf file (and go to foreground...). Of course, this is highly undesirable. Therefore, if automatic reloading is important for many people, it should be an option to deactive it. Is it possible? Thanks, Leandro.
(In reply to comment #104) > I didn't exactly got what happened here. See comment 102. There are plans to ask the user whether to auto-reload, but this has not yet been implemented. I personally like the auto-reload, but I agree that it's rough to break some use cases by committing an unfinished change; a similar thing happened to me in Evolution 2.24 when disk-summary broke threaded vfolders. (In reply to comment #105) > Just to add something. In the case were one does has an error on the latex > code, the pdf file generated will be incomplete and, then, evince will finally > open a broken pdf file (and go to foreground...). > Of course, this is highly undesirable. Here I have to disagree. If I am correct in believing that evince reads the pdf file lazily, then you lose even without the auto-reload because evince will read corrupted data when you scroll. IMO, it's your job to use a build system that avoids corrupting the file you're viewing, e.g., by writing a temporary file and moving it over the original on success. (I don't think pdflatex currently supports that, but I might make a modified version that does.) And then it's evince's job to auto-reload when a file is moved over the one it's viewing (currently it seems to auto-reload only for in-place rewrites).
Yes, you are correct. Even without the auto-reload the corrupted pdf file cannot be shown by evince. But at least I didn't got a bunch of errors after running pdflatex for a file with an error just for having evince open. I believe this will be a source of instability. I hope that option is implemented soon. By the way, in the current version, the Control-R lost all its meaning, didn't it?
(In reply to comment #107) > By the way, in the current version, the Control-R lost all its meaning, didn't > it? No, it still forces a reload, and currently it is needed if the file is updated by moving a new version over it because evince doesn't detect this.
(In reply to comment #106) > IMO, it's your job to use a build system > that avoids corrupting the file you're viewing, e.g., by writing a temporary > file and moving it over the original on success. (I don't think pdflatex > currently supports that, but I might make a modified version that does.) I wonder, how many application are out there, that overwrite files the way pdflatex does. That behaviour is not OK, i agree with you. But you can't change the world, even if it's wrong. Actually i expected you to test a bit more with typical use-cases (like pdflatex). Anyway: i was thinking about some "logic" to avoid that: I hope, that pdflatex changes the PDF the file frequently. So why not wait with reloading the PDF until no more changes have been made for a certain time? On the other hand: showing error messages after an automatic reload seems annoying. You didn't think that thing through. That should be changed. But there are many more showstoppers: I frequently encountered cases, where evince froze because the PDF was modified and because I forgot do a reload. So reloading is actually a dangerous thing, because it might freeze evince when it reloads a PDF while it's being rewritten. But that might be poppler problem - yet it becomes a evince problem, because evince is based on poppler.
(In reply to comment #109) > So why not wait with > reloading the PDF until no more changes have been made for a certain time? > So reloading is actually a dangerous thing, > because it might freeze evince when it reloads a PDF while it's being > rewritten. evince waits for the gio CHANGES_DONE_HINT event, which is based on the inotify CLOSE_WRITE event indicating that a process has closed the PDF file after writing to it. Since pdflatex opens and closes the PDF only once, that guarantees that evince won't reload the PDF until it is complete. We still have to worry about evince reading data from a partially (or even fully) rewritten PDF file to update the display, before the reload has a chance to occur. Could display updating simply be suppressed after the first change and re-enabled in conjunction with the reload? By the way, it looks like pdflatex has an -output-directory option that build systems could use to replace the PDF file via renaming, once evince knows to auto-reload when that happens. Another technique is to delete the old PDF file before having pdflatex write a new one; that triggers the CLOSE_WRITE that is currently recognized. Either technique keeps evince's fd on the old PDF until the reload, avoiding any trouble from display updating.
(In reply to comment #110) > evince waits for the gio CHANGES_DONE_HINT event, which is based on the inotify > CLOSE_WRITE event indicating that a process has closed the PDF file after > writing to it. Since pdflatex opens and closes the PDF only once, that > guarantees that evince won't reload the PDF until it is complete. Running pdflatex once is not enough it some cases. So people may run pdflatex twice or even 3 times - either manually, or using texi2pdf which detects if pdflatex likes to be re-run and runs pdflatex as often as it wants to. In that case, you'll get a CLOSE_WRITE event, but the next thing you get should be an event, that the file has been reopened, propably while evince is already reloading.
In my oppinion this was a regression. We have several problems now and, additionaly, an anoying behaviour (comming to foreground each time the document is updated), for something that before was simply solved by pressing Crontrol-R. I really don't see the point of this, it looks like a windows-style feature making us loose control of our workspace. The behaviour of pdflatex should not be discussed here, and one should not expect every package to behave as evince would like them to. This "feature" should not have been included before the option of not to enable it was also implemented.
(In reply to comment #93) > It work great so far (tested with a few hundred compilations of a 10 page LaTeX > document, while switching between workspaces and windows and doing other > stuff). The Evince window doesn't grab WM(Metacity) focus and it doesn't move > to other workspaces, which is great. I only have one minor issue with the > current behavior, the window is moved to the front when reloading content. That > might not be optimal.. It's not only "not optimal"... it's highly annoying :) The good news is that I think I figured out why this happens. See bug 571051#c3 for more information.
*** Bug 576855 has been marked as a duplicate of this bug. ***
*** Bug 611231 has been marked as a duplicate of this bug. ***
*** Bug 703281 has been marked as a duplicate of this bug. ***
Created attachment 248097 [details] backtrace from segfault when reloading document
In another bug marked as duplicate of this one, I reported that evince crashes when paging through the document as evince automatically reloads the document (ConTeXt is compiling the PDF). Would it be possible that this nasty bug could be fixed? Many thanks for your help, Pablo
*** Bug 737105 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/7.