qpdfview team mailing list archive

["Benjamin Eltzner" <b.eltzner@xxxxxx>]

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.

> >>>>> 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?

> >>>>> 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...)
 
> >>>>> 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.


Cheers,

Benjamin
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de