How to open qpdfview without restoring (big and crashy *.pdf)?

Hi,
just to add a comment: in
$HOME/.config/qpdfview/qpdfview.conf
one finds the lines
...
restoreTabs=true
...
recentlyUsed=COMMA_SEPARATED_LIST_OF_EPIC_LENGTH
...

I would have expected that changing these lines takes effect when opening qpdfview the next time. However, on my system (Debian unstable KDE) this is not the case. E.g. setting restoreTabs=false did only take effect, after I opened qpdfview, closed it and reopened it. The same goes for the recentlyUsed list, only if I open qpdfview, it will first not recognize the changed setting, restore all files and thus repopulate the recentlyUsed list on closing.

Is this expected behavior, Adam?

Hello,

a quick and dirty way would be to use that restore tabs depends on the instance name, i.e. just request a different instance name for which no tabs will be restored by running "qpdfview --unique --instance foobar". Benjamin's suggestion should be the correct one, but I could reproduce the strange behavior he observed. I'll have a look at it and report back here.

Best regards, Adam.

Hello again,

it's a bug, deactivating the restore tabs/bookmarks function only works because we're diligent enough to clear the database if the setting is disabled, but we actually never check this before restoring on start-up (which would then find an empty database on the second start of the program and hence seem to work). The fix is part of trunk revision 1543. Benjamin, could you grab it and try it out to check whether I missed anything? Thanks!

Best regards, Adam.

P.S.: The recently used list is not controlled by the list setting itself, but rather by the "trackRecentlyUsed" Boolean setting.

Hi,

I tested the new dailydeb and changing restoreTabs in qpdfview.conf now works as expected. However, the list of files which are restored is apparently not stored in the conf-file, so it is not possible to just eliminate a single file from the list of files to restore. Is this due to the fact that such a list would exist for every instance name and a text file is not a suitable database? (Because this sounds like a reasonable point to me.)

Thank you for the quick fix.
Cheers, Benjamin

Hello Benjamin,

the main reasons for tabs, bookmarks and per-file settings being stored in a database instead of a configuration file are that there could be a unlimited number of them and more importantly that they are not just a list of values, but rather a list of entries with several properties. For example to restore a tab, you need to know the file path, the current page, the scale mode and factor etc. And a list of entries with several properties is pretty a much a table. Anyway, you can very much remove a single tab by using the sqlite command-line tool to edit the database whose format is hopefully self-explanatory. (E.g. just use the "DELETE" SQL command to remove a specific entry of the "tabs_v2" table.)

Best regards, Adam.

Consider the original question solved from my point of view given a number of workarounds.

Related comment, possibly worth posting separately/differently (?):

Maybe due to a recent (qdfview) update, maybe due to the weather, but most probably not due to Linux I've started to have trouble with various random *.pdf files (size < 500kb) within qpdfview and qpdfview only. Haven't quite figured out the trigger yet, but it may be related to attempts of resizing (e.g. ctrl 8), maybe not. Seems unrelated to the type and size of *.pdf, though. Any ideas, or is this too unhelpful?

Hello,

I would not say unhelpful, but rahter unspecific. With problems you mean that the program crashes? Is it reprocible like using one of those files and trying 50 times will usually trigger the problem? Is there any output if run qpdfview from a terminal? If so, this smells like a bug report to me. Otherwise I am not sure whether I can pinpoint the problem acurately enough to fix it.

Best regards, Adam.