Bizarre window snap at screen borders

[Duncan]

Wes Hardin posted on Thu, 24 Oct 2013 10:54:42 -0500 as excerpted:

> That is a separate issue that I don't know about.  My maximized windows
> don't have a border to grab and drag, which I thought was a selectable
> option but I can't seem to find it now.  I remember seeing the
> "maximized windows can be resized" option at one point too, but if
> maximized windows don't even have the option of having a border now then
> that option wouldn't make much sense.
> 
> The issue here is related to snapping, packing, or creating new windows
> at the edge of the desktop.  The KDE devs have determined that in every
> case, for every user, the border is useless at the edge of the desktop
> and thus windows should snap to the edge of the client rather than the
> decoration.
> 
> For maximized windows (which don't have a border) I expect client
> content to end at the edge of the screen, but I have many, many more
> non-maximized terminals where the border provides the valuable visual
> feedback about the end of content.
>  With the border off-screen, I just have a black box with text and no
>  indicator
> of whether the content is going off-screen.  Did I accidentally move
> part of the window off screen?  Other users have various other uses for
> the border.
> 
> While I recognize that some users may like the "feature", there are many
> who have voiced their dislike of the feature.  I'm not advocating that
> my way be the only way, I've only asked for an option to toggle it.

It may be a (sort-of) separate issue conceptually, but AFAIK the same 
patch (or series of patches) removed the edge of screen border for both 
cases.

As for maximized windows, my expectation was apparently different than 
yours -- I maintain a conceptual difference between a maximized window, 
which should still have a border at the screen edge, and a full-screen 
window, which shouldn't.

As for use-case, here's one:  I have a kwin rule for pelapeli (kde's 
jigsaw puzzle "game") set, which forces the window to cover my two main 
monitors, with the titlebar just at the bottom of the third/top monitor 
(configured logically stacked on the other two so moving the mouse up 
moves into it, but it's physically off to the side, due to physical space 
constraints as the two big monitors are actually 42-inch TVs covering an 
entire wall at the foot of my bed, without room for the third except off 
to the side).  Covering the two 42-inch big monitors makes the for a 
puzzle window about the same size as the puzzle table my family used to 
use when I was a kid... there's room to spread out the puzzle pieces.

But, I have the rule set to force the size and location of the window 
such that the borders remain onscreen, despite the multi-monitor 
"maximized" window.  Among other reasons this allows me to easily close 
the window with just the mouse (which is used when working on the puzzle, 
the keyboard being set off to the side and temporarily forgotten about as 
it's not useful for doing the puzzle), since I can get to the border and 
activate the window context menu with the window close option, from 
there. That way I don't have to go reaching for the keyboard to close the 
window from there, or crane my neck and squint at the smaller monitor off 
to the size, to maneuver the mouse to the close button in the titlebar 
found there -- hitting the "infinite edge" and activating the window's 
context menu to close the window is far easier in this case, and it won't 
work if the window border is off the edge of the screen.

Which brings up a point.  It's still possible to use window rules to 
force the borders to be where people want them, IF AND ONLY IF it's 
reasonable to force the window location and possibly size (depending on 
the screen border involved).  However, since that /does/ end up forcing 
the location and possibly size of the window as well, which works for the 
use case I mention above, but not for others, it's not suitable when 
window location flexibility is desired.

For instance my normal konsole window layout is two side-by-side, and I 
can't force the location as it would force them to be on top of each 
other instead of side-by-side.  Unfortunately, that means kde's new 
default "border offscreen" behavior comes into play, and the external 
borders of the konsole windows disappear, leaving only the internal 
borders where the two butt up to each other, thus visually unbalancing 
them since the border on one side is there but the border on the other 
isn't.  What's worse, since the border that's missing is the screen-edge 
border, it effectively kills the "infinite edge" advantage I mentioned 
above -- the ability to mouse to the edge and have the mouse "magically" 
stop at just the right spot to activate the window context menu to close 
or otherwise manipulate that window.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.