qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

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

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