qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

I changed the keyboard shortcuts to more traditional settings in trunk
revision 242. (Help already reflects that.)

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