← Back to team overview

qpdfview team mailing list archive

Re: [TeXstudio-list] texstudio PDF viewer


Hash: SHA1

Hi Tim,

I will commit the mortal sin of placing my comments after the bits of
your mail that I comment on. :-)

> Before I go into some details: What are the major shortcomings of
> our current viewer in your opinion? Exchanging the viewer should
> generate a significant benefit. Otherwise we'd better invest the
> time into other features.

The current TeXstudio viewer is very good for an ancillary program.
Drawbacks from my point of view are:
 * The zoom is too coarse grained (I cannot set a zoom between 100 %
and 133 % or 71% and 100 %). As it only has a slider and a spinbox
(not a combobox) I cannot enter a number manually. This is probably
trivial to adjust.
 * I have not found a way to rotate pages.
 * The viewer does not seem to prefetch and seems to have very limited
page cache, which makes it seem slow on documents with many images.
 * The viewer seems to (at least sometimes) block the interface on
rendering, which can be annoying at times.
 * The viewer-editor synchronicity feature (which is awesome) is
plagued by even worse interface blocking and jerking. (But this is
probably not something which using qpdfview would immediately improve.)

Some of these may be easy to enhance in the current viewer and some
may rather affect corner cases. If you think the benefit of changing
the viewer is not sufficient, I would still be delighted if you could
have a look at these points. (I guess the greatest benefit of using
qpdfview would be to avoid duplication of effort in the future.)

> Here are some of the requirements we have: - The GUI parts have to
> be flexible: There should be a viewer widget which may be used in a
> separate window or as part of an existing window. In the latter
> case, we have to think how to integrate the menu actions (that's
> also an open issue with our current viewer but needs to be 
> considered). The same holds for the dock widgets and maybe the
> status bar. - Also, there has to be an options concept that allows
> to integrate the necessary options in our options dialog. i.e. also
> the options have to be split in the library and the gui layer. -
> We'll have to see how the shortcuts work if we embed it as a
> widgets (we had some issues there with our own viewer). - For
> synctex, we also need the text-context of the click-position to 
> keep our almost-word-level syncing working. - I'd like to have a
> Zoom-Slider (but that should be easy to integrate in qpdfview) - It
> has to build on win, linux, and OSX (in a quick try, linux was ok,
>  windows didn't work, OSX untested)

Thank you for this coarse list of requirements that allows a rough
estimate of some of the work involved. I am aware that this implies a
lot of work and it is clear that it should only be done, if both
parties think it is useful.

> - It might make sense that TXS developers actively work on the
> qpdfview code during the transition.

That sounds reasonable to me, if you would be willing to spare the
effort. As Adam has done some work on threading (in my opinion,
qpdfview surpasses TeXstudio's current viewer in terms of non-blocking
interface) he might in turn be able to contribute to an enhancement of
the viewer-reader synchronicity.



Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/