Bug 412393 - Scale Image dialogue pops up on the wrong screen when crop/transform was used before
Summary: Scale Image dialogue pops up on the wrong screen when crop/transform was used...
Status: REPORTED
Alias: None
Product: krita
Classification: Unclassified
Component: General (show other bugs)
Version: 4.2.7-beta1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2019-09-27 08:54 UTC by Tyson Tan
Modified: 2019-09-29 08:36 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tyson Tan 2019-09-27 08:54:30 UTC
I'm using a dual monitor setup, the screens are arranged vertically:
[DP2-Dell]
[DP3-Cintiq]

Normally, when I use Menu -> Image -> Scale Image to New Size (assigned to Ctrl+Alt+I), the dialogue pops up inside Krita's main window, in my case it is the [DP3-Cintiq] at the bottom.

However, if I used Crop or Transform tool before using Scaling, the dialogue would pop up on [DP2-Dell] in its top-left corner, outside of Krita's main window.

This is very inconvenient when I need to resize/rotate/crop/scale multiple photos. Especially if the screens are both 4K and such. Each time I had to move the mouse across super long distance to reach that orphan dialogue.
Comment 1 Halla Rempt 2019-09-27 08:59:26 UTC
I'm sorry, but I cannot reproduce that with my plasma desktop on KDE Neon in a two monitor configuration.

Placing the dialog windows isn't something Krita actually does, it's the window manager that places windows. In this case, we create the image size dialog properly with the mainwindow as its parent -- I don't think we can actually do anything here :-(
Comment 2 Halla Rempt 2019-09-27 12:22:34 UTC
Okay, I'm wrong here. I just noticed that we do have a lot of ancient code that tries to place dialogs in KoDialog. I still cannot reproduce, but I can disable all that stuff and then we can test what happens in the next nightly build.
Comment 3 Halla Rempt 2019-09-27 12:24:16 UTC
Er... Looks like that code wasn't called in any case.
Comment 4 Halla Rempt 2019-09-27 12:29:34 UTC
Git commit 6187864e7ffeb1d41c324e7636beca35a659de34 by Boudewijn Rempt.
Committed on 27/09/2019 at 12:26.
Pushed by rempt into branch 'master'.

Remove unused code for moving dialogs around

M  +0    -100  libs/widgets/KoDialog.cpp
M  +0    -21   libs/widgets/KoDialog.h

https://invent.kde.org/kde/krita/commit/6187864e7ffeb1d41c324e7636beca35a659de34
Comment 5 Tyson Tan 2019-09-28 02:40:10 UTC
Is it possible to have something to do with how Krita is shipped?

1) As a package from a Linux distro's native repository, built with, and utilize the distro's local dependencies;

2) As an Appimage which is built with with, and utilize all its own dependencies independent of the distro's local ones.

Because: today I tested again with Krita 4.2.5-2 from Manjaro Linux's official repository. It has different window decoration (a dark title bar, while the appimage has a white title bar). Possibly indicating that the local KDE/Qt stuff is at work) and it doesn't have this issue at all. 

By comparison, the appimage packages I downloaded from Krita.org have always been affected by all sorts of window management problems under KDE Plasma, plus not being able to accept text input from Input Methods like fcitx. All those problems can be reliably recreated on my setup, although under Gnome the experience is generally better.

I shall test this later on Windows 10 too.
Comment 6 Halla Rempt 2019-09-28 06:59:21 UTC
Yes, that's possible. The appimage doesn't have the plasma platform plugin or other distribution tweaks to Qt or plaform plugins.
Comment 7 Halla Rempt 2019-09-28 07:39:57 UTC
Okay, I tested with the appimage on dual monitor setup (KDE Neon developer edition) with the monitors stacked vertically, and I still couldn't reproduce :-(
Comment 8 Tyson Tan 2019-09-28 08:35:39 UTC
(In reply to Boudewijn Rempt from comment #7)
> Okay, I tested with the appimage on dual monitor setup (KDE Neon developer
> edition) with the monitors stacked vertically, and I still couldn't
> reproduce :-(

Maybe take a look at the priority of your monitors, like swapping their connectors' on the GPU? 

You see: my Upper Dell monitor is connected to [Displayport-2], the Cintiq was connected to [Displayport-3]. Those numbers are not arbitrary, they actually reflect the physical priority of the GPU's connectors. You can list them using xrandr in Linux terminal. 

In my case, since the upper Dell monitor has higher priority, it makes sense that when kwin doesn't know what to do with a pop-up, it places it on the top-left corner of the first screen.

If you are using a laptop with an external monitor, nothing has nigher priority than LVDS-1, the internal display. You can place Krita's main window on the upper monitor, see if the popup shows up at the bottom internal display.

I will do some further tests on my end later, to see how swapping the connectors affects my situation.
Comment 9 Halla Rempt 2019-09-28 08:39:31 UTC
I can only test on a laptop -- since I don't have a desktop with the right kind of ports to attach my monitor and my cintiq hybrid companion.
Comment 10 Tyson Tan 2019-09-29 05:24:28 UTC
Here are my test results:

1) krita-4.3.0-prealpha-0d8465d-x86_64.appimage doesn't fix the issue.
2) It has nothing to do with physical display order. The dialogue always pops up on the top-left corner of the upper screen.
3) I tried to create window rules in Kwin, forcing it to position inside the main window, but to no effect.
4) The issue doesn't happen to Krita 4.2.6 under 10 1903.

Maybe it is a Manjaro KDE vs. appimage specific issue. I will get a Gnome LiveUSB later today to confirm that.
Comment 11 Tyson Tan 2019-09-29 05:49:40 UTC
I tested this on Manjaro Gnome 18.1.0 LiveUSB, Krita 4.2.7beta1.appimage. It doesn't happen there. So I think this is a Manjaro KDE + Appimage specific issue. Do you have some suggestions that if I want to get to the bottom of this, where should I look at?
Comment 12 Tyson Tan 2019-09-29 08:36:30 UTC
I think I've narrowed down something:

[HOW TO TRIGGER]
1) KDE Plasma. Multi display. Put Krita's main window at the bottom display.
2) Make any changes to KDE Plasma - System Settings - Display - "Primary Display" setting.
3) Krita - New document - Crop/transform action
4) Ctrl-Alt-I
5) Dialogue incorrectly placed to the top-left corner of the whole desktop.
6) Immediately create a new document as a new tab. But this time do NOT Crop/transform
7) Dialogue place correctly inside the main window.

[WORKAROUND]
A) Close the affected document tab. Reopen.
B) Remove kritarc as a permanent fix, until next time the "Primary display" setting is changed.

[THE LONG VERSION]

1) I've tested Krita appimage on Manjaro KDE 18.1.0's LiveUSB. Without any modification to the system, the Scale Image dialogue always popped up correctly after Crop/tranform. Restarting Krita didn't break it.

2) As soon as I changed KDE Plasma's "Primary Display" setting (regardless of what changes), the "Scale Image to New Size" dialogue immediately popped up on the top-left corner of the top display (after Crop/transform is used). It will always find its way to the top-left corner of the whole desktop area.

3) Only the "Scale Image to New Size" dialogue (Ctrl-Alt-I) is affected. Other dialogues are unaffected.

4) Once the issue is triggered, restarting Krita cannot fix it. Crop/transform -> Scale Image dialogue will always pop up incorrectly.

5) Each document seems to remember its Crop/transform trigger state. If you opened 2 documents simultaineously, Crop/transform in Document A to make the Scale Image dialogue popup incorrectly, Document B's Scale Image dialogue still pops up correctly until you used Crop/transform in that tab.

6) Removing kritarc permanently fix the issue, until next time KDE Plasma's Primary display setting is changed.

7) Both the appimage and distro repo versions are affected. 

8) Both Tabs and Subwindows modes are affected.