| Summary: | Cannot re-enable locked but hidden dockers | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Autumn Lansing <autumn> |
| Component: | Dockers | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alvin |
| Priority: | NOR | ||
| Version: | 4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/krita/b5e64be625958ca359dbc0f9935a91fff6f090b0 | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Autumn Lansing
2018-03-23 15:07:53 UTC
I think that happens when you locked a docker and somehow managed to close it/make it hidden. There seems to be no way to simply re-enable it or toggle its visibility. You can try switching workspaces and find a workspace with the docker visible and then unlock it though. Another way would be to edit the kritarc file and replace `Locked=true` with `Locked=false` under all the docker sections (For those dockers that are still visible but greyed out in the menu, click on the lock icon on the title bar of the docker to unlock it.) I would suggest to implement a function to unlock all the dockers to prevent users from getting stuck in this situation. Ah, yes. I was able to unlock it through another workspace and realized that the official release had started me in a different workspace than I normally use. There was no visual information to make me think that though, and the beta version had not done it, hence my confusion. Yes, an emergency unlocking mechanism might be helpful. Git commit 52c0f20f60afe97568609bb161170bae98757aa2 by Boudewijn Rempt. Committed on 28/03/2018 at 13:39. Pushed by rempt into branch 'master'. On switching a workspace unlock all dockers The workspace selector widget tried to restore the lock status after changing a workspace for all visible dockers, the workspace menu didn't do that. In any case, it is far too easy to lock invisible dockers, and that confuses far too many people and takes far too much of our time to explain. Tt is better to define that changing a workspace will reset the lockedness of all dockers. The lock property of a docker is not part of the workspace. CCMAIL:kimageshop@kde.org Maybe we should remove the lock and collapse feature for dockers altogether. M +1 -1 libs/ui/KisApplication.cpp M +12 -7 libs/ui/KisMainWindow.cpp M +3 -3 libs/ui/KisMainWindow.h M +1 -20 libs/ui/widgets/kis_workspace_chooser.cpp https://commits.kde.org/krita/52c0f20f60afe97568609bb161170bae98757aa2 Git commit b5e64be625958ca359dbc0f9935a91fff6f090b0 by Boudewijn Rempt. Committed on 03/04/2018 at 11:18. Pushed by rempt into branch 'krita/4.0'. On switching a workspace unlock all dockers The workspace selector widget tried to restore the lock status after changing a workspace for all visible dockers, the workspace menu didn't do that. In any case, it is far too easy to lock invisible dockers, and that confuses far too many people and takes far too much of our time to explain. Tt is better to define that changing a workspace will reset the lockedness of all dockers. The lock property of a docker is not part of the workspace. CCMAIL:kimageshop@kde.org Maybe we should remove the lock and collapse feature for dockers altogether. (cherry picked from commit 52c0f20f60afe97568609bb161170bae98757aa2) M +1 -1 libs/ui/KisApplication.cpp M +12 -7 libs/ui/KisMainWindow.cpp M +3 -3 libs/ui/KisMainWindow.h M +1 -20 libs/ui/widgets/kis_workspace_chooser.cpp https://commits.kde.org/krita/b5e64be625958ca359dbc0f9935a91fff6f090b0 |