The non-browse tools (zoom, select, etc.) don't work if any tab in the window is in review mode. Normally, a single tab will enforce the mutual exclusivity of review mode and non-browse tools. But there is some kind of interaction between tabs that causes all tools in all tabs to behave as a browse tool without properly reflecting this in the GUI. I'm happy to fix this but it may be over a month before I have time to do so. Reproducible: Always Steps to Reproduce: 1. Open two documents in tabs 2. Enter review mode in doc 1. (At this point, doc 1 will enforce the use of browse tool.) 3. Switch to doc 2 and try to use the zoom tool (or any other tool). Actual Results: The zoom tool will be selected in the GUI and the corresponding tooltip will show, but in fact the browse tool is still active. Expected Results: Each tab should be allowed to use different tools, regardless of whether other tabs are in review mode.
:/ This is bad :/
Jonathan any chance we can get a fix for this for 4.14.0 (tagging in one week)?
I took some time to look at this and I'm not sure how to fix it. The problem is that changing the mouse mode writes the global Settings, which triggers all the Parts to reload (and potentially overwrite) the Settings. We could: 1. Don't watch for the Settings::configChanged signal. This is my preference, as I wouldn't expect the program to reload settings whenever the config file is written to. 2. Don't constantly write settings to disk. Most Settings mutations are followed by a writeConfig(), which seems unnecessary to me. Why not just writeConfig() once when the program is exiting? 3. Remove MouseMode as a global setting. Why not just always start the program in Browse mode? I would ultimately prefer to get rid of all persistent, implicit settings and make everything non-configurable or explicitly configurable because I don't think there's an intuitive way to resolve settings when multiple program instances are simultaneously altering them.
1 + 2: Because it's what we use to pass around the settings change, you write the setting and then rely on slotNewConfig to set everything correctly, if you remove slotNewConfig and writeConfig you're going to need to rewrite lots of stuff. 3. Because people asked for that feature ;) People is going to hate you if you remove the features they love and use ;)
And yes i realize i didn't give you a solution, i guess you can always store the mouse mode in that struct you added per tab and set it from there when changing tabs?
So I tested an older version (tag v4.10.97) and this bug exists for multiple windows as well. It's probably been around forever. And there are similar bugs for other settings like continuous view mode. Basically I think the global Settings object is very inadequate for how it's used, and should be re-architected. I guess I'll keep trying to find a short term solution, though.
Git commit b069e3557f995b3759a505160e3f009e2267506c by Albert Astals Cid, on behalf of Jonathan Doman. Committed on 10/12/2014 at 14:33. Pushed by aacid into branch 'Applications/14.12'. Allow each PageView to use a different tool Keep a local MouseMode setting, and don't rely on the value returned by Settings::mouseMode(). REVIEW: 120660 FIXED-IN: 14.12.0 M +25 -17 ui/pageview.cpp http://commits.kde.org/okular/b069e3557f995b3759a505160e3f009e2267506c