qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

As usual, I do more or less what the users want: Revision 236 now has
configuration options for "highlight links" (i.e. the red boxes are
links) and "fit to equal width". Please test and comment...

On 11.05.2012 13:41, Adam Reichold wrote:
> 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/

iQEcBAEBAgAGBQJPrQpxAAoJEPSSjE3STU34y+sH/0p6k2botOoidrQ1LU+NKW9T
S/7X/lef1/lYVP6gpDpcfVv1I1Af3LIdLCIzkYkVTC7gCsjQBtjRCnZdMKuNUu+R
/rm6Nrr0+qOr4IrPsg1NAbGXE8jd5c9yjyvxq0xc8+uIdNshlTRUt6/aWbsb5CJE
t+DzU5Ztnv9Z8VWx8erydxeLGznmv7BN+4MYDqGug3/qhkFSPSKGHPonYHRwXYva
IXsC7ECTV+/2wWMHjZCswARhlLpA4uTEUCQkRl3HWMhVqpvI7sJW/hFczj09pUcD
eH0vqI5g23zX609qmwEFa9K1euzsE6eHZ2AlhxI4qQ7FX5nov/szq21cLfaZMLA=
=lhvJ
-----END PGP SIGNATURE-----