qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On 11.05.2012 10:58, Benjamin Eltzner wrote:
> Hi,
> 
> I would like to share my opinion on some of the points discussed.
> Well, some of my comments might cross the border to completely
> unobjective rants.
> 
>>>>>>> Speaking of zoom, how about adding an option (maybe
>>>>>>> under settings) to scale all pages to the same width
>>>>>>> (the largest) under 2-page view, the way okular does?
>>>>>> 
>>>>>> I don't know, I am already a bit uncomfortable with the 
>>>>>> non-uniform scaling because it obscures the size
>>>>>> relations of the document which is IMHO what the viewer
>>>>>> is supposed to display. Therefore I would prefer to keep
>>>>>> at least the relative size of the two currently displayed
>>>>>> pages.
>>>>>> 
>>> 
>>>> You would be able to turn it off, of course. And the current
>>>> way of scaling would controlled by the same setting.
>> 
>> Added a build-time option "fit_to_equal_width" for you to try out
>> and tell me whether this is what you actually meant. Tough
>> personally, I don't like it. But of course, I could live with the
>> build-time option.
> 
> On the long run I quite generally prefer runtime options to
> buildtime options. (Config files are fine for less frequently used
> options.) So if this option is approved, I would prefer an
> implementation in the gui.

This could become a runtime option. Depends. Anyway, this is just for
testing how it should/could work but not the final implementation. (So
this could become for example "fit uniformly/fit per-row/fit per-row
to equal width" via the GUI...)

>>>>>>> There's also page down/up which could scroll one
>>>>>>> screenfull at a time, instead of just putting you at
>>>>>>> the beginning of the next/previous page.
>>>>>> 
>>>>>> I think it is better that way as there are so many ways
>>>>>> to scroll/pan and IMHO skipping pages is more important
>>>>>> in paged documents.
>>>>>> 
>>> 
>>>> Then how about leaving page up/down alone, and making, say, 
>>>> backspace and space do those things instead?
>> 
>> Good idea. Should be done.
> 
> In other viewers it seems usual that right-/left-arrow scroll by
> one page at a time, while page-up/-down scroll by the screenfull.
> Did I mention, that I am somewhat ui-conservative?

I don't see the argument here as I already commented on the "the other
programs do it that way". The functionality is now there and it is not
less accessible in any way.

>>>>>>> And now on to the good news. I see you added a few
>>>>>>> buttons. Of course, I wouldn't mind a few more :)
>>>>>> 
>>>>>> I do not think that making every function accessible
>>>>>> from the toolbars via buttons is a good idea. Only
>>>>>> functions that are used very often should go there to
>>>>>> keep the clutter to a minimum.
>>>>>> 
>>> 
>>>> I agree with you there. Come to think of it, I don't see why 
>>>> would both open and open in new tab, or save to file be in
>>>> the toolbar. (More on this below.)
>> 
>> Agreed. I reduced the default to "open in new tab" and "refresh"
>> for "file" and "current page", "number of pages", "previous page"
>> and "next page" for "edit".
>> 
>> This would probably be a good place for other users of this
>> mailing list to speak out what they would choose as the default
>> options as I will probably remove the fallback icons of the
>> non-default actions from the release. (Meaning you could not
>> really add them back in if your icon theme does not contain the
>> necessary icons. See below.)
> 
> I do not think that some 10-20 excessive .svg-icons create
> unbearable bloat, so I honestly do not see the point in throwing
> out the icons of non-default options. If you did not throw out
> icons, I would not have to bother. (Well actually I do not have to,
> because I use a standard ubuntu; but still, it is a matter of
> principle...)

Depends, e.g. if those icon make up most of the installed program
size? (I think we already were at 50% icons or something like that.)

But the real reasons is that I actually do not want to ship any icons
because qpdfview takes care to use standard icons only which should be
supplied by an FDo-compatible icon theme.

This really is just a fallback, i.e. a measure to preserve some
reduced level of functionality even though an icon theme is not
present which nevertheless is one of the design assumptions. So in a
sense, it is a matter of principle. Just the other way around.

Besides, some comment on what you actually would like as the default
toolbar entries would have been nice.

>>>>>>> I'd like it if you could have buttons for fit
>>>>>>> page/width, too, and make that drop-down list into a
>>>>>>> text box to display nothing else but percentages (like
>>>>>>> page number). You could always see the exact zoom
>>>>>>> level, and you'd also see if the buttons are pressed.
>>>>>> 
>>>>>> As I said earlier, I like the verbosity of have a 
>>>>>> self-explaining text there. And often, there also is no
>>>>>> such thing as "the exact zoom level" as the scaling is
>>>>>> non-uniform in the fit-to-X view modes, i.e. the scale
>>>>>> factor is an ill-defined quantity in these modes.
>>>>>> 
>>> 
>>>> I know, but I don't see why that would be a loss. Tooltips
>>>> could explain things instead.
>> 
>> I think I really like that combo box and will probably not change
>> it but see below.
> 
> I do not care about verbosity so much, but otherwise I am quite
> agnostic towards this point. Same for the
> continuous/single-double-page-box.
> 
> Also a question from the layman: Would it be much harder to make
> "render_from_disk" available as an option in a config file instead
> of a buildtime option? I have some esoteric use cases for this
> options, but I understand it is for the better not to use it as
> default. Still it would be great if it could be simply changed
> without recompiling.

It don't want to expose this a configuration option as I really want
to discourage its usage. (E.g. by making it a necessity to recompile.)
The semantics are unclear and prone to failure. The program will not
become unresponsive if this is disabled, just take a while longer to
render those pages. (Poppler 0.20 has some improvements for image
masks in the SplashOutputDev which should help with rendering speed
for your corner case. So there will be even less of a reason to use
this in the near future.)

So it is there if you feel reckless and really want it. But it will
probably never become a configuration option. Actually, for me, the
worst part is that I released the older versions with this as the default.

> Cheers,
> 
> Benjamin

Regards, Adam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPrPsDAAoJEPSSjE3STU34DjUH/iHY5lzuvlhYG6XnuYrmC47A
S60ZuSojZP52jMXrlTC9Gc3SJZmOciC0iCdGQVYgdIV2kjvi3iitC7sEMu43cjrK
BpgsceJ2n2nUeuUDvzN4EXv9HvsBxK3X50HC0+czZLo4B4XUTt5LgEjwNE6i1+tJ
YGbl+iXHAUQ2639X+toKaZxV4TmBbnBJan0FkF1Y2Hp8zfpFaiCc2dINCbSTnhK5
RNe2ldJQlawptACYPBuQ85fGx3FyWaZ/guHLj8F0QhHf8RkzzRpbuhsLx9FXqr9B
X+yxraCvPD7TM1lbETjKxbpnqo1chGh8/vKC47+mbmlzAd3Zd1t/XSVpiAuOPX4=
=qdc5
-----END PGP SIGNATURE-----