qpdfview team mailing list archive

[Adam Reichold <adamreichold@xxxxxxxxxxx>]

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

Hello again,

First of all: Thanks for the translation update. Will merge that into
trunk soon.

On 30.04.2012 19:33, Andi Șerbănescu wrote:
> On 30 April 2012 17:12, Adam Reichold <adamreichold@xxxxxxxxxxx>
> 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.

I hope you did not understand me wrong: I will focus on the code size,
but I also consider polishing up the interface "not adding features".
What I meant is that I will not introduce new features like new views
or very different behaviour.

So I am very interested in those remarks as I planned to work the
result of this discussion into that branch. And as I said, the tool
bars should already be a little smaller there. :-)

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

Oh, I think I will never ever be in the same league as Okular. But
nevertheless, if you check out the current revision of the future
branch you'll find:

A setting to switch whether fit to page (width) will scale uniformly
or not. (Default is to scale per page.)

A build-time option in "qpdfview.pri" called PAINT_LINKS which you can
comment out to disable the red borders around links. (And another one
called RENDER_FROM_DISK to enable parallel rendering of different
pages in the same view by opening several instance of the document
file. This will speed up rendering for large (e.g. scanned) or scanned
documents but introduces a slight delay. (This actually is the default
behaviour in trunk. Yields weird semantics concerning file change on
disk, so beware.)) (I did it using a build-time option since it did
not want to endanger to performance of methods like PageItem::paint by
called QSettings and possibly doing I/O. You seem more than capable to
customize the build, so I hope this makes you happy in this point.)

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

I'll think about that some more... But frankly, there are so many
options to pan using the keyboard, the mouse, the mouse wheel... But
as I said, I'll think about it.

Best regards, Adam.

> 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     :
>> qpdfview@xxxxxxxxxxxxxxxxxxx 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/

iQEcBAEBAgAGBQJPnuV8AAoJEPSSjE3STU34S3oH+wWUAlMJIh+iXljmJNJpYCvl
DqJEXXZ5WgPaTO8y1GbfGFzDRyKcPkY2X3AJlQGNB58LChjqzg3Fo1hxonT4gWTg
7j0y2Ng6ptuC9WFnPYB2Ilbz35XbP4qMGX7uYzvbBuNCXJ4f+6MK5e/eqMEzf+g0
VR0sCjjpok0p9zGDpiM2Y3ZRY2A937g9avyS0iqONkS7F/pWM/kmBsGkSRzmzR3W
6jKQw9ntZA9Q5hBuoWr17u1+XlxSLRQYD+ZcARXIDlevjg3K4zuzrqYZLsImMHnW
D5rPZ17x7tCRVbeYNn6y41tkv3NK45kNcBVnKdGlnKNXHCQnW7hahKua37zcqpw=
=YgR8
-----END PGP SIGNATURE-----