qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

One remark concerning the translations: I think it would be good if
you considered added mnemonics to the labels. This can make keyboard
control considerably faster.

On 30.04.2012 19:33, Andi Șerbănescu wrote:
> On 30 April 2012 17:12, Adam Reichold <adamreichold@xxxxxxxxxxx>
> wrote: I started some work on the per-page scaling in the
> non-continuous modes and the tool bars in the "future" branch which
> will hopefully become version 0.2.3. I don't plan to add any
> features in that release but to focus on the code.
> 
>> Good luck, then. I had a few remarks, but I'll keep them for when
>> 0.2.3 is out.
> 
>> However, I've recently checked out okular and saw that in
>> continuous mode with fit width/page enabled, it scales each page
>> individually up to the largest allowable width/height, so they
>> all end up equal in that regard, which looks very pleasing
>> (especially for fit width). It would be really good if this could
>> be implemented (and made configurable, since you don't think it
>> should be the default behaviour).
> 
>> Making page up/down scroll by the screenfull (since they only put
>> you at the start of the previous/next page), while still changing
>> pages if they reach the top/bottom would also be nice.
> 
> You can grab it at 
> "https://code.launchpad.net/~adamreichold/qpdfview/future";. (Be
> aware though that the QtNetwork dependency is exchanged for a
> QtDBus dependency. This is used for IPC to enable the "--unique"
> command-line option.)
> 
>> Thanks.
> 
> On 30.04.2012 08:55, Adam Reichold wrote:
>>>> Hello,
>>>> 
>>>> Thanks for your input. I think that the results of this
>>>> discussion will be taken up in version 0.2.3 and below are my
>>>> first thoughts.
>>>> 
>>>> On 30.04.2012 01:25, Andi Șerbănescu wrote:
>>>>> Hello,
>>>> 
>>>>> I tried the latest beta and I have to say I that although
>>>>> the program is eminently usable, the interface does require
>>>>> some polishing. All in all, this is good software, for
>>>>> which I am grateful (and rather impressed by its progress).
>>>>> The following suggestions should obviously not be construed
>>>>> as criticism.
>>>> 
>>>> Nice that you the find the program helpful. I do however
>>>> think that what is coming next is criticism. But I also think
>>>> that this is a good thing. :-) (Isn't sharing and discussing
>>>> ideas one of the things free software is about?)
>>>> 
>>>>> 1. The toolbars. I think they could use less space.
>>>> 
>>>>> First, they're too tall. I believe they should be made as
>>>>> short as the icons allow, like other Qt applications (this
>>>>> also includes the search bar). They're also too wide.
>>>> 
>>>> On could probably reduce the content margins everywhere.
>>>> Layout inside a tool bar seems problematic anyway and I will
>>>> definitely have a look at that for 0.2.3.
>>>> 
>>>>> The page field and the spaces in between could be made
>>>>> narrower, so that the information would flow naturally
>>>>> (there probably aren't any documents that need such wide
>>>>> fields anyway); also, replace „of” with „/” (it's the
>>>>> shorter and doesn't need translating, thus it's the same
>>>>> length in all languages).
>>>> 
>>>> I don't like replacing simple words with symbols (the meaning
>>>> of which is just as culture-dependent). IMHO, a bit of
>>>> verbosity is not necessarily a bad thing.
>>>> 
>>>>> The page layout drop-down list could be successfully
>>>>> replaced with 2 buttons: one to switch between showing 1 or
>>>>> 2 pages on screen and another one to toggle continuous
>>>>> (column) mode. The same goes for rotation: one button to
>>>>> cycle between the 4 options would be enough.
>>>> 
>>>>> The scaling drop-down list should be replaced by 4 buttons:
>>>>> one each for fit page, fit width, zoom in and zoom out,
>>>>> complemented by a narrow text field which only displays and
>>>>> reads percentages (again, no translation needed, so the
>>>>> toolbar size will be wholly language-neutral).
>>>> 
>>>> I actually prefer the "random access" of the combo boxes to
>>>> the cycling using buttons. But you actually (kind of) have
>>>> this option already: If you hold shift or control, the mouse
>>>> wheel cycles through rotation and scaling.
>>>> 
>>>>> The extra space (making one toolbar out of these 3 should
>>>>> also save some) could be used for some new buttons, such as
>>>>> search, full screen, outline and thumbnails. The search
>>>>> toolbar could be improved by replacing the text buttons
>>>>> with graphic ones (besides reducing its height) and adding
>>>>> another icon on the left for closing it.
>>>> 
>>>> I agree about replacing/adding buttons in the search tool
>>>> bar. Will work on that. I won't collapse the tool bars into
>>>> one however as the gain is minimal but the loss of
>>>> flexibility is large.
>>>> 
>>>> As for adding new buttons, I'd rather avoid bringing back in
>>>> the clutter after removing some. If you really want fast
>>>> access to those functions, there are always keyboard
>>>> shortcuts like control+F or F11. (I think I made sure that
>>>> all/most of the functionality is accessible by keyboard. At
>>>> least I hope so.)
>>>> 
>>>>> 2. The menus. Nothing special here, except that the page
>>>>> layout, scaling and rotation options should go under their
>>>>> own submenus, to avoid making view too long. The page
>>>>> navigation entries would probably also make more sense
>>>>> under their own submenu in view, rather than under edit.
>>>> 
>>>> I thought about it and like with the tool bar buttons, I
>>>> actually prefer the fast random access to opening another sub
>>>> menu. My monitor probably isn't to high resolution either and
>>>> I find the screen space well spent.
>>>> 
>>>>> Perhaps the context menu should have some of the
>>>>> functionality of the toolbars (page navigation, zoom,
>>>>> rotation etc.); likewise, a menu for the bookmarks
>>>>> (entries), and possibly some buttons too (now I'm beginning
>>>>> to see the reason for multiple toolbars) would be a nice
>>>>> complement.
>>>> 
>>>> I think of the bookmarks as really making sense only if used
>>>> by keyboard but of course in a GUI, features should have a
>>>> graphical representation. In that sense, the context menu is
>>>> more about discoverability than anything else. It also
>>>> emphasizes the transient nature of the bookmarks (depending
>>>> on the current view mode). If they would be present in the
>>>> main menu bar, I would probably expect them to restored after
>>>> restart or something like that. Therefore, I would prefer to
>>>> make the document view context menu the home of (and only of)
>>>> the bookmarks.
>>>> 
>>>>> 3. The general feel. The red boxes around links look kind
>>>>> of ugly. Maybe they can only display when the pointer is
>>>>> hovering above them. There's also the issue of pages not
>>>>> being properly centred if their sizes are not all the
>>>>> same.
>>>> 
>>>> Personally, I like the red boxes to find out what is a link
>>>> "at a glance" without hovering. (Which will rather tell you
>>>> the destination, i.e. assumes you are all already
>>>> interested.) But I think this could rather easily be made
>>>> configurable.
>>>> 
>>>>> One thing that really bothers me is that when activating
>>>>> fit page or fit width, the zoom level is set globally in
>>>>> order to fit the biggest page, so that if you have a
>>>>> document with various page widths you're stuck with a zoom
>>>>> level adequate only for the biggest one, even in
>>>>> non-continuous mode.
>>>> 
>>>>> This should at least be fixed for non-continuous, so the
>>>>> zoom level would be set according to the current page (or
>>>>> the largest of the 2 current pages). It wouldn't hurt to
>>>>> have some way of deciding which page is „current” and
>>>>> setting the zoom level accordingly for continuous mode too,
>>>>> although it might not be as easy.
>>>> 
>>>> Yes, this is a known limitation. (Also the reason for the
>>>> strange positioning.) I think it definitely should be this
>>>> way in the continuous modes but obviously not in the
>>>> non-continuous modes. I also think the infrastructure is
>>>> there, I will just need to change how the scale factors are
>>>> calculated. So I will work on that. (The centering itself
>>>> will probably a bit more difficult and I'm not so sure
>>>> whether the result will be worth the added complexity. Will 
>>>> think about it though.)
>>>> 
>>>>> That was all I could think of. I also intend to contribute
>>>>> a Romanian translation after these issues have been
>>>>> discussed.
>>>> 
>>>> Contributions are always appreciated. (Do you intend to use 
>>>> Launchpad or the Qt translations mechanism?) (Of course, you
>>>> could still end up in the contributors file of 0.2.2 as I
>>>> probably wont release until the weekend to wait for
>>>> translation work. :-))
>>>> 
>>>> Best regards, Adam.
>>>> 
>> 
>> -- Mailing list: https://launchpad.net/~qpdfview Post to     :
>> qpdfview@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>> https://launchpad.net/~qpdfview More help   :
>> https://help.launchpad.net/ListHelp
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPnuiPAAoJEPSSjE3STU34m38H/1l2RNa266xrBdBDY36xqjIJ
C/ihxZ6lBI8+1HzvfMsvxLk7voBKinoZnes/x2E9ZzuyZ29mvR9U/2Rwhdkqcb34
5gAaBEyQZuPEIK1lhrccQgOMsY52Z5qqE3KpI9AUDwzjxzQ3tJA5u7xiCr8EH44F
mxo79ZkpvhiOrWtOn8jG+W1+VwR2TQT69xh8g3a1HD1Ak3kPdHgg8O5Tkq5K8nBq
Ll7RlhxQxDKgJwuPRTOCZocgeIH6xqslcFUZa9odxx64v5duLVFiEq7YNBJ4ZF7v
DHu78EZpnPZ8YliFQOdOsfnfbv+D8InVG+Zio74l7NdO1LkQrhuDqUkg2K4oglg=
=qf75
-----END PGP SIGNATURE-----