Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#100 Usability Issues with the internal document preview pane.


continuing from:

@belshazzar: Concerning the shortcuts, please check svn revision 357 from
today. Amongst other things, the preview is now focusable.
It is focused when toggled on, and standard shortcuts (i.e. those of
evince) for moving and zooming are accessible. Ctrl+Tab moves the focus
from the view to the preview, and Tab or Ctrl+Tab does the converse.
Please tell me if it suits you.

(If you have other remarks, which I hope, maybe we should open a new
tracker item.)

my reply:

That is much better. Other than that I found that

1. It is somewhat slower than a stand-alone Evince.
2. The keyboard shortcuts are somehow buffered. The viewport keeps moving after you release the keys.
3. I find it confusing that every tab has it’s own preview, for files that belong to and are included in a master document.
Did you test the preview pane with a long document that has included files? If we ever get SyncTex support then we need at least a single preview pane for all files that belong to a master document.

In total, I’m not really convinced that an internal preview has many advantages over an external Evince window that is positioned similarly in the desktop workspace.


  • Hi Tobias,
    1. As José Aliste explained it (https://sourceforge.net/tracker/?func=detail&aid=2796407&group_id=204144&atid=988431) evince caches every single page you read in the document, and renders it asynchronously. It is way faster, but uses much more memory (it often happens to me when having many documents open at the same time that evince takes up to 700-800Mb RAM, and 150 Mb for only one file). In particular, the more you zoom, the more it takes memory. I guess this is why evince only lets you zoom to 400%.
    So this is a matter of choice (and of programming time!). When EvView will be out, and José will have implemented the preview with it, it should be much faster.

    2. I think this is the normal behaviour. After you filed this, I tried different things to prevent this, but without success... It is of course related to (point 1.) the fact that the rendering is not done asynchronously, and that PyGTK does only one GUI thing at a time.

    3. This is solved in svn revision 371, and should thus be in 0.2 final.