Smoothing buttons added to the "File" or "Brushes and Stuff" toolbars don't appear again after closing Krita. Reproduced on: Krita 2.9.11 on Windows 8.1 Krita 3.0 portable on Windows 8.1 Krita 2.9.7 (official Ubuntu package) on KDE Neon 5.7 Krita 3.0 (appimage) on KDE Neon 5.7 Reproducible: Always Steps to Reproduce: 1. Go to Settings -> Configure Toolbars 2. Add "Brush Smoothing: Basic" and "Brush Smoothing: Disabled" to the "File" or "Brushes and Stuff" toolbar 3. Close Krita 4. Open Krita again Actual Results: The buttons aren't visible anymore. Expected Results: The buttons should stay visible at the position the user left them.
*** Bug 365225 has been marked as a duplicate of this bug. ***
This one I cannot reproduce on ubuntu 16.04
@wolthera are you using the most recent versions? Maybe 2.9.7 comes from the KDE Neon repository, not Canonical's. Try it on 3.0 too.
anewuser: I am one of the developers, I run versions of Krita that aren't out yet.
Created attachment 99974 [details] Screencast showing bug Krita 2.9.7 KDE Neon 5.7
I made the above video to show you what happens when I do it. The other user who told me about this problem has a completely different laptop and runs Windows. The terminal output, if relevant: Legacy integer arithmetics implementation connect failed: No such file or directory WARNING: KisImageConfig: requested config synchronization from nonGUI thread! Skipping... OpenGL version 1.1 or higher is present. OpenGL version 1.2 or higher is present. OpenGL version 1.3 or higher is present. OpenGL version 1.4 or higher is present. OpenGL version 1.5 or higher is present. OpenGL version 2.0 or higher is present. OpenGL version 2.1 or higher is present. krita(21289)/koffice (lib komain) KoRuler::createGuideToolConnection: No guides tool found, skipping connection krita(21289)/koffice (lib komain) KoRuler::createGuideToolConnection: No guides tool found, skipping connection krita(21289) CanvasData::activateToolActions: "InteractionTool" : action "object_order_raise" conflicts with canvas action "rotate_canvas_right" shortcut: "Ctrl+]" krita(21289) CanvasData::activateToolActions: "InteractionTool" : action "object_order_lower" conflicts with canvas action "rotate_canvas_left" shortcut: "Ctrl+[" krita(21289) CanvasData::activateToolActions: "InteractionTool" : action "object_order_raise" conflicts with canvas action "rotate_canvas_right" shortcut: "Ctrl+]" krita(21289) CanvasData::activateToolActions: "InteractionTool" : action "object_order_lower" conflicts with canvas action "rotate_canvas_left" shortcut: "Ctrl+[" QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current. QGLContext::makeCurrent(): Cannot make invalid context current.
I can reproduce this with git master. Some actions, like about krita, are saved correctly, but specifically the smoothing actions (and I bet other actions that come from plugins) don't get saved correctly. I though that Michael had fixed all those issues, but apparently not. Any information about 2.9.x is not relevant, btw, those versions have been superceded by 3.x.
I also encounter this consisently on windows version of krita 3.0
this is potentially a duplicate of this bug? https://bugs.kde.org/show_bug.cgi?id=344907
@Bollebib, since this doesn't happen to all buttons/options, please don't close either bug report. Mine is about other options and has been confirmed in the most recent version of Krita.
just as an update this still seems to be an issue
(I can confirm this with "Krita 4.0.0-beta1.1.appimage" on Ubuntu 14.04)
Exactly the same symptoms, I only saw this the time the beta came out, (I'm on the git-master) removing krita.xmlgui (I should had removed it earlier though) and krita4.xmlgui to start anew, fixed the problem since.
*** Bug 389317 has been marked as a duplicate of this bug. ***
I'm on 4.0.0 and Windows 10 and this is still happening. Are there any plans to iron out this bug? It's rather frustrating to have to re-configure the window every time I restart the program.
I think I've spend about 80 hours trying to figure out how to fix this bug, but I haven't succeeded yet.
*** Bug 395433 has been marked as a duplicate of this bug. ***
*** Bug 399817 has been marked as a duplicate of this bug. ***
I can confirm this on 4.1.5 (Win10)
yeah this bug has been up for 2 years and really hate that I have to press re apply every time i open krita.
I know... I'm sorry, but I just haven't had time to finish the work Michael started on making all actions available on Krita on startup, instead of having some only be created when there's an image open.
Git commit 5f91230f074be53379ba1461c6a1560d1f8aa1eb by Boudewijn Rempt. Committed on 29/11/2018 at 13:24. Pushed by rempt into branch 'master'. add a createActions method to KoToolFactoryBase Actions created by a tool instance only exist if there's an open document, which means they cannot be configured or placed in toolbars. We should only have per-window actions, not per-action actions. Creating the actions in the toolfactory instead of the tool when the window is created fixes that: now the tools will retrieve the actions from the global action collection on activations and de-activation, like the freehand tool already did for increase and decrease brush size. Note: this commit breaks the following tools because it's not worth porting hidden tools in any case: * artistic text tool * odf text tool * connection tool CMAIL:kimageshop@kde.org M +0 -12 krita/kritamenu.action M +0 -3 libs/flake/KoCanvasController.cpp M +3 -3 libs/flake/KoCanvasController.h M +2 -58 libs/flake/KoToolBase.cpp M +0 -19 libs/flake/KoToolBase.h M +0 -1 libs/flake/KoToolBase_p.h M +94 -3 libs/flake/KoToolFactoryBase.cpp M +22 -0 libs/flake/KoToolFactoryBase.h M +84 -121 libs/flake/KoToolManager.cpp M +0 -3 libs/flake/KoToolManager.h M +49 -59 libs/flake/tools/KoPathTool.cpp M +2 -1 libs/flake/tools/KoPathTool.h M +22 -0 libs/flake/tools/KoPathToolFactory.cpp M +1 -0 libs/flake/tools/KoPathToolFactory.h M +3 -1 libs/ui/CMakeLists.txt M +21 -19 libs/ui/KisMainWindow.cpp M +1 -5 libs/ui/KisPart.cpp A +64 -0 libs/ui/tool/KisSelectionToolFactoryBase.cpp [License: LGPL (v2+)] A +44 -0 libs/ui/tool/KisSelectionToolFactoryBase.h [License: LGPL (v2+)] A +54 -0 libs/ui/tool/KisToolPaintFactoryBase.cpp [License: LGPL (v2+)] A +35 -0 libs/ui/tool/KisToolPaintFactoryBase.h [License: LGPL (v2+)] M +0 -17 libs/ui/tool/kis_tool_paint.cc M +0 -3 libs/ui/tool/kis_tool_polyline_base.cpp M +9 -33 libs/ui/tool/kis_tool_select_base.h M +4 -3 libs/ui/tool/kis_tool_shape.h M +2 -1 libs/widgetutils/kis_action_registry.cpp M +1 -1 libs/widgetutils/kis_action_registry.h M +3 -3 libs/widgetutils/xmlgui/kactionconflictdetector.cpp M +2 -2 plugins/assistants/Assistants/kis_assistant_tool.cc M +11 -11 plugins/flake/artistictextshape/ArtisticTextTool.cpp M +57 -57 plugins/flake/textshape/TextTool.cpp M +40 -36 plugins/tools/basictools/kis_tool_brush.cc M +18 -16 plugins/tools/basictools/kis_tool_brush.h M +3 -4 plugins/tools/basictools/kis_tool_ellipse.h M +3 -3 plugins/tools/basictools/kis_tool_fill.h M +3 -3 plugins/tools/basictools/kis_tool_gradient.h M +82 -45 plugins/tools/basictools/kis_tool_move.cc M +8 -7 plugins/tools/basictools/kis_tool_move.h M +1 -1 plugins/tools/basictools/kis_tool_multihand.cpp M +2 -3 plugins/tools/basictools/kis_tool_multihand.h M +3 -3 plugins/tools/basictools/kis_tool_rectangle.h M +15 -15 plugins/tools/defaulttool/connectionTool/ConnectionTool.cpp M +86 -73 plugins/tools/defaulttool/defaulttool/DefaultTool.cpp M +6 -0 plugins/tools/defaulttool/defaulttool/DefaultTool.h M +47 -0 plugins/tools/defaulttool/defaulttool/DefaultToolFactory.cpp M +2 -0 plugins/tools/defaulttool/defaulttool/DefaultToolFactory.h M +25 -0 plugins/tools/defaulttool/referenceimagestool/ToolReferenceImages.cpp M +5 -2 plugins/tools/defaulttool/referenceimagestool/ToolReferenceImages.h M +1 -0 plugins/tools/karbonplugins/tools/CMakeLists.txt A +46 -0 plugins/tools/karbonplugins/tools/CalligraphyTool/KarbonCalligraphyTool.action M +41 -37 plugins/tools/karbonplugins/tools/CalligraphyTool/KarbonCalligraphyTool.cpp M +4 -0 plugins/tools/karbonplugins/tools/CalligraphyTool/KarbonCalligraphyTool.h M +14 -0 plugins/tools/karbonplugins/tools/CalligraphyTool/KarbonCalligraphyToolFactory.cpp M +2 -0 plugins/tools/karbonplugins/tools/CalligraphyTool/KarbonCalligraphyToolFactory.h M +2 -3 plugins/tools/tool_dyna/kis_tool_dyna.cpp M +4 -7 plugins/tools/tool_dyna/kis_tool_dyna.h M +3 -3 plugins/tools/tool_lazybrush/kis_tool_lazy_brush.h M +2 -2 plugins/tools/tool_polygon/kis_tool_polygon.h M +2 -2 plugins/tools/tool_polyline/kis_tool_polyline.h M +3 -3 plugins/tools/tool_smart_patch/kis_tool_smart_patch.h https://commits.kde.org/krita/5f91230f074be53379ba1461c6a1560d1f8aa1eb
It works! :) Thank you for a lot of work fixing this bug.
Reopening. I'm sorry after re-checking it seems that creating a new keyboard shortcut scheme and restarting disables the toolbar buttons (thanks Storm-Engineer) Setting the "Default" keyboard shortcuts scheme back solves the problem.
I've just tried the 4.2.0 pre-alpha (5f91230) appimage on Debian 9 with brush smoothing buttons added and they stay in place after a restart. I also created a new keyboard shortcut scheme (and added a new shorcut) and this did not remove the added buttons after a restart (as indicated in Comment 25). Running a previous 4.2.0 pre-alpha removed the buttons, as might be expected.
(In reply to Ahab Greybeard from comment #26) > they stay in place after a restart. Hi Ahab, yes, the buttons stay in place now but then if I try to: 1. create and set a new keyboard shortcuts scheme 2. restart Krita the whole toolbar don't respond anymore. Setting the "Default" keyboard shortcuts scheme back and restarting, will render the toolbar usable again.
(In reply to mvowada from comment #27) > (In reply to Ahab Greybeard from comment #26) > the whole toolbar don't respond anymore *doesn't To be precise, here only the "BrushesAndStuff" toolbar *default* buttons won't respond. The "mainToolBar" buttons and buttons added by users (to both the toolbars), will work.
Git commit 0e5eb2d78a39088c70d5fb38366ea319c60ad1a6 by Boudewijn Rempt. Committed on 30/11/2018 at 09:03. Pushed by rempt into branch 'master'. Loading custom shortcuts sets the shortcuts for actions that are stripped of their default shortcuts to "", an empty string. This means that the shortcut is not empty, so the logic that checks for duplicate shortcuts that need to be disabled when a tool overrides the global shortcuts thinks that all actions with a "" shortcut need to be disabled. M +10 -7 libs/flake/KoToolManager.cpp https://commits.kde.org/krita/0e5eb2d78a39088c70d5fb38366ea319c60ad1a6
(In reply to mvowada re. Comment 27 and Comment 28) Hi mvowada, Yes, that was poor comprehension and observation by me. I confirm your Comments 25, 27, 28.