Okular saves viewing properties for a document on exit, for example the viewed page or the zoom factor. When the document is opened again, the view is restored. However, whether okular shows a document in continuous mode or not is not saved per document. Reproducible: Always Steps to Reproduce: 1. View document A (a presentation) in non-continuous mode. 2. Close document A. 3. Open document B (a paper) 4. Switch continuous mode on. 5. Close document B. 6. Open document A again. Actual Results: Document A is displayed in continuous mode. Expected Results: Document A is displayed in non-continuous mode.
If someone could point me into the right direction I would be willing to look into this. It can't be too hard :-)
Download the code, compile it, and run it, then use "grep" to find where most probably you would want to have a look (by grepping by something visible in the UI) and then when you're lost ask again. On the other hand, i'm not still sure we want the continuous mode saved per document, but i am not unsure either, so if you can provide a patch i guess it'll be easier to convince me.
I totally agree, that this would be a cool features, as I think others might think, as well. There exist numerous bugreports regarding this particular feature or another view feature (such as 2page-facing): https://bugs.kde.org/show_bug.cgi?id=295506 https://bugs.kde.org/show_bug.cgi?id=309808 https://bugs.kde.org/show_bug.cgi?id=200183 @t0mplar: Did you make any progress on this? Cheers Felix
After some code browsing, I guess the following solution should work: DocumentPrivate::loadViewsInfo seems to be a good starting point as it's the xml parser. Following the function calls you end up in PageView::setCapability where you could implement another switch case and then add another function to pageview analog to the PageView::updateZoom function that handles other view features. Of course DocumentPrivate::saveViewsInfo needs to be adjusted, too. I didn't look at the process pipeline there, but that should be rather simple, I guess, since that's only grabbing available data and sending it to the XML-writer. Basically, I think it's not too much work, so the main question is: Is there a chance that this gets merged? Albert wasn't so clear about that ;) @t0mplar: Would you like to implement this? Otherwise tell me then I'll try to find some time.
That sounds like you got a lot farther than I did :-) I looked into the code a bit but didn't find the right spot to jump in (probably due to my incompetence when it comes to C++). At the moment I don't have time to implement this feature, but if you do, I would gladly help testing it. I hope that we can get this new feature merged, because for me it's the only one missing to make okular the perfect document viewer :-)
Created attachment 92103 [details] patch to solve the issue I've made a first solution. Some things might be a bit hacky such as changing the UI manually and calling the slots manually. Is there a better way to do this?
Please use reviewboard.kde.org for patches
I've created a review request (#123427 ) about two weeks ago, however there was no reaction to it. Should I provide anything else?
A 36h day :D Or some more reviewers on Okular code.
Is there anything I can do to make this patch land in master? Unfortunately, 36h days are currently out of stock, but I would volunteer to work on the patch if somebody tells me what precisely remains to be done.