qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

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/

iQEcBAEBAgAGBQJPnjdHAAoJEPSSjE3STU344gEH/0FWgvROCNkRBYb4+2RKxHKn
zT9OqSxp+vNzidtNBFTXLvPeFS0MuVjWQjLXo9QaTGOm6kplntW3yjo5gdJgwLHx
aBtZsci/hLCkqLT7sh3cHEViwOWteW8hle2bhsfnqLRbkOeRpTUsf14iJy6oRocu
yZ+OB1IsmN9xDusLndUqrJfgtwdfNx3+vm2uSoGSgA0z7IG6RpX23Ty2iItFIBep
zMxUlPvg/vs5Eivd9pHjkOo7RjzC0Sew6te/k8cRfpOHykDMk75mK7ALDy8kv2RS
b86OT+Kudw90o8pEMT8W9OxpoPC/CjSHPHx5lwzDtQBfOJftoLfrXjzOsIbgNx0=
=rZBS
-----END PGP SIGNATURE-----