Synchronize outline view with main view

[Ari]

Note: This bug report's scope has been changed. Point 2.) is implemented in the latest qpdfview trunk.

######################################################################################

Hi again,

I hope you haven't gotten tired with my (quite overlong) bug reports. This one is to address a couple of observations and suggestions concerning the current state of navigation in qpdfview.

Let me first say that I am very much a fan of the customizability qpdfview offers in arranging different navigational elements such as the outline and thumbnails sidebars. I think this is a very important functionality that separates qpdfview from other PDF viewers and makes it a very enjoyable viewer to use overall. There are a few points that I think could be improved, though:

### 1.) Context-sensitive outline ###

## Overview ##

The overview pane is a great way of jumping between specific sections of a document. What I feel is lacking, though, is a way of telling what section you're currently in. Right now you have to compare the page number with the document outline to find out where you are. I think navigation within the document could be greatly improved if the the outline automatically adjusted to your progress within the document.

## Suggestions on implementation ##

I think there are two UI functions qpdfview would greatly benefit from:

 1. an outline indicator on your current location within the document
 2. automatically collapsing and expanding outline entries

I have attached a screenshot with a mock-up of how I think an outline indicator could look like. As for the second point, this is how I imagine it would work: As soon as you scroll past a high-level entry it's children are automatically expanded so as to allow the outline indicator to give a more detailed overview of your current position. Leaving an entry tree would make it collapse again and open the subsequent one.

(### 2.) Context-sensitive thumbnails pane ###

## Overview##

I think the thumbnails pane would just as well benefit from a progress indicator. The reasoning is the same as above: It's sometimes hard to identify the page you are on within the thumbnails pane. Highlighting the current page would remedy that.

## Suggestions on implementation ##

I have attached a very simple mock-up of what I imagine this could look like.) ✔

Thanks, again, for taking the time to read this

[Adam Reichold (adamreichold)]

Hello Ari,

Again before reviewing all of this, the best place to discuss ideas for the development is the mailing list at "https://launchpad.net/~qpdfview".

Regards, Adam.

[Adam Reichold (adamreichold)]

Hello again,

Highlighting the thumbnail for the current page in some (reserved) way should be possible to implement.

Concerning the outline, things are not that simple: The outline is just a tree of links, there is inherent order, e.g. a link to page 15 could be followed by link to page 3 and so on. Even if it is in page order, the 'order' of the links on a page if less well defined and depends on the reading direction, rotation, etc.. So I don't think implementing something like this is a clear cut and you it would consist of a bunch of heuristics in any case. Hence, I don't like the idea.

Regards, Adam.

[Adam Reichold (adamreichold)]

Hello again,

Since trunk revision 1114, there is a setting called 'highlight current thumbnail' which controls whether the thumbnail of the current page is highlighted.

Regards, Adam.

[Ari (ari-lp)]

> Since trunk revision 1114, there is a setting called 'highlight current thumbnail' which controls whether the thumbnail of the current page is highlighted.

This has got to be the fastest response time on a bug tracker I have ever experienced. Thank you for you commitment! I just tried the new revision out and the highlighting looks great, just how I imagined it.

> Concerning the outline, things are not that simple: The outline is just a tree of links, there is inherent order, e.g. a link to page 15 could be followed by link to page 3 and so on. Even if it is in page order, the 'order' of the links on a page if less well defined and depends on the reading direction, rotation, etc.. So I don't think implementing something like this is a clear cut and you it would consist of a bunch of heuristics in any case. Hence, I don't like the idea.

You're right, the embedded bookmarks can be quite chaotic at times. I see how that would be problem. Still, I think this feature could greatly enhance navigation in qpdfview and would be worth the effort - if not now then as a long-term goal. But that's up to you and other developers, of course. In the end I, as an end-user, really can have no idea what would go into coding a functionality like this.

[Adam Reichold (adamreichold)]

I'll rename the bug report and mark it as triaged then, for someone who is interested in investigating a synchronized outline view in the future.

[Ari (ari-lp)]

Hello Adam,

yes, that's absolutely fine with me. I edited the description to reflect the changes in the scope of this bug report.

Cheers
--Ari

[Adam Reichold (adamreichold)]

Trunk revision 1207 has a setting to enable a simple heuristic that will find the first entry that matches the current page.

[Ari (ari-lp)]

Hello Adam,

I was very glad to see your commit in my inbox and I now have the latest revision of qpdfview installed. The outline synchronization works great for me. I really like how the entries automatically expand to sub-entries when needed.

There are just two smaller graphical inconsistencies I think I found:

1. Only the chapter titles are highlighted right now. This looks a bit awkward, I think, and I'd prefer it if the page numbers were highlighted as well.

2. The highlighting appears to take up the "inactive color" by default and only switches back to the active state when clicking on an entry. I think that the color state should only change when the whole window is focused/unfocused - similarly to the thumbnail highlighting.

-----

These are only my first impressions with this new feature. I will have to do some more in-depth testing with more convoluted PDFs to see how the synchronization performs in these cases. I'll make sure to keep you posted on my findings.

Thanks again for taking the time to implement this!

Cheers
--Ari

[Adam Reichold (adamreichold)]

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

Hello Ari,

Am 08.08.2013 06:42, schrieb Ari:
> Hello Adam,
>
> I was very glad to see your commit in my inbox and I now have the
> latest revision of qpdfview installed. The outline synchronization
> works great for me. I really like how the entries automatically
> expand to sub- entries when needed.

Thanks for testing this and reporting about your findings here.

> There are just two smaller graphical inconsistencies I think I
> found:
>
> 1. Only the chapter titles are highlighted right now. This looks a
> bit awkward, I think, and I'd prefer it if the page numbers were
> highlighted as well.

I fine-tuned the selection of the outline view to work on a per-row
basis which should fix this issue and also enable to jump to a page by
clicking on the second column. This was committed to trunk revision 1212.

> 2. The highlighting appears to take up the "inactive color" by
> default and only switches back to the active state when clicking
> on an entry. I think that the color state should only change when
> the whole window is focused/unfocused - similarly to the thumbnail
> highlighting.

In contrast to the thumbnails view, the drawing behaviour of the
outline view is determined by Qt's tree view component and its active
style. Hence this out of scope for qpdfview. (And for example,
currently running qpdfview under KDE 4.10 with openSUSE's default
theme, I don't see the described behaviour. As I said, this could very
well be style-dependent.)

> -----
>
> These are only my first impressions with this new feature. I will
> have to do some more in-depth testing with more convoluted PDFs to
> see how the synchronization performs in these cases. I'll make
> sure to keep you posted on my findings.

This would be rather welcome. Note one known limitation though: The
"synchronization" will only expand and highlight entries that have
exactly the right page number. I am not sure if I am willing to extend
 this to an implementation finding a real lower bound yet.

> Thanks again for taking the time to implement this!
>
> Cheers --Ari
>

Best regards, Adam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJSA9jGAAoJEPSSjE3STU34plcH/2+MWMbSuo+/a8tEruOGb3a9
F4dOw8qBVZF6vd8DwZVWPFeC8skYdFMsewxmMnBlm1VVBkz9lCC17s4B1piiF03t
c5cvsKC2y54gQSwVfwolN7dn6A/yQkqroAfO+4M3m0rDJYfivN8FpdGFBxsQF4d5
atrTk5c0CG+YkQRaKzJfymGHWH/0bHSWWRqSJMJqvEvdoVI5ox6Tm/K19Eu4rM99
R+MDufT2Vhpsmr6PML2dvoJx4S9QgVXQCkDKwmiKlE/gGQbqGfR6Jf1TDmzBND1i
2gIIJyae5s0VoUaWZ4uSC7ff/i3WKZkRWtjtcElBoHROlLVFlSEllG86JKThsno=
=e0bE
-----END PGP SIGNATURE-----

[Ari (ari-lp)]

Hey Adam,

sorry for not getting back to you over the past couple of weeks. I was on holiday and didn't have access to my usual system. Now that I am back I will be able to report issues and other observations that arise form my daily usage of qpdfview.

I am glad to say that far I haven't encountered any particular problems with the outline synchronization so far.

One small enhancement which I feel would make this feature even better would be the option to automatically collapse expanded sub-entries of the bookmark tree upon moving to the next section. I feel that this could improve navigation in larger PDFs with fine-grained TOCs by reducing some of the clutter that just naturally arises while reading through the document.

Is this idea something that is feasible with the current implementation of the outline synchronization?

Cheers
--Ari

[Ari (ari-lp)]

Another quick observation:

I don't know if this is related to the updated outline view or if it's just because I haven't used qpdfview for a while but I feel like the page number column is taking up more space than before.

Please take a look at the attached screencast. You will see that there is a pretty wide static horizontal gap between the page numbers and the right edge of the outline view. It looks as if the numbers are left-aligned. I think it would make more sense to align them right.

[Adam Reichold (adamreichold)]

Hello again,

Did you make the screencast using a current build of qpdfview's trunk?
Because I can't reproduce that spacing behavior. (In current builds, the
page column is set to resize according to its contents, so the alignment
shouldn't matter.)

Best regards, Adam.

Am 29.08.2013 07:05, schrieb Ari:
> Another quick observation:
>
> I don't know if this is related to the updated outline view or if it's
> just because I haven't used qpdfview for a while but I feel like the
> page number column is taking up more space than before.
>
> Please take a look at the attached screencast. You will see that there
> is a pretty wide static horizontal gap between the page numbers and the
> right edge of the outline view. It looks as if the numbers are left-
> aligned. I think it would make more sense to align them right.
>
> ** Attachment added: "screencast of outline column spacing + resizing behaviour"
> https://bugs.launchpad.net/qpdfview/+bug/1171820/+attachment/3792441/+files/screencast1.mp4
>

[Adam Reichold (adamreichold)]

Hello Ari,

Am 29.08.2013 06:40, schrieb Ari:
> Hey Adam,
>
> sorry for not getting back to you over the past couple of weeks. I was
> on holiday and didn't have access to my usual system. Now that I am back
> I will be able to report issues and other observations that arise form
> my daily usage of qpdfview.
>
> I am glad to say that far I haven't encountered any particular problems
> with the outline synchronization so far.
>
> One small enhancement which I feel would make this feature even better
> would be the option to automatically collapse expanded sub-entries of
> the bookmark tree upon moving to the next section. I feel that this
> could improve navigation in larger PDFs with fine-grained TOCs by
> reducing some of the clutter that just naturally arises while reading
> through the document.
>
> Is this idea something that is feasible with the current implementation
> of the outline synchronization?

I fiddled a bit and will continue to think about this, but in the
current state it doesn't really seem feasible since whether there is not
exactly matching page number in the outline, nothing would be expanded,
so the problem comes down to finding a lower bound instead of an exact
match again... As I said, I'll think about it.

> Cheers
> --Ari
>

Best regards, Adam.

[Ari (ari-lp)]

Hey Adam,

thanks again for the quick reply. Yes, the screencast was recorded with the latest qpdfview build (compiled today).

Maybe the behaviour is different because I am running a GTK-based desktop (as previously seen with the Qt tree view colouring)?

Cheers
--Ari

[Adam Reichold (adamreichold)]

Hello Ari,

Am 29.08.2013 21:45, schrieb Ari:
> Hey Adam,
>
> thanks again for the quick reply. Yes, the screencast was recorded with
> the latest qpdfview build (compiled today).
>
> Maybe the behaviour is different because I am running a GTK-based
> desktop (as previously seen with the Qt tree view colouring)?

I am not sure as this should affect the style and theme, but the
behavior of the layout to that degree. But I really don't know for sure.

In any case, maybe Benjamin could try to confirm this? Possibly by
comparing a GNOME and KDE environment? And if the issue can be
confirmed, this should be tracked by a different bug as it is a bit
off-topic here.

> Cheers
> --Ari
>

Best regards, Adam.

[Adam Reichold (adamreichold)]

Hello again,

I also think that I found a useful way of dealing with collapsing and expanding outline entries: If an entry is matched, its parents are expanded and everything else is collapsed. If there is no match, nothing is changed in the outline view. This was just pushed and should hit the daily builds soon.

Best regards, Adam.

[Benjamin Eltzner (b-eltzner)]

Hi,

my trial run yielded the following results:

debian unstable, 0.4.4 & xfce: correct sizing
kubuntu 12.04, 0.4.4 & kde: correct sizing
kubuntu 12.04, dailydebs & kde: wrong sizing as shown in the video
ubuntu 12.04, dailydebs & unity: wrong sizing as shown in the video

So this suggests a regression, possibly introduced with the default outline, that is not yet present in 0.4.4. (As an aside: Note that the empty space corresponds in width to the two buttons to detach or close the dock, so I suppose there is some relation here.)

Cheers, Benjamin

[Adam Reichold (adamreichold)]

Hello Benjamin,

Thanks for trying to nail this down! I found one regression w.r.t. the
fallback outline, i.e. the header layout not being adjusted if upon
open/refresh only a fallback outline is available. A fix should be part
of trunk revision 1238.

But the behavior in this case isn't really comparable to the screencast
and therefore I think there is something else going on. (But please test
whether this fixes your problem as well.)

Since I still can't reproduce the original problem, could you try to
give me a step by step procedure by which I could try to observe the
issue with the dock title bar elements? Thanks.

Best regards, Adam.

P.S.: The only other thing I can think of, is that I allowed for outline
and properties to be docked anywhere in the main window, not just left
and right. But that's pure guesswork until I can reproduce the problem...

Am 30.08.2013 16:05, schrieb Benjamin Eltzner:
> Hi,
>
> my trial run yielded the following results:
>
> debian unstable, 0.4.4 & xfce: correct sizing
> kubuntu 12.04, 0.4.4 & kde: correct sizing
> kubuntu 12.04, dailydebs & kde: wrong sizing as shown in the video
> ubuntu 12.04, dailydebs & unity: wrong sizing as shown in the video
>
> So this suggests a regression, possibly introduced with the default
> outline, that is not yet present in 0.4.4. (As an aside: Note that the
> empty space corresponds in width to the two buttons to detach or close
> the dock, so I suppose there is some relation here.)
>
> Cheers, Benjamin
>

[Benjamin Eltzner (b-eltzner)]

Hi,

the problem is apparently in the default spacing in the themes. In the current trunk (version 1241) the spacing ist set to zero, so no space should be wasted and the numbers are aligned to the right. Hopefully this is an acceptable state.

Cheers, Benjamin

[Ari (ari-lp)]

Hey Benjamin and Adam,

I am a bit late but I'd like to thank you both for working on this. The spacing is perfect now!

Cheers
-- Ari

[Ari (ari-lp)]

Ah, sorry for the duplicate comment but I forgot to mention that the automatic collapse/expand method is working great here as well. Fantastic work, Adam!