After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 304249 - Monitor document changes
Monitor document changes
Status: RESOLVED OBSOLETE
Product: evince
Classification: Core
Component: general
git master
Other Linux
: Low enhancement
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Read comment #37. See discussion in b...
: 315569 322333 330400 339816 343333 399511 446044 449468 500348 505514 532948 576855 611231 703281 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-05-15 12:14 UTC by Nickolay V. Shmyrev
Modified: 2018-05-22 13:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch so it won't get lost (2.29 KB, patch)
2005-05-16 14:56 UTC, Nickolay V. Shmyrev
needs-work Details | Review
A patch that adds ReloadURI dbus method (4.56 KB, patch)
2005-07-22 18:22 UTC, Carlos Garcia Campos
rejected Details | Review
Command line tool for testing the previous patch (1.15 KB, text/x-csrc)
2005-07-22 18:25 UTC, Carlos Garcia Campos
  Details
evince asking to reload the current document (55.37 KB, image/png)
2007-09-06 18:47 UTC, Bryan W Clark
  Details
evince after auto-reloading the current document (65.68 KB, image/png)
2007-09-06 18:54 UTC, Bryan W Clark
  Details
New patch (9.90 KB, patch)
2008-06-11 11:01 UTC, Carlos Garcia Campos
none Details | Review
Updated patch (13.88 KB, patch)
2008-06-12 10:28 UTC, Carlos Garcia Campos
committed Details | Review
backtrace from segfault when reloading document (33.79 KB, text/plain)
2013-06-30 17:21 UTC, Pablo Rodríguez
  Details

Description Nickolay V. Shmyrev 2005-05-15 12:14:53 UTC
It would be nice if evince will automatically reload document on changes. This
can be easily implemented with GnomeVfsMonitor.
Comment 1 Marco Pesenti Gritti 2005-05-15 17:45:33 UTC
I think this was already discussed in another bug...
Comment 2 Olav Vitters 2005-05-15 18:05:08 UTC
Could be dupe of bug 171582
Comment 3 Nickolay V. Shmyrev 2005-05-15 18:12:20 UTC
No problem. 

*** This bug has been marked as a duplicate of 171582 ***
Comment 4 Bryan W Clark 2005-05-16 03:17:30 UTC
Actually this is about the reload vs. monitor see bug 165119
Comment 5 Bryan W Clark 2005-05-16 03:17:44 UTC

*** This bug has been marked as a duplicate of 165119 ***
Comment 6 Nickolay V. Shmyrev 2005-05-16 05:54:31 UTC
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.
Comment 7 Nickolay V. Shmyrev 2005-05-16 14:56:07 UTC
Created attachment 46494 [details] [review]
Patch so it won't get lost
Comment 8 Nickolay V. Shmyrev 2005-05-17 12:19:06 UTC
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?
Comment 9 Bryan W Clark 2005-05-17 14:40:37 UTC
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. :-)
Comment 10 Nickolay V. Shmyrev 2005-05-18 06:37:52 UTC
Well, I agree. What about addition of gconf key, hidded from UI to enable this
functionality?
Comment 11 Reinout van Schouwen 2005-06-22 14:24:58 UTC
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. :-)
Comment 12 Marco Pesenti Gritti 2005-06-22 15:16:26 UTC
FWIW That's not necessarily the only way to implement it. The application could
notify evince that it needs to reload.
Comment 13 Sebastian Spaeth 2005-07-05 11:29:22 UTC
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.
Comment 14 Troy Henderson 2005-07-16 13:51:23 UTC
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.
Comment 15 Bryan W Clark 2005-07-19 14:44:26 UTC
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.
Comment 16 Troy Henderson 2005-07-19 22:34:05 UTC
I really appreciate the open mindedness here.  This seems like a *great* (stated
sarcastically) way to accomidate the users.  Thanks again!!!
Comment 17 Reinout van Schouwen 2005-07-19 22:51:51 UTC
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.)
Comment 18 Troy Henderson 2005-07-20 10:04:29 UTC
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.
Comment 19 Bryan W Clark 2005-07-20 16:30:03 UTC
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.
Comment 20 Troy Henderson 2005-07-21 00:30:13 UTC
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.
Comment 21 Troy Henderson 2005-07-21 10:34:33 UTC
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!
Comment 22 Carlos Garcia Campos 2005-07-22 18:22:50 UTC
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
Comment 23 Carlos Garcia Campos 2005-07-22 18:25:22 UTC
Created attachment 49588 [details]
Command line tool for testing the previous patch

I also attach a command line tool for testing the patch
Comment 24 Troy Henderson 2005-08-11 03:36:08 UTC
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.
Comment 25 Carlos Garcia Campos 2005-08-11 11:07:07 UTC
which dbus version are you using? I think dbus/dbus-glib-bindings.h is a
generated file, so it isn't in CVS.
Comment 26 Troy Henderson 2005-08-11 12:35:15 UTC
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).
Comment 27 Troy Henderson 2005-08-11 22:34:25 UTC
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?
Comment 28 Carlos Garcia Campos 2005-08-12 15:49:06 UTC
You need to open evince with thesis.pdf before launching the reload command. 
Comment 29 Troy Henderson 2005-08-12 16:20:06 UTC
Carlos, I did this.  I did

evince thesis.pdf &
./reload thesis.pdf

and that's when I get that error!
Comment 30 Carlos Garcia Campos 2005-08-12 17:15:31 UTC
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.
Comment 31 Troy Henderson 2005-08-12 17:28:32 UTC
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.
Comment 32 Alina Beygelzimer 2005-08-22 23:08:23 UTC
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.
Comment 33 Nickolay V. Shmyrev 2005-09-08 19:51:09 UTC
*** Bug 315569 has been marked as a duplicate of this bug. ***
Comment 34 Kristoffer Lundén 2005-10-23 19:48:23 UTC
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.
Comment 35 Nickolay V. Shmyrev 2005-11-24 15:14:45 UTC
*** Bug 322333 has been marked as a duplicate of this bug. ***
Comment 36 Troy Henderson 2005-12-16 10:59:02 UTC
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.
Comment 37 Nickolay V. Shmyrev 2005-12-16 14:42:49 UTC
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.
Comment 38 aurelien 2006-01-07 13:04:15 UTC
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 :)
Comment 39 Alan Siu-Lung Tam 2006-01-31 12:19:56 UTC
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.
Comment 40 Reinout van Schouwen 2006-01-31 12:43:05 UTC
Agreed. The fix for bug 165119 still leaves issues open from this bug.
Comment 41 Alan Siu-Lung Tam 2006-01-31 13:38:01 UTC
(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.
Comment 42 Nickolay V. Shmyrev 2006-02-08 21:30:36 UTC
*** Bug 330400 has been marked as a duplicate of this bug. ***
Comment 43 Marc Strämke 2006-04-26 14:57:04 UTC
*** Bug 339816 has been marked as a duplicate of this bug. ***
Comment 44 Olaf Leidinger 2006-05-09 18:53:36 UTC
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.
Comment 45 Wouter Bolsterlee (uws) 2006-05-17 15:44:48 UTC
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.
Comment 46 Wouter Bolsterlee (uws) 2006-05-17 16:00:29 UTC
(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
Comment 47 Mårten Woxberg 2006-05-17 16:19:52 UTC
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.
Comment 48 Carlos Garcia Campos 2006-05-17 17:59:46 UTC
hmm, IMHO a popup could be really annoying. 
Comment 49 Wouter Bolsterlee (uws) 2006-05-17 22:04:45 UTC
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)
Comment 50 Olav Vitters 2006-05-29 21:50:59 UTC
*** Bug 343333 has been marked as a duplicate of this bug. ***
Comment 51 Daniel Holbach 2006-08-28 11:39:35 UTC
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.
Comment 52 Nickolay V. Shmyrev 2006-08-28 12:22:16 UTC
Daniel, we have no automatic reloading yet. Can you please check ubuntu package sources if they add some patches?
Comment 53 Nickolay V. Shmyrev 2006-08-28 12:29:22 UTC
> 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
Comment 54 Robert McNees 2006-09-07 00:07:20 UTC
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. 

Comment 55 Ed Schofield 2006-09-12 15:12:42 UTC
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.
Comment 56 Alan Siu-Lung Tam 2006-09-12 17:33:38 UTC
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
Comment 57 Nickolay V. Shmyrev 2006-09-14 08:40:31 UTC
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
Comment 58 Adam Schreiber 2006-09-25 19:50:26 UTC
(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?
Comment 59 Nickolay V. Shmyrev 2006-09-25 20:23:14 UTC
It's in HEAD, will be in 0.6.1
Comment 60 Alan Siu-Lung Tam 2006-10-24 20:38:57 UTC
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.
Comment 61 Wouter Bolsterlee (uws) 2006-10-24 20:50:22 UTC
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".
Comment 62 Alan Siu-Lung Tam 2006-10-24 21:02:49 UTC
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.
Comment 63 Nickolay V. Shmyrev 2007-01-23 07:50:38 UTC
*** Bug 399511 has been marked as a duplicate of this bug. ***
Comment 64 Alan Siu-Lung Tam 2007-03-25 19:57:24 UTC
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.
Comment 65 Nickolay V. Shmyrev 2007-06-10 15:10:52 UTC
*** Bug 446044 has been marked as a duplicate of this bug. ***
Comment 66 Nickolay V. Shmyrev 2007-06-20 14:18:19 UTC
*** Bug 449468 has been marked as a duplicate of this bug. ***
Comment 67 Bryan W Clark 2007-09-06 18:40:34 UTC
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)
Comment 68 Bryan W Clark 2007-09-06 18:47:07 UTC
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.
Comment 69 Bryan W Clark 2007-09-06 18:54:43 UTC
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.
Comment 70 Nickolay V. Shmyrev 2007-11-29 05:07:46 UTC
*** Bug 500348 has been marked as a duplicate of this bug. ***
Comment 71 Nickolay V. Shmyrev 2007-12-25 05:46:39 UTC
*** Bug 505514 has been marked as a duplicate of this bug. ***
Comment 72 Zack Weinberg 2007-12-25 06:10:36 UTC
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.
Comment 73 Florian Wilhelm 2008-02-24 10:51:25 UTC
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. 
Comment 74 Wouter Bolsterlee (uws) 2008-02-24 15:06:01 UTC
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.
Comment 75 Carlos Garcia Campos 2008-02-25 09:16:07 UTC
(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. 


Comment 76 Wouter Bolsterlee (uws) 2008-02-25 09:22:25 UTC
(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.
Comment 77 Michal Čihař 2008-02-25 09:48:51 UTC
(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?
Comment 78 Bastien Nocera 2008-02-25 09:56:37 UTC
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.
Comment 79 Wouter Bolsterlee (uws) 2008-02-25 09:59:12 UTC
(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.
Comment 80 Wouter Bolsterlee (uws) 2008-02-25 10:31:09 UTC
(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.
Comment 81 Florian Wilhelm 2008-03-05 17:28:14 UTC
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.
Comment 82 Robert McNees 2008-03-05 18:37:41 UTC
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). 
Comment 83 Zack Weinberg 2008-03-05 18:57:15 UTC
(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.
Comment 84 Robert McNees 2008-03-05 19:02:22 UTC
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.

Comment 85 Zack Weinberg 2008-03-05 19:08:09 UTC
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.
Comment 86 Wouter Bolsterlee (uws) 2008-03-05 23:20:21 UTC
(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.
Comment 87 Zack Weinberg 2008-03-05 23:48:31 UTC
(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.
Comment 88 Nickolay V. Shmyrev 2008-05-13 14:50:57 UTC
*** Bug 532948 has been marked as a duplicate of this bug. ***
Comment 89 Mathias Nedrebø 2008-06-09 23:08:30 UTC
(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.
Comment 90 Bastien Nocera 2008-06-09 23:55:22 UTC
(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.
Comment 91 Carlos Garcia Campos 2008-06-11 11:01:34 UTC
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?
Comment 92 Reinout van Schouwen 2008-06-11 16:32:07 UTC
(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.

Comment 93 Mathias Nedrebø 2008-06-11 16:46:21 UTC
(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.
Comment 94 Mathias Nedrebø 2008-06-11 20:33:01 UTC
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

Comment 95 Nickolay V. Shmyrev 2008-06-12 03:26:51 UTC
For the reason in comment #94 I suggest to make a test for the patch before applying it.
Comment 96 Bastien Nocera 2008-06-12 08:43:19 UTC
Seems like 5 seconds isn't quite enough. Carlos, would you mind adding timing output in ev_file_monitor_changed_cb()?
Comment 97 Carlos Garcia Campos 2008-06-12 10:28:10 UTC
Created attachment 112604 [details] [review]
Updated patch

Ok, I have a new patch. Please try again, it should work now.
Comment 98 Mathias Nedrebø 2008-06-12 11:18:23 UTC
(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
Comment 99 Mathias Nedrebø 2008-06-12 11:32:47 UTC
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
Comment 100 Carlos Garcia Campos 2008-06-12 11:41:17 UTC
It works for me. . .
Comment 101 Mathias Nedrebø 2008-06-12 12:32:50 UTC
(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!
Comment 102 Carlos Garcia Campos 2008-06-15 14:59:18 UTC
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)
Comment 103 Paul Sladen 2008-10-10 16:07:10 UTC
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!".

Comment 104 Leandro Martínez 2008-12-09 12:21:30 UTC
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.
Comment 105 Leandro Martínez 2008-12-09 12:57:14 UTC
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.

Comment 106 Matt McCutchen 2008-12-09 16:58:05 UTC
(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).
Comment 107 Leandro Martínez 2008-12-09 17:10:15 UTC
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?


Comment 108 Matt McCutchen 2008-12-09 17:19:26 UTC
(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.
Comment 109 Sven 2008-12-11 18:12:24 UTC
(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.
Comment 110 Matt McCutchen 2008-12-13 07:06:07 UTC
(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.
Comment 111 Sven 2008-12-13 12:47:56 UTC
(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.
Comment 112 Leandro Martínez 2008-12-13 13:40:08 UTC
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.

Comment 113 Wouter Bolsterlee (uws) 2009-02-09 18:25:23 UTC
(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.
Comment 114 Nickolay V. Shmyrev 2009-03-26 19:44:26 UTC
*** Bug 576855 has been marked as a duplicate of this bug. ***
Comment 115 Germán Poo-Caamaño 2013-06-15 07:35:25 UTC
*** Bug 611231 has been marked as a duplicate of this bug. ***
Comment 116 Germán Poo-Caamaño 2013-06-28 18:39:14 UTC
*** Bug 703281 has been marked as a duplicate of this bug. ***
Comment 117 Pablo Rodríguez 2013-06-30 17:21:07 UTC
Created attachment 248097 [details]
backtrace from segfault when reloading document
Comment 118 Pablo Rodríguez 2013-06-30 17:23:29 UTC
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
Comment 119 Germán Poo-Caamaño 2014-09-22 18:19:47 UTC
*** Bug 737105 has been marked as a duplicate of this bug. ***
Comment 120 GNOME Infrastructure Team 2018-05-22 13:01:25 UTC
-- 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.