Bug 416716

Summary: Some dialogs are created off screen
Product: [Applications] krita Reporter: eleanorhawk
Component: GeneralAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED NOT A BUG    
Severity: normal CC: ghevan
Priority: NOR    
Version First Reported In: 4.2.8   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description eleanorhawk 2020-01-24 22:29:18 UTC
SUMMARY
When launched from the UI, some dialogs are created at the global screen coordinate 0,0 which on my system is completely off screen, making the dialog inaccessible.
I have observed this for the "Scale Image to New Size", "Resize Canvas", "Grow Selection", "Shrink Selection", "Feather Selection", and "Border Selection" dialogs. Other dialogs I have tried behave as expected.
STEPS TO REPRODUCE
1. Adjust screens (e.g., with xrandr) so that global coordinate 0,0 is off screen.
2. Launch one of the above dialogs

OBSERVED RESULT
The Krita UI will fade to gray but no dialog will be visible.
xwininfo -root -tree will confirm that the dialog has been created at 0,0

EXPECTED RESULT
The dialog would appear in an accessible part of the screen -- presumably near the center of the main Krita window

SOFTWARE/OS VERSIONS
Windows: N/A
macOS: N/A
Linux/KDE Plasma: Arch Linux, rolling, 4.19.97-1-lts Kernel
(available in About System)
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66.0
Qt Version: 5.14.0

ADDITIONAL INFORMATION
wmctrl is able to move the dialog onto the screen and except for its placement everything else seems to be fine about its behavior. I have been using this hacky bash script as a work-around:
while IFS= read -r window; do
    wmctrl -r ${window} -e 0,0,733,-1,-1
done <<<"$(xwininfo -tree -root | grep -oP "(?<=\\\").*?Krita.*?(?=\\\")")"

Renaming my $HOME/.config/kritarc file or $HOME/.local/share/krita directory did not affect the issue

I expect it is possible in xorg to place a screen at an arbitrary offset from the global coordinates, but I do not know how practical this would be with the more modern and intelligent screen adjustment tools. My system is in this (admittedly unusual) state because I have two monitors side-by-side, with the left screen about 700 pixels lower than the right one.
Comment 1 vanyossi 2020-01-25 02:10:19 UTC
Hi, do you adjust screens [Adjust screens (e.g., with xrandr)] while krita is open?

We usually can't do anything about window placement as that is decided by your window management and possibly Qt.
Comment 2 eleanorhawk 2020-01-26 22:36:02 UTC
(In reply to vanyossi from comment #1)
> Hi, do you adjust screens [Adjust screens (e.g., with xrandr)] while krita
> is open?

No, I don't adjust the screens while Krita is open -- I simply mentioned that as an example

> We usually can't do anything about window placement as that is decided by
> your window management and possibly Qt.

This problem seems to have emerged sometime since Krita 4.1.5. I've previously been using the Appimage of that version, which did not (and still does not) exhibit this behavior. I switched to the Arch package about a week ago, which is where I noticed this.

As a test, I have downloaded the 4.2.8 Appimage. It behaves the same as the Arch package in this regard.
Comment 3 Bug Janitor Service 2020-01-27 04:33:20 UTC
Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.
Comment 4 vanyossi 2020-01-30 21:42:22 UTC
Do you happen to know the Qt version you have installed? Arch repos tend to have recent versions of software. Since we have no control of where the Windows will be placed, that is decided by the window manager, Im inclined to think you have a Qt version >=5.13 which are known to be buggy. For krita we stick with 5.12.4 for the moment.

I will mark as not a bug.
Comment 5 eleanorhawk 2020-02-04 07:54:26 UTC
(In reply to vanyossi from comment #4)
> Do you happen to know the Qt version you have installed? Arch repos tend to
> have recent versions of software. Since we have no control of where the
> Windows will be placed, that is decided by the window manager, Im inclined
> to think you have a Qt version >=5.13 which are known to be buggy. For krita
> we stick with 5.12.4 for the moment.
> 
> I will mark as not a bug.

I mentioned this behavior occurs with the Krita Appimage, which is linked against Qt 5.12.5

$ ./krita-4.2.8-x86_64.appimage --appimage-extract
$ strings squashfs-root/usr/lib/libQt5Core.so.5 | grep "QtCore library version"
This is the QtCore library version Qt 5.12.5 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 5.5.0 20171010)