Bug 392932 - Window position fault with 4.1.0 pre-alpha (2d068df) appimage Window Layouts tool
Summary: Window position fault with 4.1.0 pre-alpha (2d068df) appimage Window Layouts ...
Status: ASSIGNED
Alias: None
Product: krita
Classification: Applications
Component: Usability (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: joupent
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-09 14:30 UTC by Ahab Greybeard
Modified: 2019-06-20 09:14 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ahab Greybeard 2018-04-09 14:30:14 UTC
This fault has been seen with the nightly appimage (2d068df).

If dual and single monitor layouts are saved, you can switch from a single monitor layout to another single monitor layout, even if this involves switching to the other monitor.

You can switch between different dual monitor layouts.

However, if you switch from a single monitor layout to a dual monitor layout, the result is a single monitor window with a dual monitor layout crowded inside it.

The mitigation for this is to drag the edge of the window across onto the other monitor, so the window exists on both monitors and then reselect the dual monitor layout from the drop down list.
I classed this as a minor fault since the mitigation simple.
Comment 1 Halla Rempt 2019-05-03 13:20:50 UTC
Okay, to get back to this:

* is this when you use window layouts in Krit,a or is about desktop monitor layouts? 

* if the latter, I might be trying to reproduce it the wrong way. What I did was:

** set Plasma to spanned dual monitors
** Move Krita to the second monitor
** Disable the second monitor

Then I see Krita moved to the remaining monitor by the window manager.

Which desktop/window manager are you using?
Comment 2 Ahab Greybeard 2019-05-03 16:19:58 UTC
Just tested with the May1st krita-4.2.0-pre-alpha-96b04ed-x86_64.appimage.
Not tested with a Windows executable on Windows 10 and I had a different bug report for that https://bugs.kde.org/show_bug.cgi?id=392931

This is with using the Krita Window Layouts selector tool, under the Workspaces selector tool.

I'm using the MATE 1.16.2 desktop on Debian 9 (regularly updated) but I always have the main window on the right monitor with 1x monitor wide layouts (with some floating dockers on the left monitor) and the krita canvas on the right monitor with 2x monitor wide layouts (with multi-column docked and tabbed dockers on the left side monitor). However, I gave up using 2x monitor wide layouts last year because of this problem.

The behaviour is now different and a lot better. (The Windows 10 bug may have improved as well but I haven't had a look at it yet.)

Now, I can switch between 1x monitor wide main window, 1.5 x monitor main window and 2x monitor wide main window using the Windows Layouts selector. However, the Window Layouts selections also seem to store and restore the docker/workspace layout details as well. I thought that it was only the Workspace selector that stored the docker arrangements (both docked and floating).

Sometimes when switching from a 2x wide layout to a 1x wide layout, it puts the main window on the 'wrong' monitor but I can fix that by selecting a different 1x wide Window Layout then selecting my desired Workspace layout.

What is the purpose and intended functions of the Window Layouts tool? At the moment, it seems to combine a Window size function and a docker arrangement function. If there was only a 'Window Layouts' tool that selected a particular window size and particular docked+floating dockers arrangement then that would be fine, if it worked.

Whatever arrangement I have is remembered after a Quit and restart and the amount of time spent 'fixing' any problems is minor but can be confusing until you get used to it.
Comment 3 Bug Janitor Service 2019-05-04 04:33:14 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.