qpdfview team mailing list archive

[Andi Șerbănescu <ac.serbanescu@xxxxxxxxx>]

Hello,

On 11 May 2012 22:46, Adam Reichold <adamreichold@xxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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).

> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPrWyWAAoJEPSSjE3STU34KBcH/jrUhzTt0rU14bcffY8jNf42
> l7waOCFYVLE9uBL04yJ1HQ4rSqbPJHATO/lz1aqFncCwAi4GrtwaTlhhClHiptV3
> 0fN+NjFzaYaKSm3RJ9drQnRig8u3TLFiv+T+3MqzbtxRPJkMwIn28Xq0fzL6iKHO
> n+hGJAd4/5cWnLBtuXegS53l2l9MB2axG4dkoMWlNpG+Fk2IaAeQN7qb9XAEzvNS
> TM+ohoSeX5yfEwpYxkIRHVk4zFGqN9pNCzHe+vdZsYkwsQuUHFM1A5PmwUDwEgr1
> yP5OSaLfgFYDeLPqTTmUn7RVIYS086oYDbm1fbKYAKmBF3RCF9pNjgiss9PSTs4=
> =nlJX
> -----END PGP SIGNATURE-----
>
> --
> 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.

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.

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.

Regards,
Andi