qpdfview team mailing list archive

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

On 30 April 2012 17:12, Adam Reichold <adamreichold@xxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPnp3DAAoJEPSSjE3STU34ouIIAIGaExCVGNDwe/Csb0zKlr92
> 4/Egn9MiZdTEWANFhY3kBmvN2ease3oX2/T2X54JhvjEZt8Dq8eR/rXtCOy9DBlP
> AK2OIkk/2HBR1FbWEek3l77W8xHARYkvT1ubTrMgTV6uRldJ5b95PsVOGk71jZtu
> a5rZgA8JdmB5wZpsZT/qdz968i6fc4pKfSes0ssZnhHfC55oLVm+RlYAjUQyVGxe
> DWK55Nel1VqRYdwgfzvBqWzYXJKWFbfGawhgROwGKyhJeDOeTyWHdqaJ2UAscM0i
> uylQxXFxK66MEwsHX9njBgabJySaqd7aiqRxTRz6ThI1I5at70miYurHhBcJGQE=
> =ZcfN
> -----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