Bug 310531 - Okular does not reload files after modification
Summary: Okular does not reload files after modification
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 0.15.80
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-22 22:20 UTC by Eugene Shalygin
Modified: 2012-12-12 21:57 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.10
Sentry Crash Report:


Attachments
Stupid fix for the reload problem (897 bytes, patch)
2012-11-23 16:23 UTC, Eugene Shalygin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Shalygin 2012-11-22 22:20:51 UTC
After upgrade to KDE 4.9.80, Okular stopeed to reload PDF files after latex runs.

Reproducible: Always
Comment 1 Eugene Shalygin 2012-11-22 22:29:17 UTC
Okular detects when the file is trancated, but does not reload it when the file is ready
Comment 2 Albert Astals Cid 2012-11-22 22:50:57 UTC
What do you mean with comment #1?
Comment 3 Eugene Shalygin 2012-11-22 23:17:19 UTC
I meant that the program is not completely disconnected from the filesystem events: it reacts on file truncation by latex. I.e.: I open a PDF in Okular, then run latex. When latex starts to write a PDF, it removes (or truncates?) the PDF file. At this moment Okular reacts in a some way that leads to removing the document from Okular. But later, when the PDF it ready, Okular does not load it.
Comment 4 Albert Astals Cid 2012-11-22 23:27:20 UTC
Can you please make sure the "Reload document on file change" option is still checked?
Comment 5 Eugene Shalygin 2012-11-23 00:46:03 UTC
Yes, it is checked. Otherwise Okular does not react on file truncation (deletion).
Comment 6 Eugene Shalygin 2012-11-23 15:53:26 UTC
I found that after the first update (file truncation), the oldUrl in Part::slotDoFileDirty() is always empty (yes, the file has been closed. So this seems to be correct). But then how it is impossible to reopen the document?

Perhaps, there is not need to close the file on truncation at all? At least with latex it would be more useful, since one can read further while PDF is regenerating.
Comment 7 Albert Astals Cid 2012-11-23 16:10:21 UTC
oldUrl should never be empty (actually it is not here), and your logic of why it is empty is wrong because the document is closed at the next line after oldUrl is assigned.
Comment 8 Eugene Shalygin 2012-11-23 16:22:19 UTC
I'm saying what I have seen from a debug print.

When Okular detects that file is deleted, it closes it, and fails to reopen.  When we come to the Part::slotDoFileDirty() next time (file is ready to be viewed), oldUlr became empty. From this point oldUrl is always empty and slotDoFileDirty() is been called continiously.
Comment 9 Eugene Shalygin 2012-11-23 16:23:52 UTC
Created attachment 75430 [details]
Stupid fix for the reload problem

This change fixes a problem for me. Just as an illustration.
Comment 10 Albert Astals Cid 2012-11-25 14:40:20 UTC
I think I know what's wrong, and you are partially right, oldUrl can be sometimes empty, your patch is not totally correct though, i'll work on something and post it here so you can give it a try.
Comment 11 Eugene Shalygin 2012-11-25 16:20:04 UTC
OK. thank you, I know that my changes are silly. I just wanted to illustrate that there is indeed a problem with oldUrl, since such change fixes the reloading process
Comment 12 Fabio D'Urso 2012-11-30 23:14:37 UTC
Git commit a0135a3c8ec64d1e5325091a7294de84365a6f4f by Fabio D'Urso.
Committed on 30/11/2012 at 23:24.
Pushed by fabiod into branch 'master'.

Fix reload of modified documents that take longer to be ready

SlotDoFileDirty tries to reload the file at regular intervals.
This patch fixes it so that it can actually reopen the file even if
it is not ready at the first timer shot.

M  +5    -3    part.cpp
M  +1    -0    part.h

http://commits.kde.org/okular/a0135a3c8ec64d1e5325091a7294de84365a6f4f
Comment 13 Christoph Feck 2012-12-06 14:20:41 UTC
On Thursday 06 December 2012 14:54:24 Albert Astals Cid wrote:
> Not sure i agree with this setting to 4.10, this was never broken
> in a "proper" release (i.e. was only broken in beta1) so to me
> setting this to fixed in 4.10 makes it seem as it was broken in
> stable releases before.
> 
> What's other people's feeling about this?

Oh sorry, I did not see it was a regression. Reverting will 
unfortunately not help, because bugzilla searches previously set 
values, too.

> 
> Cheers,
>   Albert
> 
> --- El jue, 6/12/12, Christoph Feck <christoph@maxiom.de> escribió:
> > De: Christoph Feck <christoph@maxiom.de>
> > Asunto: [Okular-devel] [Bug 310531] Okular does not reload files
> > after modification Para: okular-devel@kde.org
> > Fecha: jueves, 6 de diciembre, 2012 14:52
> > https://bugs.kde.org/show_bug.cgi?id=310531
> > 
> > Christoph Feck <christoph@maxiom.de>
> > changed:
> > 
> >            What 
> >   |Removed           
> >          |Added
> > -----------------------------------------------------------------
> > ----------- Version Fixed In|
> >                
> >       |4.10
Comment 14 Eugene Shalygin 2012-12-08 01:26:08 UTC
Thank you for the fix. But now there is another minor problem in version 0.15.90. Okular reloads file twice. I.e. After the file is ready and latex has exited, Okular loads file and then (within half of the second) it reloads it again. This glitch is annoying
Comment 15 Albert Astals Cid 2012-12-12 21:57:50 UTC
Are you sure about that? Are you sure the file is completely finished? Okular tries to reload the file while it's being changed, it might happen that at a given time we can open the file (i.e. it's a valid pdf) but it's still being changed by latex so it's closed and open again.

If you are *completely sure* it's a bug, please open a new bug (this one was about not reloading) and attach the files you are using so we can try to reproduce the problem.