qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Sorry, failed to send to the mailing list myself. But see below as well.

On 12.05.2012 12:31, Adam Reichold wrote:
> Hey,
> 
> On 12.05.2012 12:20, Andi Șerbănescu wrote:
>> Hello,
> 
>> On 11 May 2012 22:46, Adam Reichold <adamreichold@xxxxxxxxxxx> 
>> wrote: I changed the keyboard shortcuts to more traditional 
>> settings in trunk revision 242. (Help already reflects that.)
> 
> 
>>> I thought I might join in on this. This is not entirely good
>>> (I hope Benjamin will concur), since we've lost the
>>> functionality previously bound to up/down (scrolling one/a few
>>> lines at a time).
> 
>>> And right now we have 3 pairs of keys doing the same thing 
>>> (skipping pages). I think only left/right should do this if we 
>>> are to go the way of ui-conservatism (bksp/sp also does the
>>> same thing that pgup/pgdn does).
> 
> At this point, I probably lost any opinion on the topic. ;-)
> 
> So I'll change it to: arrow left/right: skip a page
> backwards/forwards arrow up/down: do nothing, i.e. the scrollbars
> take it to pan the view page up/down: scroll one screen at a time 
> space/backspace: scroll one screen at a time
> 
>> Beside that, I'd appreciate a more sober tone on the mailing
>> list if possible. (Of course, this applies to myself as well.)
> 
>> On 11.05.2012 19:01, Benjamin Eltzner wrote:
>>>>> Hi,
>>>>> 
>>>>> first of all: You're the coder, so as it's do or die, you
>>>>> do, I die. :-)
>>>>> 
>>>>>>> 
>>>>>>> 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.
>>>>> 
>>>>> Okay, since you seem to really not understand this point 
>>>>> (despite my bestest effort), here's an explanation: I
>>>>> expect _most_ users to be ui-conservative. So the whole
>>>>> point of "others do it like that" is really "users will
>>>>> probably expect this behaviour (at least I do)". You are of
>>>>> course free to question the value of this argument, but if
>>>>> it were your aim (I assume it is not) to win users by
>>>>> making the program easily accessible, I suppose this breed
>>>>> of arguments might be worth considering. :-)
>>>>> 
>>>>>> Besides, some comment on what you actually would like as 
>>>>>> the default toolbar entries would have been nice.
>>>>> 
>>>>> If I have configuration options I do not care that much 
>>>>> about defaults, so I thought I'd not spoil this discussion 
>>>>> for those who really rely on the fallback.
>>>>> 
>>>>>>> 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.
>>>>> 
>>>>> I do not quite get the problem ("The semantics are unclear 
>>>>> and prone to failure"). I think, if it were simply a 
>>>>> sibylline option in a config file, the average user would
>>>>> be sufficiently shielded from it... Also I do not see the 
>>>>> problem in pointing out its potentially problematic
>>>>> behaviour in the help-file, but as I said: You're the
>>>>> coder.
>>>>> 
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Benjamin
>>> 
>>> -- Mailing list: https://launchpad.net/~qpdfview Post to     : 
>>> qpdfview@xxxxxxxxxxxxxxxxxxx Unsubscribe : 
>>> https://launchpad.net/~qpdfview More help   : 
>>> https://help.launchpad.net/ListHelp
> 
>> PS. Regarding icons, did you check out oxygen? I believe it only 
>> lacks one for continuous mode. We could also borrow from DjView.
> 
> No, I did not really check that out yet. Benjamin said that he
> would probably have a look. But you are welcome to do so as well.
> 
> I mean if you find/create the suitable icons, post them (or a link
> or description how to find them) here and explain the license to
> me, I would be happy to include it into the program. (And add the
> missing toolbar buttons as configuration options.)
> 
> After all, its free software and this seems a nice opportunity for 
> users to get directly involved.
> 
>> The thumbnails are just fine (maybe 96*144 would be a little 
>> better), but they too tend to exhibit the annoying 1-pixel-wider 
>> behaviour.
> 
> Consider it committed. (The changed dimensions, I mean. No good
> news on the rounding errors from me.)
> 
>> I don't think they should be handled in physical units, since 
>> they're esentially interface objects, more akin to icons. It
>> would be good if you could drag them with the mouse, though.

You can now pan using the mouse as in the main view but this implies
that you have to double-click to jump to the page. I wonder whether
one should change the outline to "jump by double-click" as well for
consistency.

> Yes, that was my thinking as well.
> 
>> Regards, Andi
> 
> Regards, Adam.
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPrkEcAAoJEPSSjE3STU34iHAH/iFsbtHHS8pqfdGyJze7viFp
X+bBgOPpkgXH7KSeLL9ikD7+GcTD6XZU3z8VPtOetP69JmN+yvC3vnc+Adz1QOj+
isWEFRf5wFAFUmz2o+dVXGvgAL+yd3Qkex1SjxWLDDFywVfCIxSuqTlr9UCznnA+
W+6NSNliwRzLT/KV1KfoXB+SEXPBqRcAmGK6BOfSVBAIkNNCC66VJhxF1wwOA5ze
x5Jp3j1FmV6haVEa1q0HdhX09tQ5ib0SkdLcV5V+iAkm49E1qfhWoOjrBh0VubA1
W5O9cmGaQ6M39VuGu8zlODjOaVt+Rvp7TEqTkHV07ATbDJ1gNGO5xE+cr7veeVo=
=/mMr
-----END PGP SIGNATURE-----