-----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----- -- Mailing list: https://launchpad.net/~qpdfview Post to : [email protected] Unsubscribe : https://launchpad.net/~qpdfview More help : https://help.launchpad.net/ListHelp
