Bug 325475 - near workspace area covering maximized windows should alilgn to the titlebar position
Summary: near workspace area covering maximized windows should alilgn to the titlebar ...
Status: REOPENED
Alias: None
Product: kwin
Classification: Plasma
Component: core (other bugs)
Version First Reported In: 4.10.5
Platform: Debian unstable Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-30 21:26 UTC by Xxx
Modified: 2020-11-12 00:07 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xxx 2013-09-30 21:26:37 UTC
When maximizing a window that resizes in increments (like xterm or GVim), the spacer between the panel and window bottom is the wrong size, since there is a small gap between the titlebar and the top of the screen. So pushing the mouse against the top of the screen and clicking clicks on the desktop, or selects another maximized window underneath, instead of selecting the window.

Reproducible: Always

Steps to Reproduce:
1. clear the desktop
2. open xterm (or gvim, or some other program that enforces window size increments)
3. maximize it
4. push the mouse against the top of the screen and right-click
Actual Results:  
the desktop menu is opened

Expected Results:  
the window titlebar menu is opened

My monitor is 1280x1024, and I'm using the default Oxygen KWin theme. I'm not sure how to find out the size of the panel, if it matters.
Comment 1 Thomas Lübking 2013-10-01 05:38:12 UTC
That's not really a bug - the window cannot occupy random geometries (and is centered on screen with the maximum size)

Either override size increments (kcmshell4 kwinrules) for the window or just move the window to the desired alilgnent (top, bottom, left, right)
Comment 2 Xxx 2013-10-01 13:08:47 UTC
(In reply to comment #1)
> That's not really a bug - the window cannot occupy random geometries (and is
> centered on screen with the maximum size)

My concern was that this might be a usability issue, especially with multiple monitors, since you can't pretend that the titlebar is "infinitely tall" any more.
Comment 3 Thomas Lübking 2013-10-01 15:49:15 UTC
I guess that's mostly a problem when the gap is pretty small (and you're not placing a "display" of a panorama stitch or a window that maximizes to VGA on WUXGA)
Comment 4 Martin Flöser 2015-01-05 14:02:09 UTC
Honestly: there is nothing we could reasonably do about it, so I'm adjusting to WONTFIX.

We either can respect what the window asks for and get the gap or run into a situation that the window starts to resize itself.

I don't think it's a big usability issue as such applications are (luckily) very rare.
Comment 5 Thomas Lübking 2015-01-05 14:26:50 UTC
erhemmm, *cough* - please see comment #3 (or history ;-)

My idea was to not maximize centered if the gap is "very small™" but align the titlebar edge (and increase the opposing gap)

I'll boldly re-open it once. Please forgive and close again if you disagree.
Comment 6 Martin Flöser 2015-01-05 14:42:54 UTC
but where to align to? Left or right? Depending on user settings the one could be worse than the other and we cannot really know which one it is.
Comment 7 Thomas Lübking 2015-01-05 15:40:38 UTC
I'd say, preferably
1. towards the (physical) screen edges
2. where the titlebar is.

Left/Right (ie. adjacent borders w/ unpadded screen edges on either side) is close to random, but it might indeed still be better to just stuff it into one edge and have a bigger (ie. also more notable) gap on the other side than surrounding the window w/ a 1px margin.
Comment 8 Justin Zobel 2020-11-12 00:07:14 UTC
(In reply to Martin Flöser from comment #6)
> but where to align to? Left or right? Depending on user settings the one
> could be worse than the other and we cannot really know which one it is.

Martin, thoughts on this matter?