I have been putting the documentation button on my toolbars more often now that the toolview doesn't restore itself anymore at startup (and I've begun working on a QTextBrowser backend). Sadly, not all issues with the toolview's behaviour have been resolved, at least not on Mac: - sessions where the documentation button is left on a toolbar will reopen with the documentation toolview in docked mode or in detached mode, seemingly at random; the toolview will sometimes also open without asking. - moving the floating window to dock it tends to provoke a crash in the cocoa QPA (but not when I use the X11/XCB QPA). I've only seen this on Mac, but given how I cannot seem to figure out how to prevent the toolview from using an unwanted floating window mode I'm not very keen on causing the same problem on my Linux system.
Please help to make bug reports useful and tell how to reproduce your problem. E.g. by creating a new session and trying to find out the steps needed which trigger the bug you need and then document them here. Sadly the title "documentation viewer docking behaviour" also is anything but useful, please consider updating it. Please make the crash "moving the floating window to dock" a separate bug report, that is a different problem and needs to be trackied separately.
Sadly I have no idea how to reproduce the issue. What I think happens is this: - I undocked the documentation window in one of my sessions sometime in the past and there are two related issues: 1 The documentation window will open when it shouldn't when I open a session that was closed with the documentation window hidden (closed) 2 The documentation window will open in floating or in docked mode (either when it auto-opens or when I open it myself) in a session in which I only used docked mode. To me this reeks of cross-talk between session settings for the documentation toolview, probably combined with an influence of the order in which something is being loaded or restored. I haven't been able to figure out where the two state settings are stored so cannot verify if removing all those settings makes the issue go away. I ran into this issue when restarting a test session repeatedly after rebuilding the documentation library. I kept the session open that has the KDevelop project, and didn't launch any other sessions. Sometimes I'd see the floating documentation window pop up and then disappear again, supporting the idea this has to do with restoring (the wrong) state.
An additional observation (unique hence anecdotal for now): 3 The documentation window opened automatically in floating mode when I closed a source document. I had used the context help "Show Documentation for QFoo" action, this opened a docked documentation window which I had closed by clicking on the toolbar "Documentation" button. 4 The floating window remained empty and I could only restore normal operation by removing the Documentation button from the toolbar and restoring it afterwards. I have seen that last issue before, but only when the floating window opens out uninvitedly so I think it's related.
One more observation, and this one is reproducible on Mac AND Linux: 1. Add the "Documentation" toolview to a toolbar (no need to open and use it). Close the documentation toolview if it was already open. 2. Use e.g. Git/Show Differences to launch the patchreview toolview. Don't use the documentation toolview. 3. Exit from the patchreview toolview (Finish button) You'd expect the toolview to remain closed. It doesn't, for me, it reopens systematically until I remove the toolview button from the toolbar.
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!