-----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----- -- Mailing list: https://launchpad.net/~qpdfview Post to : [email protected] Unsubscribe : https://launchpad.net/~qpdfview More help : https://help.launchpad.net/ListHelp
