Bug 139629 - Wish "bug", file reload mechanism could be more efficient
Summary: Wish "bug", file reload mechanism could be more efficient
Status: RESOLVED DUPLICATE of bug 136820
Alias: None
Product: kpdf
Classification: Applications
Component: general (show other bugs)
Version: 0.5.5
Platform: Debian testing Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Albert Astals Cid
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-05 11:57 UTC by rusconi
Modified: 2009-01-31 14:06 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rusconi 2007-01-05 11:57:42 UTC
Version:           0.5.5 (using KDE KDE 3.5.5)
Installed from:    Debian testing/unstable Packages
OS:                Linux

I am enjoying KDE since a short time. Great stuff. I almost exclusively use the LaTeX package for doing my text work. Having side by side the editor window and the kpdf window I can edit and trigger a recompile of the document while looking at the kpdf window that will monitor file changes on the pdf file. Good.

There is a point here, however: imagine the document takes long to compile with pdflatex (big number of graphics files); as soon as the pdf file changes on disk, kpdf will switch to "reload mode", thus erasing the contents of the current page. Because the currently displayed page might be far from the first page of the document, the time course between the "file has changed" sensing step and the effective redisplay of the re-rendered page might be very long. That is sad because when writing complex scientific stuff, one very often reads and re-reads the same paragraph and the precedent one many many times. The time course above is all time lost which could be spent doing re-reads, while the document renders fully.

xpdf has a very very nice feature: a pdf file might be opened by telling xpdf that it should launch as a "server". The document reload might be triggered by asking that specific "server" to reload. In my Makefile setup, I have integrated that functionality by having the recompile instruction followed by a reload instruction to the xpdf "server". During all the long time of the recompile, xpdf does not reload the document (no file change sensing). xpdf only reloads the document when the makefile instruction tells it to do so (that is at the end of the full document rendering). And during all that time I can look at the rendered pdf file for more changes or other corrections to do. That makes working with LaTeX extremely streamlined and efficient.

Do you think this would be difficult to implement in kpdf, or is there some equivalent method already existing ? For the moment, I must admit the xpdf methods works best for me...

Cheers, and congratulation for a wonderful desktop environment.

Filippo Rusconi
an ex-GNOME user :-)
Comment 1 Pino Toscano 2007-01-05 12:15:28 UTC
What you propose seems more or less what was requested in bug #136820, isn't it?
Comment 2 rusconi 2009-01-31 14:02:44 UTC
Well, since Okular provides the correct solution, I close this bug (works for me). Am I right to do so ? If not, then sorry, I'm learning to work with the bug tracking system and I'm eager to receive explanations!

Cheers,

Filippo
Comment 3 Pino Toscano 2009-01-31 14:06:36 UTC
Well, you could have replied to my question in comment #1, at least...

*** This bug has been marked as a duplicate of bug 136820 ***