SUMMARY This bug happens on all recent nightly appimages (during May as far as I can tell) but did not happen with version 4.1.7 or with the Feb 21st 4.2.0-pre-alpha. When editing text, the text editing window is drawn below/behind any floating dockers. This is inconvenient if you have lots of floating dockers on a second monitor. STEPS TO REPRODUCE As stated above OBSERVED RESULT As stated above EXPECTED RESULT It should be on top of floating docker, as it used to be. SOFTWARE/OS VERSIONS Krita Version: 4.2.0-beta (git 45bdec0) Languages: en_GB, en Hidpi: true Qt Version (compiled): 5.12.2 Version (loaded): 5.12.2 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.9.0-9-amd64 Pretty Productname: Debian GNU/Linux 9 (stretch) Product Type: debian Product Version: 9 ADDITIONAL INFORMATION
I made that change. The idea is to have the text tool open like modal window and edit the text more readily. I did try the text tool over all, but the problem was that if I made it a tool window it would loose the menu. Maybe I missed something to make it also go above the tool windows.
Git commit cd4d6453dac73d9d0851e7b2f63589bf0824fc82 by Ivan Yossi. Committed on 24/05/2019 at 04:42. Pushed by ivany into branch 'master'. Re-enable svgTextTool as a modal window It has to be this way to avoid being covered by tool windows, and before changing to nonModal as Tool window, a workaround for shortcuts must be made. As a Tool window the menu is not shown, making some edition options unavailable. BACKPORT:krita/4.2 M +1 -1 plugins/tools/svgtexttool/SvgTextTool.cpp https://invent.kde.org/kde/krita/commit/cd4d6453dac73d9d0851e7b2f63589bf0824fc82
Hi, Ivan! It is also might be not very safe to have this window not-modal, because the user can delete the source layer with the text shape and the editor will keep a dangling pointer. For such cases we usually have use KisImage's sigStrokeCancellationRequested() and sigStrokeEndRequested().
Please also check a comment here: https://invent.kde.org/kde/krita/commit/cd4d6453dac73d9d0851e7b2f63589bf0824fc82#note_6274
Git commit 375384414368b4bbd65d734f9f7d7cd7c48ef05f by Boudewijn Rempt, on behalf of Ivan Yossi. Committed on 24/05/2019 at 10:17. Pushed by rempt into branch 'krita/4.2'. Re-enable svgTextTool as a modal window It has to be this way to avoid being covered by tool windows, and before changing to nonModal as Tool window, a workaround for shortcuts must be made. As a Tool window the menu is not shown, making some edition options unavailable. BACKPORT:krita/4.2 (cherry picked from commit cd4d6453dac73d9d0851e7b2f63589bf0824fc82) M +1 -1 plugins/tools/svgtexttool/SvgTextTool.cpp https://invent.kde.org/kde/krita/commit/375384414368b4bbd65d734f9f7d7cd7c48ef05f
Ive just tried Build #493 krita-4.2.0-beta-974cf7b-x86_64.appimage and Build #494 krita-4.2.0-beta-75df7cc-x86_64.appimage. In both of them, the text editor window is still under/behind floating dockers. This is obviously a complicated problem and it's an inconvenience rather that a funtion breaker. I'll be happy if it gets fixed one day :)
So now it goes below floating dockers but also blocks event in the main window? because the type of window shows on top of everything (at least on macOS) It's not diffcult, it probably means that setting a "parent" to the application still makes the dockers on top on some platforms. Let me test the changes on Linux and see how it behaves there.
Quick note: Windows 10 doesn't show this problem but Debian 9, Debian 10 and Linux Mint 18.3 do show it. (I don't know what you mean by "blocks event in the main window" but if I was using the text editing window, I wouldn't be interested in anything else until I'd done Save then Close.)