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