Bug 412393

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 :-(

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.

Er... Looks like that code wasn't called in any case.

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

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.

Yes, that's possible. The appimage doesn't have the plasma platform plugin or other distribution tweaks to Qt or plaform plugins.

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 :-(

(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.

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.

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.

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?

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.

Git commit a286d2383f7fa8938bdc3d3d4fa04506ded335d0 by Halla Rempt.
Committed on 11/08/2022 at 10:37.
Pushed by rempt into branch 'master'.

Force-place the dialog over the parent window

For some reason, sometimes, a dialog is placed in the top-level
corner of the desktop by Qt or by the Window Manager, despite
adjustPosition in QDialog doing the right thing.

This copies the QDialog adjustPosition code to KoDialog (since
it's obviously not public) and uses a singleshot time to move
the dialog window to the right place after 3 ms from the showEvent.

M  +92   -8    libs/widgets/KoDialog.cpp
M  +5    -8    libs/widgets/KoDialog.h

https://invent.kde.org/graphics/krita/commit/a286d2383f7fa8938bdc3d3d4fa04506ded335d0

Git commit 3a7c7ced9bfe1e7bc9162dcac5a2d973c8b383c8 by Halla Rempt.
Committed on 11/08/2022 at 10:45.
Pushed by rempt into branch 'krita/5.1'.

Force-place the dialog over the parent window

For some reason, sometimes, a dialog is placed in the top-level
corner of the desktop by Qt or by the Window Manager, despite
adjustPosition in QDialog doing the right thing.

This copies the QDialog adjustPosition code to KoDialog (since
it's obviously not public) and uses a singleshot time to move
the dialog window to the right place after 3 ms from the showEvent.
(cherry picked from commit a286d2383f7fa8938bdc3d3d4fa04506ded335d0)

M  +92   -8    libs/widgets/KoDialog.cpp
M  +5    -8    libs/widgets/KoDialog.h

https://invent.kde.org/graphics/krita/commit/3a7c7ced9bfe1e7bc9162dcac5a2d973c8b383c8

A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1591

Git commit 751483e2b41c76d316740dfb2a576ba1d3644f6d by L. E. Segovia.
Committed on 13/10/2022 at 00:16.
Pushed by eoinoneill into branch 'master'.

KoDialog: simplify force placement fix

KoDialog is a subclass of QDialog and adjustPosition() and
parentWidget() are marked as protected, so there's no need to copy
anything nor use a lambda. Just force execute the methods.

M  +3    -80   libs/widgets/KoDialog.cpp
M  +0    -1    libs/widgets/KoDialog.h

https://invent.kde.org/graphics/krita/commit/751483e2b41c76d316740dfb2a576ba1d3644f6d