2 feature requests (Remember position/edit toolbars)

Hello Anders,

Concerning your feature requests:

ad 1: I'd say this basically comes to implementing "per-file settings". I do agree that it could be a useful feature and will consider it for the next release. (We are currently stabilizing for the release of version 0.3.6.) I was/am reluctant to do this because of littering this user's system with yet another form of history mechanism. So if it is done, then disabled by default. (If you'd like to influence the design and implementation of such a feature, you could join the project driver team at "https://launchpad.net/~qpdfview" and use its mailing list.)

ad 2: This should already be possible even though it is not done in graphical way: There are three settings for the tool bars which contain a comma-separated list of actions to display (including their ordering). The actions available in each tool bar are documented in the online help.

ad 3: I think it should be possible to add an "expand/collapse all" action to the context menu of the outline view. Should have nearly the same effect without introducing an new setting. What do you think?

ad 3: Ok, context menu actions to expand/collapse all entries in the outline view just hit trunk and should be in the daily builds soon. Testing and feedback whether this alleviates the problem would be appreciated.

By the way, concerning "In lieu of same, [...]": Logically, the outline is just a list of links and while one could try to infer the "sections" of the document by that this is no way guaranteed to be correct. Hence we do not track which outline entry is currently visible because this notion does not really exist in a PDF document. So, things will probably stay as they are in this regard.

Wow, that is a lot of progress in half a day! :)

I went ahead and pulled in the persistent state branch. So far, it works like a charm, as does the "collapse/expand" entry. Great stuff.

Ad: "In lieu of same, [...]": I assumed there was some sort of keeping tab happening, given that evince exhibits this behaviour of linking pages and outline links. Either way, it's fairly trivial in comparison to pages perstisting.

Ad 2: Do you have a link for the documentation on actions available? /usr/share/qpdfview/help.html doesn't have it and I can't find additional help files here or via google.

Ad "In lieu of same, [...]"; It is possible by sorting the outline entries by page/position and using that to cut the document into sections. But that is an interpretation of the outline data that is based on additional assumptions.

Ad 2: It should be in this file. In the section "Settings" subsection "Interface settings". The settings are called "File tool bar", "Edit tool bar" and "View tool bar". The lists of available actions are part of their descriptions. (As mentioned, this is not a very comfortable mechanism, but it works with a minimal amount of code.)

Ad 1: Nice to know that it works for at least two people. Do you notice that small lag when opening or closing tabs? Maybe it is my SQLite driver/configuration that needs to be modified.

Ad2: Ah, my scan and search-fu was just looking for the wrong keywords. Thanks.

ad1: No discernible lag here. And my pc is sufficiently middle-of-the-line that lag creeping in ought to be discernible. It opens close to instantaneously with large and small files alike.

Ok, just to polish it up a bit, I added the setting for keeping the persistent state, defaulting to off, to the 'persistentstate' branch. The corresponding table is now also limited to the latest 1000 rows. (This number is obviously open to debate.) This changes the database scheme, so you have to delete "~/.config/qpdfview/persistentstate.db" for it to be recreated correctly and enable the setting using the settings dialog (on the "behavior" tab).

If nobody finds something seriously wrong with this, I'd say it will enter trunk in about two weeks. (That is right after version 0.3.6 is released.)

This code now lives in the branch "lp:~adamreichold/qpdfview/database" after a lot of refractoring and reimplementing all persistence functionality using SQLite.

Hmm, I have hit a snag with the new branch. My compile-fu isn't terribly strong, but it wasn't originally too difficult to change the PKGBUILD (I use Arch Linux) from compiling from trunk to pull in the persistentstate branch.

I figured that simply changing "persistentstate" to "database" would pull in the new branch, but now I am getting:

bzr: ERROR: These branches have diverged. Use the missing command to see how.
Use the merge command to reconcile them.

What's different between the two branches?

Hello Anders,

This is just Bazaar getting confused because you have not cleaned up the build directory before trying to pull the new branch. Everything should be fine after deleting the "src" and "pkg" directories.

(The thing is that both branch are based on trunk, hence "database" is not a continuation of "persistentstate" but rather a rewrite of that the complete persistence functionality. I just reconsidered my options and started again.)

Ah. Problem solved. Thanks. :)

Good work, comrade Adam Reichold. The feature 'remember position' is must have for any PDF viewer program.