Created attachment 81705 [details]
picture of a window snapped outside

Created attachment 81706 [details]
picture of a window snapped correctly

Correction: the "good" snap only occurs when the window also snaps to the panel.

Snapping to window content is intended (to have scrollbars etc. aligned)

Please specify your decoration border width (the one that causes non-content snapping along low snap zone widths)

Forget that - can see it on screenshot.
Is there a panel at the snapping edge?

No, the panel is at the bottom, the snapping is on the left side. Actually, since then I noticed that it isn't the panel that makes the difference, but any other window: if the moved window snaps to an other and to the side at the same time, than it works OK, a lonely windows snaps incorrectly.

If the window snapping is stronger it takes precedence.

Since the screen snapping to content is intended, this is not implicitly a "bug". You'll have to explain why you'd consider it to be (and please don't just say "it changed" ;-)

The problem is when there is no other window around, so "snapping to content" is not applicable.
The scenario shown in the firts attachment (snapped outside) is wrong, because you don't see the window border, so you can't be sure that there is no important portion of the window is hidden. With snapping turned on, it is impossible to snap the window (with border) to the edge of the screen, you can pick between having a part out or having an empty stripe.
In case of multiple screens, the border of the window thus snapped pollutes the neighboring screen. I really hope this is not the intendended behaviour.
When I start an app, the autoplacement places the window to an expected place (expected by me at least :) ), to 0:0 coordintes. If I move it, there is no way to put it back. If nothing else, this inconsistency is a bug.

(In reply to comment #8)
> so you can't be sure that there is no important portion of the window is 
> hidden.

That argument is nonsense.
First you can have no border on windows at all without problems, second, if it's important you'll now when it's not there and third, you may actually trust the system to snap to the content and not somewhere else (that window snapping can outperform screen snapping is completely orthogonal to this and not new - it can always prevent you from snapping to screen if there's another window - i would however agree that this should be altered)

> In case of multiple screens, the border of the window thus snapped 
That's actually a valid concern, given the reason for edge snapping is to allow for fitt's law on the content edges.

> When I start an app, the autoplacement places the window to an expected
> place (expected by me at least :) ), to 0:0 coordintes.
That's bug #318107

(In reply to comment #9)
> (In reply to comment #8)
> > so you can't be sure that there is no important portion of the window is 
> > hidden.
> 
> That argument is nonsense.
> First you can have no border on windows at all without problems, second, if
> it's important you'll now when it's not there and third, you may actually
> trust the system to snap to the content and not somewhere else (that window
> snapping can outperform screen snapping is completely orthogonal to this and
> not new - it can always prevent you from snapping to screen if there's
> another window - i would however agree that this should be altered)

Trust me, it is a valid concern for me. I have lots a windows on lots of virtual screens, I prefer not to remember every time if it was snapped to the edge or thrown over a bit more. I rely on the visual cue of the window border: that's what it's for. (I have no problem with window snapping interfering with screen snapping)

I also managed to understad the reasoning behind content snapping, it is in deed neat to have scrollbars line up; still, the scrollbars are on one side, why does kwin insist on content-snapping on both side? The scrollbar is as sufficient visual cue as the window border, I don't mind content-snapping that side, but the other side I really do. Can't we have at least a switch to disable it?

(In reply to comment #10)
> the scrollbars are on one side
No.

Most scrollbars are on the right, yes.
But often there's one on the bottom and on some windows (or by config option) they're on the left (and so they are when the window content is right-to-left aligned)
Overmore there're often toolbutton etc. rows on the left.

The WM doesn't now anything about a particular client content.
Either content snapping is good or bad in general.

And content snapping to a particular edge only would not cover your "i don't know whether it's snapped or offscreen" concern either - while i'd say either you miss something in the window (than it's too far off) or you don't (then it doesn't actually matter whether - if that would be possible against snapping - one or two pixels are cut off)

(In reply to comment #11)

> 
> The WM doesn't now anything about a particular client content.
> Either content snapping is good or bad in general.

In this case, for me, it's bad. (the scrollbars are lining up all the same if the border is visible)

> 
> And content snapping to a particular edge only would not cover your "i don't
> know whether it's snapped or offscreen" concern either - while i'd say
> either you miss something in the window (than it's too far off) or you don't
> (then it doesn't actually matter whether - if that would be possible against
> snapping - one or two pixels are cut off)

The problem is not that I can't decide if it's snapped or not, the problem is that I used to be able to do it at a glance, using the border. (Maybe it's because I use white-on black terminals and my monitor has also black border, it's really disturbing with the new behaviour)

Maybe it would be possible to snap to both (deco and client), depending on how far you move the window.

Let me add that while I think the new behavior makes sense, I share Roberts' concerns about the visual "distraction".

Also, the feature is not fully consistent. For fully maximized windows, the frame is removed. For only horizontally maximized windows, the frame would have to be clipped at the left and right side, too.

> the scrollbars are lining up all the same if the border is visible

Well, but if there is no border, you can just move the mouse to the edge, and can be sure to hit the scroll bar, not the border. I sometimes accidentally resized my Kate window because of that, and with the new snapping, it cannot happen.

(In reply to comment #13)
> Also, the feature is not fully consistent. For fully maximized windows, the
> frame is removed. For only horizontally maximized windows, the frame would
> have to be clipped at the left and right side, too.

Matter of deco implementation. Same for QuickTiling. I shall send Hugo patches (what means i need to update liboxygen first ;-)

(In reply to comment #14)
> > the scrollbars are lining up all the same if the border is visible
> 
> Well, but if there is no border, you can just move the mouse to the edge,
> and can be sure to hit the scroll bar, not the border. I sometimes
> accidentally resized my Kate window because of that, and with the new
> snapping, it cannot happen.

This is an important use case, I admit. Still, in case of multiple monitors, it is counterproductive in the "middle" borders. I suggest it to be a configurable setting for every edge, among the other screen edge settings.

https://git.reviewboard.kde.org/r/112103/
and also:
https://git.reviewboard.kde.org/r/112102/
https://git.reviewboard.kde.org/r/112124/

*** Bug 323855 has been marked as a duplicate of this bug. ***

I really don't like to be forced to this change to "snap to content" with no way of keeping the previous behavior. Windows snapped to the vertical edges look broken to me, and I can't really see the benefit in this change for my way of working. What's even worse, on a two-monitor setup, windows snapped to the edge between the monitors have their decoration protruding onto the other screen (see the attached photo for an example).

I am very much considering going back to version 4.10, because of this change, which – for me – drastically changes the whole desktop look and handling, and I don't like it at all.

Created attachment 81881 [details]
photo showing the protruding edge for windows snapped to the edge between two screens

(In reply to comment #19)
> I really don't like to be forced to this change to "snap to content" with no
> way of keeping the previous behavior. Windows snapped to the vertical edges
> look broken to me, and I can't really see the benefit in this change for my
> way of working. What's even worse, on a two-monitor setup, windows snapped
> to the edge between the monitors have their decoration protruding onto the
> other screen (see the attached photo for an example).
> 
> I am very much considering going back to version 4.10, because of this
> change, which – for me – drastically changes the whole desktop look and
> handling, and I don't like it at all.

Agreed, but not going back yet.

Thomas Lübking, if I apply those patches in the order you gave to Kwin will this 'fix' this bug (a temporary one of course)?

(In reply to comment #21)
> if I apply those patches in the order you gave to Kwin will
> this 'fix' this bug (a temporary one of course)?

The first one deals with your problem (completely, i assume, but i've reservations against turning snapping into an obstacle, so i'll gonna update it to the "general agreement" state somewhen tonight or tomorrow. Older patch versions remain accessible, though)

The other two deal with remotely related issues (one about snapped movement of maximized windows, snapping to other windows as well, the other one with positioning towards the client when a client is shown)

(In reply to comment #22)
> (In reply to comment #21)
> > if I apply those patches in the order you gave to Kwin will
> > this 'fix' this bug (a temporary one of course)?
> 
> The first one deals with your problem (completely, i assume, but i've
> reservations against turning snapping into an obstacle, so i'll gonna update
> it to the "general agreement" state somewhen tonight or tomorrow. Older
> patch versions remain accessible, though)

I tried only the first patch and it works great. Having the option between border snapping and content snapping is a decent compromise IMHO.

If anybody on Gentoo wants to test, install my overlay with layman and emerge kde-base/kwin and then restart kdm/login or restart KDE.

https://github.com/Tatsh/tatsh-overlay
https://github.com/Tatsh/tatsh-overlay/tree/master/kde-base/kwin

Forgot to mention that with that first patch, maximisation is still weird. Maximisation removes borders. This is somewhat acceptable but makes the interface inconsistent. If the idea is to make an option or if themes need tweaking/etc, I would like to know.

Make a demand to your favorite decoration to offer showing borders even on maximized windows.

As explained in detail in bug #299245 comment #5, this has never really been a WM feature ever, decos just "abused" a hint and the setting was relabeled in a misleading way to resolve a logical conflict of the actually controlled setting.

> If anybody on Gentoo wants to test, install my overlay with layman and
> emerge kde-base/kwin and then restart kdm/login or restart KDE.

Installed, and it looks good. Thank you!

Let me tell you another use case where this new "content snapping" behavior is annoying as hell. (I really thought it was a bug in KWin 4.11 and was sad to come here and find that it was intentional.)

My monitor's resolution is 2560x1600. I use a size of exactly 1280x1024 for most application windows. This lets me put two windows side-by-side perfectly with no overlap, and I can effectively use all four corners of my screen. The new "content snapping" behavior means that my perfectly sized windows now bleed off the edge of the screen and leave a gap down the middle. Though I could work around this by increasing the dimensions by the width of a border, there is another problem that the windows appear asymmetrical: there is a visible window border on two edges but none on the other two. This is visually disconcerting, to say the least.

The argument about "aligning scroll bars" is really weak, in my opinion. Who actually touches the scroll bar with the mouse cursor? I use it only as an indication of where I am in the document. I scroll using the mouse wheel. And anyway, I've never had a problem hitting the scroll bar when I need to.

I hate that I'm now going to have to start patching KWin with every release so that I can have sane snapping (and now with bug 318107, sane placement) behavior.

(In reply to comment #27)

> My monitor's resolution is 2560x1600. I use a size of exactly 1280x1024 for
> most application windows. This lets me put two windows side-by-side
> perfectly with no overlap
As you mentioned yourself that is actually no issue, because you chose a specific size to arrange your windows in a specific way and you can still choose a specific size to arrange your windows in a specific way - the size changed, but that's it.

Actually if you so far arranged your windows like this:
   kwrite --geometry 1280-(2*decowidth)x1024+0+y &
   kwrite --geometry 1280-(2*decowidth)x1024+1280+y &
nothing changed at all and neither if you use kwin rules or a script to apply initial size and position to the window.

I however assume you just setup a rule to make windows 1280x1024 and then move them somewhere at the screen borders?
Functionally the only change is, as you mentioned, to make the rule wider by the decoration border width.

> windows now bleed off the edge of the screen
bleeding into a second screen (though i think you were not pointing that) is subject to linked review request.

> there is another problem that the windows appear asymmetrical:
> there is a visible window border on two edges but none on the
> other two. This is visually disconcerting, to say the least.
Actually, it is visually disconcerting at best - and linked to your pseudo tiling approach, which could better be dealt by simply

Just fyi, it's also not asymmetrical (for the setup) - the visual border dimensions mirror (it would be assymetrical if there was no border on eg. both left sides).

---

Now on actual ratio:

> The argument about "aligning scroll bars" is really weak, in my opinion. 
This is not about scrollbars in particular.
The ratio here is /very/ simple.
The screen edges have an infinite area, turning them the most valuable regions for mouse interaction.
Snapping to the window decoration "wastes" this area for the decoration - where also the only possible action is to remove the decoration from the valuable area...

It can not be utilized by clients eg. for autohiting panels (inside the client), or tolbars, or ... or -in just many cases- the scrollbars.

This is the argument you have to defeat. Or, positively:
Why does it make sense to have esp. the window borders at this position, which can be not used for anything else but to be removed from that position?

> Who actually touches the scroll bar with the mouse cursor?
> I use it
Extrapolation from oneself to the rest of the world is usually gonna fail, thus never an argument.

> I scroll using the mouse wheel.
You are scrolling to the beginning of the lower third of tenthousand lines (or just even this bug report) with the scrollwheel??
-qed

I'd rather use a shortcut or the scrollbar - seriously. Even the short source file i was just looking at (<300 LOC) took 13 mousewheel rotations (not clicks, but wheel as much as possible w/o repositioning the finger) from top to bottom.
This is however not relevant, since this is not a scrollbar specific matter (and there're fancy new mice where one can unlock the wheel)

> And anyway, I've never had a problem hitting the scroll bar when I need to.
This is not related to "scrollbars are too hard to hit" (that would be solved by making them wider) but "the window decoration occupies the value area of the screen for itself alone and actually no reason"

> and now with bug 318107
is fixed, 4.11.1

> I hate that I'm now going to have to start patching KWin with every release
Since your only real trouble seems to be with the look, i'd frankly test this for a while first (you gain more size for the actual window content =)

(In reply to comment #28)

Thanks for the point-by-point response.

I will try to force myself to grow accustomed to this behavior, but I think I will work on adding a "snapping behavior" setting to KWin in the meantime. The user could pick whether to snap at window edge, client edge, or both.

As a general note, from a product design perspective, it's a really bad idea to change software behaviors that are deeply ingrained into your user base without giving them a way to continue using the original behavior. Your users will resent you for trying to force them to change. Your opinion on why the change makes sense will not be shared by everyone.

Lastly, it seems there is a bug in the implementation of this content snapping behavior: the top edge of the screen (on which I have no panel) is attracting the top edge of the window border rather than the top edge of the title bar.

(In reply to comment #29)
> (In reply to comment #28)
> 
> Thanks for the point-by-point response.
> 
> I will try to force myself to grow accustomed to this behavior, but I think
> I will work on adding a "snapping behavior" setting to KWin in the meantime.
> The user could pick whether to snap at window edge, client edge, or both.

Please notice that this is unfortunately no more possible for KDE4 (as workspace was feature frozen)
There's a patch to snap on both, client and deco, on reviewboard but it sucks (i wrote it, so i'm allowed to say that) because it turns snapping into an obstacle game (for a thin decoration it become very hard to control whether to snap to deco or client - and it's hardly visible either. Option or not: there must be either or - not both)

> Lastly, it seems there is a bug in the implementation of this content
> snapping behavior: the top edge of the screen (on which I have no panel) is
> attracting the top edge of the window border rather than the top edge of the
> title bar.
I'm not sure whether I understand this.
Technically the titlebar is just a very thick border where the decoration plugin puts some text and buttons - there's no "titlearea+fat outline" separation or similar - we just snap to the titlebar (always and unconditionally, as there's strong reason to not allow it to drop out of screen for any reason)
-> What decoration do you use?
I tested oxygen, plastik, laptop and some aurorae decos and no matter how fat i make the border, they all keep the titlebar at the same size (no extra border)

PS, reg. decorations and your specific setup:
several decorations support to have no (side) borders and since we provide border resizing via an input window and compositing/shadows (?) provide a visual separation, they actually no more required (functionally)

> there must be either or - not both

This might be true for thin frames, but with my setup, I am very happy with the current patch. I locally reverted the patch from bug 318107, though (see my comment there).

Ah, you changed it again. I was talking about revision 2 of the patch.

(In reply to comment #30)
> (In reply to comment #29)
> There's a patch to snap on both, client and deco, on reviewboard but it
> sucks (i wrote it, so i'm allowed to say that) because it turns snapping
> into an obstacle game (for a thin decoration it become very hard to control
> whether to snap to deco or client - and it's hardly visible either. Option
> or not: there must be either or - not both)

With all due respect, I can't tell you how many times I've found that windows are mapped in a position that is one pixel off from where they should be. (They'll have one empty pixel between the top of the window and the top of the screen, for example.) I frequently have to move a newly mapped window up by one pixel or left by one pixel to make it sit in the "right" place in my pseudo-tiled screen layout. There seem to be a lot of "off-by-one" bugs in KWin. So I don't think it would really be any worse to have two snap points that are four pixels apart, allowing a choice between snapping the decoration to the screen edge or snapping the client area to the screen edge.

> > Lastly, it seems there is a bug in the implementation of this content
> > snapping behavior: the top edge of the screen (on which I have no panel) is
> > attracting the top edge of the window border rather than the top edge of the
> > title bar.
> I'm not sure whether I understand this.
> Technically the titlebar is just a very thick border where the decoration
> plugin puts some text and buttons - there's no "titlearea+fat outline"
> separation or similar - we just snap to the titlebar (always and
> unconditionally, as there's strong reason to not allow it to drop out of
> screen for any reason)

Regardless of how the pieces are laid out in the X server, and regardless of how it's drawn, there is a difference in the thickness of the top non-client area when a window is maximized versus when it is not. The title-bar+top-edge area is thinner when a window is maximized because, conceptually, the window frame (the part that provides resize control) is collapsed. Maximizing a window hides the other edges as well. To be consistent, the snap-to-client-area behavior should snap to the part of the title bar that is displayed when the window is maximized.

> -> What decoration do you use?

Oxygen.

> PS, reg. decorations and your specific setup:
> several decorations support to have no (side) borders and since we provide
> border resizing via an input window and compositing/shadows (?) provide a
> visual separation, they actually no more required (functionally)

Could you explain what you mean by "border resizing via an input window"? I don't mind the way window resizing works on Mac OS X, where there are no window borders but there's a resizing tab in the lower-right corner. It's not quite as good as having the ability to resize in all directions independently, though, in my opinion.

(In reply to comment #33)

> With all due respect, I can't tell you how many times I've found that
> windows are mapped in a position that is one pixel off from where they
> should be. (They'll have one empty pixel between the top of the window and
> the top of the screen, for example.)

Please explain "where they should be".
There're several mapping strategies:
- "Smart"
- "Maximizing"
- "Cascade"
- "Random"
- "Centered"
- "Zero-Cornered"
- "Under Mouse"

You can predict the behavior or zero-cornered and centered, but for "centered", you'll be naturally "off by one" for windows with odd dimensions and an even placement area (or vv.)

This does however not hold for clients which demand a certain positionwhen mapped - unless suppressed by a rule, those whishes are honored (as suggested by NETWM spec)
In addition, the placement area is constrained by any (strutting) panel.

You should point the configured placement strategy and one or more clients causing "off-by-one" placement to verify your assumption of one of the 'lot of "off-by-one" bugs in KWin' - which I would like to be shown.

> I frequently have to move a newly mapped window up by one pixel or 
> left by one pixel to make it sit in the "right" place in my pseudo-tiled 
> screen layout.
No, you don't. Utilize the zero cornered placement (globally or by sepcific rule) and setup a rule to ignore geometry requests.
If the client still maps "off-by-one", you found an interesting issue - worth investigation.



> there is a difference in the thickness of the top non-client
> area when a window is maximized versus when it is not.
Yes, the decoration has a chance to alter it's borders when becoming maximized to not waste space.

> The title-bar+top-edge area is thinner when a window is maximized 
for certain decorations, yes.

> because, conceptually, the window frame [...] is collapsed.
Even if that was the the concept...

> To be consistent, the snap-to-client-area behavior should snap to the 
> part of the title bar that is displayed when the window is maximized.
... this would no way work.
Let's assume the core would track the behavior of the decoration plugin on maximization and knew that it vertically shrinks by 10px when becoming maximized and assumes "this is certainly because it removes a frame" and would snap to 10px below the decorations titlebar top, it would simply cut off part of the vertically aligned title.
We do not know what the decoration does when given the opportunity to alter its borders on maximization (and quick tiling) - what would instead have to happen is to inform the deco about the snapping, have it alter its titlebar and/or borders and reposition the result.



> Could you explain what you mean by "border resizing via an input window"?
Despite there're no visual borders, you can still resize the windows as if there were, you can configure that in "kcmshell4 kwindecoration", press the "configure decoration" button and set "Border size" to "No border".
Requires more recent Qt (4.8.3/4/5 or so)

> don't mind the way window resizing works on Mac OS X
Supported by some decos (including oxygen) as well, but not what i meant.

(In reply to comment #34)
> Please explain "where they should be".
> There're several mapping strategies:

I use "Smart." As I said, most of my application windows are sized to 1280x1024, either by KWin rules or simply because they remember their size across instances. I like for them to appear in the "least used" corner of my screen. "Smart" placement does this perfectly. If I have windows occupying any three corners of my screen, then a new, fourth window will always appear in the unused corner. It's just that sometimes it appears in a position that's off by one pixel. (Maybe there will be an extra pixel between the window and the edge of the screen, or maybe there the window will be hanging off the edge of the screen by one pixel.) It probably happens about once a week, so the next time it does, I'll try to characterize the conditions necessary to reproduce the behavior.

> This does however not hold for clients which demand a certain positionwhen
> mapped - unless suppressed by a rule, those whishes are honored (as
> suggested by NETWM spec)
> In addition, the placement area is constrained by any (strutting) panel.

Yes, and I have no complaints about explicitly requested placement. That works as it should. I'm only talking about when KWin chooses the position for a new window.

> You should point the configured placement strategy and one or more clients
> causing "off-by-one" placement to verify your assumption of one of the 'lot
> of "off-by-one" bugs in KWin' - which I would like to be shown.

Sorry if I offended you. I will indeed try to find minimal steps to reproduce the off-by-one behavior, and I'll report back to you when I have them.

> > I frequently have to move a newly mapped window up by one pixel or 
> > left by one pixel to make it sit in the "right" place in my pseudo-tiled 
> > screen layout.
> No, you don't. Utilize the zero cornered placement (globally or by sepcific
> rule) and setup a rule to ignore geometry requests.
> If the client still maps "off-by-one", you found an interesting issue -
> worth investigation.

I don't want all of my windows to appear in the top-left corner. And I don't want any particular application's windows always to appear in the same location. Example: I have KMail open in the upper-left corner and Chromium open in the lower-left. (The right half of my screen is empty.) I launch a second Chromium window. I don't want it to open on top of KMail. I want it to open in the lower-right. The "Smart" placement strategy does this perfectly, 99% of the time.

> Let's assume the core would track the behavior of the decoration plugin on
> maximization and knew that it vertically shrinks by 10px when becoming
> maximized and assumes "this is certainly because it removes a frame" and
> would snap to 10px below the decorations titlebar top, it would simply cut
> off part of the vertically aligned title.
> We do not know what the decoration does when given the opportunity to alter
> its borders on maximization (and quick tiling) - what would instead have to
> happen is to inform the deco about the snapping, have it alter its titlebar
> and/or borders and reposition the result.

How does a dialog layout algorithm align widgets along their text baselines? It queries the widgets to find the locations of their baselines. KWin could query the decoration to determine the dimensions of its "insets" (the number of pixels that should hang off the edge of the screen when the window snaps to an outer screen edge with no panel).

> > Could you explain what you mean by "border resizing via an input window"?
> Despite there're no visual borders, you can still resize the windows as if
> there were, you can configure that in "kcmshell4 kwindecoration", press the
> "configure decoration" button and set "Border size" to "No border".
> Requires more recent Qt (4.8.3/4/5 or so)

Ah, cool. I never tried that. I might go in that direction.

> ... the window will be hanging off the edge of the screen by one pixel.) It probably happens about once a week, so the next time it does, I'll try to characterize the conditions necessary to reproduce the behavior

Here, I can reproduce when opening a window, which opens with maximum height (but not maximized vertically state). Due to the new inner-snapping-on-open, it opens a few pixels down.

(which is actually a bug, because when moving the window, it correctly snaps to the top screen edge, but I can not snap it back to the position where it opened. So the opening position is not the same as the snapping position.)

(In reply to comment #36)
> Here, I can reproduce when opening a window, which opens with maximum height
> (but not maximized vertically state). Due to the new inner-snapping-on-open,
> it opens a few pixels down.

That's new and introduced by the "make placement like snapping" bugfix.

(In reply to comment #37)
> (which is actually a bug, because when moving the window, it correctly snaps
> to the top screen edge, but I can not snap it back to the position where it
> opened. So the opening position is not the same as the snapping position.)

Err what?
It'll snap to the other edge (the titlebar) when that becomes closer, but there's no reason why you should not be able to snap it back to the other edge (and that works as expected here) - where would it snap instead?

(In reply to comment #35)

> I use "Smart."
This is getting off topic.

> across instances. I like for them to appear in the "least used" corner of my
> screen. "Smart" placement does this perfectly.
Not exactly. It tries to place the window in a least overlapping area, with a preference on the corners.
Since your third and above windows will overlap for sure, it's position depends on intersection with all other windows on screen.
Also the window should never be positioned out of the screen (before the very lastes snapping adjustment in 4.11.2, which except the decoration border from this)

> week, so the next time it does, I'll try to characterize the conditions
> necessary to reproduce the behavior.

xwininfo -root -tree
xprop

> Sorry if I offended you.
This is not about offending, but if you claim "a lot of" off-by-one errors, it's necessary to become more specific - or remains FUD.
I understood it's rather "unexpected behavior of smart placement"?

> Example: I have KMail open in the upper-left corner and 
[...]
> to open in the lower-right. The "Smart" placement strategy does this
> perfectly, 99% of the time.
It should actually open in the upper right.

> How does a dialog layout algorithm align widgets along their text baselines?
I don't think you understand the problem.
The titlestring is usually vertically centered.
If you cut off a random part of that, you move the titlestring out of vetical centration at best and cut it off at worst.
The decoration needed a signal "make yourself smaller".

It snaps to either the top edge, or 8 pixels down (which is my border snap setting). Note that the window needs to have full height, but not maximized.

Test it with a decoration that has "normal" border sizes (4 px), not very thin or very thick.

Nope.
Random guess: you got another window around there and window snapping (corner alignment) takes precendence?

Nope, empty screen. Even panel is hidden (which might make a difference).

(In reply to comment #28)
> The screen edges have an infinite area, turning them the most valuable
> regions for mouse interaction.
> Snapping to the window decoration "wastes" this area for the decoration -
> where also the only possible action is to remove the decoration from the
> valuable area...

Well you said it yourself...

> Extrapolation from oneself to the rest of the world is usually gonna fail,
> thus never an argument.

*I* don't think window decorations are wasted space.  They provide valuable visual feedback regarding the size and position of windows.  If someone else thinks window decorations are unnecessary, wouldn't the correct course of action be to remove the unwanted borders?  The option already exists to remove them.

To have window decorations enabled and then have them ignored is hair-pullingly (assuming I had some left to pull) aggravating.  I'm constantly having to move windows a few pixels this way or that.

And on the consistency front, the "pack windows" shortcuts still behave the old (correct) way.

I don't know what patches have made it mainstream yet, but even with 4.11.1, issues with multi-monitor setups still exist.  If I create a new window on my right-hand monitor, it puts the decoration on the monitor border (as expected), but if I move this window, it then snaps the content to monitor edge, putting the decoration on the left-hand monitor and the content on the right-hand monitor.  How that possibly be considered good design?

# kde4-config --version
Qt: 4.8.4
KDE Development Platform: 4.11.1
kde4-config: 1.0

# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 13.04
Release:	13.04
Codename:	raring

Using the Kubuntu Backports PPA

(In reply to comment #43)

> *I* don't think window decorations are wasted space.
And *nobody* said that.

The quoted text says, that 
    they waste the valuable screen edges
because you can use them for nothing but removing them from the valuable position.

-- short rant on style ---

Seriously, such lousy attempts are just a boring annoyance.
What you did was to turn a relative into an absolute.
Eristic Dialictic, Art No. 3

I had to memorize that book as a kid.
None of those tricks are gonna work on me, ever.
And since the only point about eristic dialectic is to maintain your position despite you're wrong, it's neither productive in any direction - what bothered me more than having to memorize it.

You can state any reasonable concern on topic anytime, but stop wasting my time, ok? You can at best make me quit the discussion by that, what's not gonna help you here either.

----

Now, back on topic.

> I'm constantly having to move windows a few pixels this way or that.

Why *precisely* do you require window decorations to touch a screen edge in particular?
-> This is the question you need to answer.

> And on the consistency front, the "pack windows" shortcuts still behave 
Yes, known bug. Packing was just forgotten. Sorry for that.

> I don't know what patches have made it mainstream yet, but even with 4.11.1,
> issues with multi-monitor setups still exist.
The particular review request is still pending.
This is a very well reasoned point (inner screen borders have no particular value for anything and the edge bleeds) and so at some point the patch will hopefully get a "ship it".

(In reply to comment #42)
> Nope, empty screen. Even panel is hidden (which might make a difference).

Autohiding panel?

> Autohiding panel?

Yep.

(In reply to comment #44)
> 
> > *I* don't think window decorations are wasted space.
> And *nobody* said that.
> 
> The quoted text says, that 
>     they waste the valuable screen edges
> because you can use them for nothing but removing them from the valuable
> position.

Dance around the syntax however you like, that doesn't change my point.  Why are the screen edges valuable?  I don't find the edges of the screen particularly "valuable", that is your personal opinion.  My opinion is that the window frame is more valuable than the screen edge.  Window decorations give visual feedback that "this is where the content ends".   If I can't see the window frame, I'm left to wonder whether there might be more off screen.  

> -- short rant on style ---
> 
> Seriously, such lousy attempts are just a boring annoyance.
> What you did was to turn a relative into an absolute.
> Eristic Dialictic, Art No. 3
> 
> I had to memorize that book as a kid.
> None of those tricks are gonna work on me, ever.
> And since the only point about eristic dialectic is to maintain your
> position despite you're wrong, it's neither productive in any direction -
> what bothered me more than having to memorize it.
> 
> You can state any reasonable concern on topic anytime, but stop wasting my
> time, ok? You can at best make me quit the discussion by that, what's not
> gonna help you here either.
> 
> ----

I am stating a reasonable concern.  If you feel this is a waste of your time, maybe you should reassign the bug to a dev who will fix it.

> 
> Now, back on topic.
> 
> > I'm constantly having to move windows a few pixels this way or that.
> 
> Why *precisely* do you require window decorations to touch a screen edge in
> particular?
> -> This is the question you need to answer.

1.) Aesthetics
2.) To keep content in my various windows aligned
3.) Visual feedback of end of content

Why precisely do you require window decorations to be non-visible?  Why are current methods for removing window decorations not appropriate for your use?

> > And on the consistency front, the "pack windows" shortcuts still behave 
> Yes, known bug. Packing was just forgotten. Sorry for that.
> 
> > I don't know what patches have made it mainstream yet, but even with 4.11.1,
> > issues with multi-monitor setups still exist.
> The particular review request is still pending.
> This is a very well reasoned point (inner screen borders have no particular
> value for anything and the edge bleeds) and so at some point the patch will
> hopefully get a "ship it".

Has anyone looked at how much space is really going to be saved by overlapping the borders?  My border size (tiny) is about 4 pixels wide, if i span 3 windows across the screen that's only 20 px of saved space in the horizontal direction (or about 1.1% on my 1680 x 1050 display) and if we have them stacked 2 high, that is 16 pixels (or 1.5%) space saved.  In other words the space you saved is hardly large enough for two letters in Sans at 12pt. Is that space really worth the headaches of borders bleeding into other screens or the frustration of trying to snap to either the inner or outer border?  I guess you *might* be able to squeeze out an extra line in the horizontal direction if your resolution is high enough, but that begs the question "If your monitor is that good, do you really need to put in all that effort for an extra line?"  If you still insist that this space is "valuable" and that border decorations are wasted space, then why not just disable borders for users that want the extra 320 sq px's?  That seems like the more logical option.  If for some reason this "feature" is still indispensable, can we please just get a check box somewhere in the settings to disable it?

(In reply to comment #48)
> Has anyone looked at how much space is really going to be saved by
> overlapping the borders?

Is this a joke?
I'm done here.
Bye.

I'd like to see the request for enhancement that prompted development of this new "feature." Where is the user story? This "feature" does not appear to have resulted from a user-centric development process. It appears to have been born out of Thomas Lübking's notion that it would be a good idea. Now there are many requests from users to change it back, or at least make it optional, but the developer has taken a childish "I'm right and you all are wrong" stance and is refusing to listen to his users. This leaves us no choice but to fork the software and maintain it as we prefer it.

(In reply to comment #49)
> 
> Is this a joke?
> I'm done here.
> Bye.

No, not really... and you know what, so am I.  I am done trying to report bugs to KDE.

(In reply to comment #50)
> I'd like to see the request for enhancement that prompted development of
> this new "feature." Where is the user story? This "feature" does not appear
> to have resulted from a user-centric development process. It appears to have
> been born out of Thomas Lübking's notion that it would be a good idea. Now
> there are many requests from users to change it back, or at least make it
> optional, but the developer has taken a childish "I'm right and you all are
> wrong" stance and is refusing to listen to his users. This leaves us no
> choice but to fork the software and maintain it as we prefer it.

I'm keeping my patched copy on my repository until I I see the patch merged in or it becomes impossible to use the current patch (in which case not sure what I will do then).

Thomas, I answered your question.  It would simply be common courtesy to answer mine.

(In reply to comment #50)
> but the developer has taken a childish "I'm right and you all are
> wrong" stance

Now is enough.

I quit the discussion because
* Wes claimed the justification of the behavior was that borders would waste screen space,
* i stated explicitly that this was a false claim and all talking has been about occupying the screen edges for no actual reason and 
* the next thing was Alex showing up by "Has anyone looked at how much space is really going to be saved by overlapping the borders?"


That is not 'childish "I'm right and you all are wrong" stance', but simply that i do not intend to waste my time on OBVIOUS trolling.

(In reply to comment #47)

> Dance around the syntax however you like
That has nothing to do with syntax. "Wasting space" is fundamentally different from "wasting screenedges".

> Why are the screen edges valuable?
As pointed out several times in this bug, because of their infinite space (reg. fitts law)

> particularly "valuable", that is your personal opinion.
No, i fear not.
http://en.wikipedia.org/wiki/Fitts's_law

--------------------------------

> I am stating a reasonable concern.  If you feel this is a waste of your
> time

Seriously?

"What you did was to turn a relative into an absolute."

AND YOU TRY THE SAME LOUSY TECHNIQUE AGAIN?

> I am stating a reasonable concern.  If you feel this is a waste of your
> time

"None of those tricks are gonna work on me, ever.
And since the only point about eristic dialectic is to maintain your position despite you're wrong, it's neither productive in any direction - what bothered me more than having to memorize it."

"You can state any reasonable concern on topic anytime, but stop wasting my time, ok?"

> I am stating a reasonable concern.  If you feel this is a waste of your
> time

SERIOUSLY?

-----------------------------

> 1.) Aesthetics
on the screen edge in particular?

> 2.) To keep content in my various windows aligned
they all snap the same

> 3.) Visual feedback of end of content
The only valid, yet questioned, argument. Actually. And discussed in the very beginning of this.

> Why precisely do you require window decorations to be non-visible?  
The visibility is irrelevant. The point is to align the window content to the edge. To quote myself from comment #28 (...)

> > This is not about scrollbars in particular.
> > The ratio here is /very/ simple.
> > The screen edges have an infinite area, turning them the most valuable > > regions for mouse interaction.
> > Snapping to the window decoration "wastes" this area for the
> > decoration - where also the only possible action is to remove the
> > decoration from the valuable area...

> > It can not be utilized by clients eg. for autohiting panels (inside the 
> > client), or tolbars, or ... or -in just many cases- the scrollbars.

> > This is the argument you have to defeat. Or, positively:
> > Why does it make sense to have esp. the window borders at this 
> >  position, which can be not used for anything else but to be removed
> >  from that position?

I'm not trying any tricks; I'm not trolling.  Honestly, I have other things I could be doing right now (just ask my wife), but I'm pursuing this because it's important to me.  I spend 8 hours or more each work day using KDE; it's important to me that it work well and consistently so that it makes me more productive and does not become a hindrance.  I'm asking questions, answering questions asked of me, and providing feedback related to a behavior I do not understand.  Just a simple dialog.

I read your link to Fitt's Law.  Thank you.  That actually does help to explain some of the missing plot holes here.  It had only been mentioned once before in this bug and not given much attention.  Let me paste here what I believe to be the critical point from the Wikipedia page for others who may not read it:

"Edges and corners of the computer monitor (e.g., the location of the Start button, Taskbar and a maximized window's Close button in Microsoft Windows; or the menus and Dock of Mac OS X) are particularly easy to acquire with a mouse, touchpad or trackball. Because the pointer remains at the screen edge regardless of how much further the mouse is moved, they can be considered as having infinite width."

Okay, that makes sense.  Dumbed down a bit, "It's easy to click on things on the edge desktop."  So logically it makes sense to put important content on the edge of the screen.

1.) For my workflow though, you are now putting the "important content" off screen in some instances.  The majority of my windows at any given time are RXVT terminals; simple black boxes with text.  While I have a very thin scroll bar on the left of each terminal, it's hardly ever used.  Essentially, I have nothing inside the window borders to click on.  There is no content inside the border of the window that is made easier to acquire with this new behavior.  If I'm clicking on a window, it's usually because I want to move it or resize it by grabbing a border.  I realize the borders in question here are already at the edge of the desktop and unable to extended any; that point is not lost on me.  I'm not at work right now to test this physically, but over VNC it does appear you can still grab the borders that are off-screen if you wanted to shrink a window, but this is hardly intuitive.  Basically, my point is that sometimes the borders are the "important content" you want to click on.

2.) Borders provide instant visual feedback that the content of the window has ended.  Does that window on the right edge of my screen actually stop at the edge or did I mistakenly place an extra wide window too close to the edge and now content is off-screen?  Not impossible to figure out from other visual clues, but the absence of a border just makes this more difficult.

3.) Aesthetically, I just find it ugly.  If I put four identical windows in the four corners of my desktop*, each one appears differently based on the edges they touch.  Some have a border on the left, some have a border on the right, some have a border on the bottom, some do not.

4.) Additionally, when testing this behavior earlier today, I found that if you have a ridiculously thick border on a window on the left edge of the desktop, the system menu can become inaccessible.  Similarly, such a window snapped to the right edge may lose access to the close button.

#1 and #2 are learned behaviors ingrained in me from over two and half decades of working on computers.  Work-arounds for each are available; new behaviors can be learned.  But why?  The value you have suggested simply does not exist for me.

#3 is obviously a matter of opinion.  It is provided simply as feedback from a (non-paying) customer.

#4 is truly bad behavior.  It doesn't affect me personally, I just happened to find it while experimenting.

Seriously, I don't mean this as an insult, but given the number of places where changes to behaviors were forgotten or missed to implement this change consistently, it doesn't really give me the feeling that a lot of effort was put into the design and testing of this change.  I can't speak to the effort to implement the change since I'm not a programmer.  It seems hasty and was obviously incomplete.  Myself and others have been able to quickly identify inconsistent behaviors in a KDE release.

Computing for me these days is less of a hobby and more about productivity.  KDE still allows me to be the most productive I can be, but issues like this distract from that just a little bit.

I don't think anyone is suggesting that this functionality be removed.  It probably makes sense for some people but is demonstrably nonsensical for some.

I would argue that it should not be the default behavior.  A usability change like this needs more time to mature.  If I am fated to lose that argument though, could the concession at least be made to make it toggle-able?  I agree with the previous statement that it should be an either/or toggle though.  Either snap to border or snap to content; snapping to both border and content could get crazy difficult with thin borders.

Thank you for your time.

* This is especially easy since I recently discovered KDE's "drag to the corner" functionality to resize and place windows, although I just found this still places windows with the borders visible.

Created attachment 82277 [details]
Missing buttons due to think borders and client snapping

A visual of the missing buttons with thick borders.  Window on the left has inaccessible system menu.  Window on the right has missing close button.

Created attachment 82278 [details]
Window extending beyond edge of desktop

In this example, one of windows on the right of the screen extends past the desktop edge.  The lack of a border on the right hand desktop edge makes a quick visual discovery of such a window much more difficult.  Not impossible, as the buttons in the titlebar provide a clue that something is amiss, but certainly much more difficult.  More difficulty, no added value.

Created attachment 82280 [details]
Other UI elements off screen

Other UI elements still use the width of the decorations in determining the ultimate size of the window.  Elements drawn at (0,0) may be clipped by this new snapping behavior.  In this example, the coordinates shown when moving a window are impossible to read.

If KDE policy is now that window decorations can/should be ignored in certain circumstances (I don't see any mention of this in the KDE HIG), ALL UI elements need to adapt to this change.

(In reply to comment #56)
> I'm not at work right now to test this
> physically, but over VNC it does appear you can still grab the borders that
> are off-screen if you wanted to shrink a window, but this is hardly
> intuitive.

I was incorrect.  You cannot grab the off-screen borders in order to shrink the size of an edge-snapped window.

(In reply to comment #58)
> Created attachment 82278 [details]
> Window extending beyond edge of desktop
> 
> In this example, one of windows on the right of the screen extends past the
> desktop edge.  The lack of a border on the right hand desktop edge makes a
> quick visual discovery of such a window much more difficult.  Not
> impossible, as the buttons in the titlebar provide a clue that something is
> amiss, but certainly much more difficult.  More difficulty, no added value.

My panels are at the top of my screen.  A window extending beyond the bottom edge of my desktop gives no visual indication of off-screen content.

(In reply to comment #58)
> Created attachment 82278 [details]
> Window extending beyond edge of desktop
> 
> In this example, one of windows on the right of the screen extends past the
> desktop edge.  The lack of a border on the right hand desktop edge makes a
> quick visual discovery of such a window much more difficult.  Not
> impossible, as the buttons in the titlebar provide a clue that something is
> amiss, but certainly much more difficult.  More difficulty, no added value.

Additionally, if another window is covering the title bar of a window extending beyond the right edge, once again I am left with no visual indicators of off-screen content.

I fully agree with you in all points, Wes. I think that snapping to window content rather than the window border is an inherently BAD idea.

I'm using the QtCurve window decoration with a somewhat larger border, and with the new snapping behaviour, a good part of my window menu button is cut off now. As I don't want that, snapping to screen borders is completely unusable to me. I always have to stop moving windows a short distance from the screen border and then drag the window border so it properly aligns with the screen border - quite the nuisance.
The "Initial placement" window rule has become unusable now as well, as it will likewise move the window too far off to the left, and I end up with a cut off window menu button as well.

It feels particularly bad that we get such a major usability change forced down out throat, if we want it or not, without trying it out before and without asking for user input. I thought I left the "Broken by design" land when I left Windows.
It also feels really bad that all the reaction we get from the devs to our complaints is that they play ostrich and stick their head in the sand, simply labeling everything as "Invalid".
I am clearly NOT AMUSED here.

"If you don't believe that Fitt's Law trumps all other usability arguments, then you're just stupid and wrong and not worth talking to." That seems to be Thomas's stance.

And even if Thomans considers it a good thing if parts of the windows are outside the screen, I'm sure that cannot be applied to windows snapped to the edge beween multiple monitors.

I found this bug report googling about kde 4.11 and the new behaviour about snapping windows near screen edges. I think that gain some pixel in a screen with 1900 or more horizontal pixels is irrelevant, but the effect introduced by this new behaviour is, for me, really annoying.
I read the previous messages, and I'm really disapponted about the "Resolved invalid" status, and by the tone taken by the discussion.
The new behaviour is particularly annoying in konsole windows, where the fonts (I prefer Misc Console, instead of default) are attached to the screen edge, so I constantly reposition windows to get back window border.
If you could consider to add an option somewhere to get back the old behaviour I would be very happy. Alternatively, also I provide to modify the code for my workstation.
Thank,
Alessandro Sturniolo

(In reply to comment #64)
> "If you don't believe that Fitt's Law trumps all other usability arguments,
> then you're just stupid and wrong and not worth talking to." That seems to
> be Thomas's stance.

Yes, seems just that way. Very, very sad.

> I think that gain some pixel in a screen with 1900 or more horizontal
> pixels is irrelevant, but the effect introduced by this new behaviour is,
> for me, really annoying.

True. I use 1920x1200, and moving the window borders offscreen just to gain a tiny amount of pixels is just ludicrously stupid. The only instance where I could see this making sense would be on very low-res smartphones (e.g. 320x480), where every pixel counts, but certainly not on desktops. Even on lower resolutions like the common 1280x720 one, the few pixels gained by moving window borders offscreen is nothing but laughable.
Also, gaining a tiny amount of pixels certainly isn't a good recompense for having the window menu button cut off, and things looking very ugly in general.

For the now broken "Initial placement" rule, there's at least a workaround: on the "Size & Position" tab, use "Position" instead of "initial placement". Just enter 0,0 as the coordinates of the upper left window corner, and the window will be properly placed in the upper left corner, with window borders fully visible, as it should be.
Please note: The "Position" rule doesn't take any panels into account. If you have a panel at the upper screen border, add the panel's height to the coordinates, e.g.: 0,64. If you have a panel on the screen border, add the panel's width to the x coordinate, e.g.: 64,0.
Also note that the "Position" rule sets the window position permanently, so you will not be able to move the window. I also recommend to set this rule only for the window type "Normal window", so dialogs etc. aren't fixed to that position as well.

(In reply to comment #66)

> I read the previous messages
No, you did not, because

> snapping windows near screen edges. I think that gain some pixel in a screen
> with 1900 or more horizontal pixels is irrelevant, but the effect 

You then had read comment #54 on this being a falsely claimed argument, only to be counterproofed as pseudo argument against the change.

An THIS is in particular why this Troll lair was abandoned.

The actual concerns (esp. also from comment #56) have been filtered out and the topic under development progress (for consisntency and the actually only valid reason: "users cannot be expected to be any rational")

However this aparently HAS TO happen with explicit troll bypassing and does happen DESPITE all the nonsense talk here around like eg. comment #64 which is exact the same kind of made up counterargument that renders *any* attempt of a seriously reasoning lost hope, since most ppl. here seem to be mainly interested in argue, not reason.

You can keep trolling around here and claim as much bullshit on intentions and reasoning as you want - that just stresses the tagging of this bugreport as INVALID since it's no bugreport but turned into a troll lair long time ago.

Thomas Lübking: don't you agree that it is undesirable that the decoration of windows snapped to the border between two screens protrudes onto the other screen? Or is this effect really wanted with the new behavior?

(In reply to comment #69)
> Thomas Lübking: don't you agree that it is undesirable that the decoration
> of windows snapped to the border between two screens protrudes onto the
> other screen? Or is this effect really wanted with the new behavior?

If you had actually tracked this "report" (what is granted to be hard) or just checked the linked review request (not so hard), you would not  have had to ask this question.

So, don't you agree that this "report" became completely useless?

 > If you had actually tracked this "report" (what is granted to be hard) or
> just checked the linked review request (not so hard), you would not  have
> had to ask this question.
> 
> So, don't you agree that this "report" became completely useless?

I must say that I find your tone of voice patronising and offensive. And by that I mean not just that one post, but the whole report.

Yes, you are, correct, it seems tis has become a futile endeavour here, but not entirely without your participation.

Stefan, what Thomas is trying to say is that a fix for that has already been submitted and is being reviewed.  You do not need to keep bringing it up.

Thomas, it's not trolling for people to disagree with you or not understand your position.  It's not trolling for them to not understand your vague references to external sources.  You've done a terrible job of actually explaining yourself and your position on this bug in favor of just calling everyone idiots.  In 70+ comments, I'm the only one who has presented any reasoning at all for _your_ position -- and I disagree with you.  You've had your chance to defend your ideas and you won't.  Or can't.  I don't know which.

Beyond this behavior being undesirable by many people, there are real usability bugs that I have identified and which you seem not to understand or care about.  Since you seem determined not to fix any more bugs, I am going to clone this bug with the hopes that another developer will want to address the problems you've created.

(In reply to comment #72)

> It's not trolling for them to not understand your vague
> references to external sources. 
No, but it /is/ trolling to come up ever and ever again by assigning me a false argumentation just to show how dumb it is, even despite I explicitly stated on that this particular argument has never been taken.

>  You've done a terrible job of actually
> explaining yourself and your position on this bug

Like in the second part of comment #28?

"Now on actual ratio:

> The argument about "aligning scroll bars" is really weak, in my opinion. 
This is not about scrollbars in particular.
The ratio here is /very/ simple.
The screen edges have an infinite area, turning them the most valuable regions for mouse interaction.
Snapping to the window decoration "wastes" this area for the decoration - where also the only possible action is to remove the decoration from the valuable area...

It can not be utilized by clients eg. for autohiting panels (inside the client), or tolbars, or ... or -in just many cases- the scrollbars.

This is the argument you have to defeat. Or, positively:
Why does it make sense to have esp. the window borders at this position, which can be not used for anything else but to be removed from that position?"


> in favor of just calling everyone idiots.
A term that i did not use even once, thanks for continuing the strategy to assign false things to me.

> You've had your chance to defend your ideas and you won't.
... and here as well.

If you believe that is a smart stragegy to get me more cooperative:
you're wrong.

Even if your argument were completely right, Thomas, and even if the arguments of every other person posting here were completely wrong, there is one fact that you cannot argue against: there is a significant number of users who dislike the new behavior. That alone should lead you to offer it as an option.

I'm sorry, you are correct.  You did not explicitly call anyone an idiot, but you have called multiple people "trolls" and labelled arguments against this change as "nonsense" and "invalid".  Either way, your strategy has simply become name-calling and inaction.

Maybe it's just one of those "lost in translation" things, but your defense of your "ratio" is still pretty weak.  Kind of like speaking English louder does not help a non-English speaker understand you, pasting your comment again doesn't make it any more understandable or any less wrong.  And FYI, it's "rationale", not "ratio".

ratio : the relationship that exists between the size, number, or amount of two things and that is often represented by two numbers
rationale : the reason or explanation for something

"Snapping to the window decoration "wastes" this area for the decoration - where also the only possible action is to remove the decoration from the valuable area..."

Your rationale is very simple, but it's also very wrong.  *I* understand why the desktop edge is considerable valuable.  *You* need to understand that window decoration can also be valuable.  The "only possible action" is not to remove the decoration; you could also leave it there.  If you want to remove the decorations from your windows, mechanisms already exist to do that.  Why is it necessary to remove my decorations as well?  How does this benefit me?

This is the argument you have to defeat.

(In reply to comment #75)
> The "only possible action" is not
> to remove the decoration; you could also leave it there.  If you want to
> remove the decorations from your windows, mechanisms already exist to do
> that.

I think what Thomas means is that, if your window border is at the edge of your screen, then the only possible way in which you can interact with the edge of the screen is to remove the window border from it (by resizing the window). He believes other uses (client uses) of the screen edge are more important than the ability to resize a window.

Since version 4.11 I'm annoyed about this ugly behavior.
I don't want to have parts of a window on screen 2, when snapping to the edge of screen 1.
For me the only workaround was to disable snapping at all.
I don't see a reason for discussing this behavior as a benefit, it shouldn't be different from snapping two windows together !

>  there is a significant number of
> users who dislike the new behavior. That alone should lead you to offer it
> as an option.
sorry no, there isn't. This bug report has now, let's check around 80 comments 
and 9 people in CC. That's not a significant number compared to the millions 
of users we have. Sorry to break it like that. It's what is often referred to 
as the strong vocal minority.

Improvements are on the way (see reviewboard) and I would highly appreciate if 
the pointless discussion would stop till the improvements have reached your 
systems. Also feel free to try out the patches on reviewboard and provide 
constructive feedback (and no, just going back to the old solution is not 
constructive).

> Why is it necessary to remove my decorations as well?  How does this
> benefit me?
> 
> This is the argument you have to defeat.
Sorry, but no, we don't have to defeat this argument. KWin is not developed 
especially for you, but for millions of users. We as the developers try to 
find solutions which fits as much people as possible, but we don't aim for 100 
% - that's just impossible and not a good advice. A recommendation a 
psychologist specialized in that area once mentioned to me that one should aim 
for about 90 %. It's sad if you are in the less ten percent but if therefore 
90 % can use the software in a more efficient way, it's the best we can have. 
It's awesome if users can see the benefit even if they do not like the change. 
If they can transit into others and see that it can help. Moving away from the 
"I" to the "we". It's difficult, but it's possible. We as developers have to 
do it all the time.

And on the same argument: free software is also about scratching ones own itch 
and especially KDE is a meritocratic society. This means those who do decide. 
So if we think that it should be that way, we decide that it should be that 
way. It's not a democracy where we let the users vote (which is impossible 
given that we don't have any means to invite all users), but also not a 
dictatorship as some other free software projects.

I've found far more outcry against the new behavior than I've found for the behavior.  Where are the feature requests (from your millions of users) asking for this?

KDE is one of the most configurable pieces of software I've ever encountered, that's what has drawn me to use it for the past 15 years.  I fail to understand why such a hard stance must be taken on this particular point.

If decorations are so unimportant and only get in the way, why not get rid of them entirely?  At least that wouldn't look broken.

My fix for this bad behavior is simply to put panels around my entire desktop.

(In reply to comment #80)
> My fix for this bad behavior is simply to put panels around my entire
> desktop.

Brilliant! Thanks for the tip!

My dear Mr Gräßlin, your argumentation is just as ludicously absurd and stupid as the crap you usually hear from CDU politicians.
Yopu're no bit better than Mr "anyone who has an opinion that's different from mine is a troll" Lübking.
(Mr Lübking's behaviour makes me really want to play "Danger Mouse":
"Lübking ist ein unerschütterlich feiger Hamster. Eine große Hilfe ist er aber selten. Lübking gibt vielmehr immer wieder gern den kompletten Ignoranten und Trottel vom Dienst, was dann in unregelmäßigen Abständen Danger Mouses liebsten Ausspruch, "Lübking, Schnauze!" zur Folge hat.")

Where are the people who asked for this new, broken snapping behaviour? There aren't any!
It's only a deranged idea that developed in your twisted minds after a bad drug trip, nothing else.

Where are the people who praise you for breaking snapping with the new behaviour, resulting in ugly stuff like cut off window buttons and such? There aren't any!
_No one_ likes your new snapping behaviour, it's only you and Lübking who are vociferously defending it, while everyone else says that they don't like it.
As such, it's clearly _you two_ who are the vocal minority.

> It's not a democracy where we let the users vote

In short: "We do whatever we damn please, and if you don't like our crackpot ideas, shut the fuck up, because we don't give the slightest damn about what anyone thinks about it."

If I wanted to have retarded stuff forced down my throat without having any say in it, I could've stayed with Windows... Althoug, it's also very common with Gnome nowadays as well. It's very disturbing however to see that the Kde devs are suddenly starting with it as well.

As Wes already said, we like Kde because of its configurability. If you suddenly start introducing crackpot ideas that no one likes (except you devs) without the ability to turn them off, I have to fear that Kde 5 will be for Kde 4 what Gnome 3 was for Gnome 2: a greatly dumbed down version with only little configurability left.

(In reply to comment #82)
> Danger Mouses liebsten Ausspruch, "Lübking, Schnauze!" zur Folge hat.")
The sidekick is named "Lübke" - you could not even get that right, could you?

Anyway, thanks for proving once more that you're not interested in a constructive or even just serious discussion or reporting a bug but just trolling around and wasting other peoples time.
It didn't really work, but was a nice try nevertheless. Farewell.

> Where are the people who asked for this new, broken snapping behaviour?

You assume that we at KDE only add features our users request. Sometimes we also implement features that we want ourselves.

ah it seems that I have to modify my sieve scripts to mark all further notifications to this bug as read so that I don't see them. Very sad, that's the first time that I'm going to do that.

> thanks for proving once more that you're not interested in a constructive or even just serious discussion or reporting a bug but just trolling around and wasting other peoples time

I'd say you're describing yourself very well there. Right from the very beginning, you weren't at all interested in a serious or constructive discussion. People were pointing out that the "feature" you implemented is badly broken and even provided pictures proving that it is badly broken.
The only thing you did was completely ignoring any (fully justified) complaints and calling this bug "invalid". Then, because you didn't have any real arguments to defend your badly broken "feature", you started calling everyone complaining about it a troll. That's just pitiful.

> Sometimes we also implement features that we want ourselves.

The problem here isn't so much that you implemented a "feature" that no one wanted, without asking anyone beforehand if implementing it would be a good idea.
The problem is much more that the "feature" you implemented is badly broken.
On the official homepage, it says, "Experience Freedom". If those aren't just empty words, you should permit users to turn off this badly broken "feature".
In the Gnome world, there's no freedom: "Let's implement broken by design features that no one wants, and then force them on anyone without the ability to turn them off again." That's one of the reasons I really can't stand Gnome. It makes me really sad to see that this nonsense seems to be entering the KDE world now as well.

I fully agree with wes's reasoning. I have been working with this "feature" for several days and the "feature" is not only completely annoying but also partly broken. I vote for an option to disable this "feature".

(In reply to comment #87)
> I fully agree with wes's reasoning. I have been working with this "feature"
> for several days and the "feature" is not only completely annoying but also
> partly broken. I vote for an option to disable this "feature".

Your vote doesn't matter. The developers are not interested in giving you a choice on this matter apparently. (I'm not sure why. KWin has options for less intrusive "features" than this.)

Git commit 3adca1a4e6afa4a8b9f3308f89db053b66146cb2 by Thomas Lübking.
Committed on 15/08/2013 at 09:54.
Pushed by luebking into branch 'KDE/4.11'.

snap to deco, not client on inner screen borders

client snapping is ultimately reasoned by fitt's law
and inner borders are not infinite
FIXED-IN: 4.11
REVIEW: 112103

M  +13   -8    kwin/geometry.cpp

http://commits.kde.org/kde-workspace/3adca1a4e6afa4a8b9f3308f89db053b66146cb2

Thomas, that commit fixes bug 325184, right? I guess part of the confusion is that multiple issues were reported in this bug. The title seems to suggest the reporter wanted to report the multiple screen issue, while the description talks about the decoration snapping inside instead of outside (even not between screens).

Yupp, i just had the "wrong" bug still in the commit message.
Sorry for the confusion.

And to spare Martin the further comments....

Could be I'm missing something, but…

> Why does it make sense to have esp. the window borders at this position, which can be not used for
> anything else but to be removed from that position?

How about resizing the window? ;-) I know there are other ways to do it, but having the border be positioned outside the screen means that one can't resize that edge easily by mousing over that border. Which means a single-step operation becomes three: move window, resize from that border, move it back. That's a few seconds of wasted time and productivity every time it happens.

I see the rationale behind this, and I even see where it can be useful. But I think others have good points, such as the border being a useful indicator that some window content hasn't been accidentally positioned off the screen.

Given the amount of controversy over this, it seems that there are enough people feeling strongly about the issue to make having it be an option reasonable.

Yes, of course the main point of the borders is to resize the window, but the question would then turn why one would want to snap a window to a screen edge in order to resize it? "To profit from Fitt's law" would be a bit questionable (since you would "invoke move/resize/move back" instead of just "resize" and of course largely be trumped by alt+rmb)

There's no chance for options in KDE4 anymore (frozen) but there's http://kde-look.org/content/show.php/Snap+To+Deco?content=160851

Admittedly, resizing like that probably isn't a common case. Though since it was something I ran into at first (had a window on the edge and wanted to shrink it toward the center to make room for another window), I thought I might mention it. It doesn't (yet, at least) bother me too much, personally; it actually did more when I thought it was a bug rather than an intentional feature with some benefits. :-)

The script is a neat way to handle things without even requiring recompiling. :-) Kwin scripting isn't something I've looked at much yet, but it certainly sounds interesting.

I use the window frames to raise windows (I have kwin configured so clicking in the client area doesn't do that) - but that becomes much trickier if you contrive to snap them off the screen.  I too would love the option to select the old behaviour.

This forced change is disfunctional for me (I can't resize from borders) and ugly as hell (window decorations with rounded corners are clipped in the middle of the curve).

I can't believe this bug was closed without even implementing an option.
This is a GNOMEish attitude, I would have never expected from KDE.

Can someone point me to the commit implementing this atrocity? It's time to patch my KDE myself, it seems. :-(

Why is this bug closed?

With the current behaviour it is impossible to resize windows from the edge that snapped outside the screen. Now you always first have to move it a little bit e,g, to the right, then you can resize it, then you move it back.

"... why one would want to snap a window to a screen edge in order to resize it?"

And yes, those windows sometimes just snap to the edge allthough you don't want to, beause you know you would need the border soon. But I'm using my computer for work, not playing around with it, so windows movements are doen quickly, if not to say in a hurry.

And no, having displays with almost 2000 pixels in every direction, those saved 10 pixels of the border are not worth that trouble. If you would have made that "feature" configurable I wouldn't complain, except it unnecessarily increases code size, might add avoidable bugs, etc.

And last not least, those unsymmetrict and cut off windows just look ugly. Your brain always thinks you moved them too far to the left or bottom (my panel ist at the right screen edge).

Created attachment 83383 [details]
Windows Decoration Button almost moved off the screen

And just talking of avoidable bugs: by snapping the button in the windows decoration is almost moved off the screen, unreachable (see red button).

This is KDE 4.11.3 from the opsnSUSE 12.3 repos.

Snapping to client on inner screen borders does not happen and martin closed this bug because it turned into an unreasonable flamewar.

Open bug/wish is bug #325286 - which will certainly become an unreasonable flamewar since i now linked it here :-(

Hello,

I'm currently using KDE 4.12.1 and I am still facing the issue that one of the lateral window borders disappears when the window is snapped to a screen border.  Snapping with 2 windows works fine and does not make the border of any two window disappear.

Although I understand the importance of screen edges, windows borders are more useful with my typical usage pattern which is a kind of window tilling.  I like to be able to resize a widow with any border (left, top, right, bottom) without having to first move it.  When a window is snapped to a screen edge, one must first move it away from the screen edge to make the border visible.

I really like the "Tile windows by dragging them to the side of the screen" option in "Workspace Appearance and Behaviour" -> "Workspace Behaviour" -> "Screen Edges".  When I drag a window to a screen edge, it gets positioned as I expect with all border visible.  However, as soon as I move the window, it's size returns to whatever it was before I dragged it to the screen edge.

My question is the following : Is there a work-around in KDE 4.12.1 that would allow me to prevent windows from being snapped to content instead of the border when snapped to a screen edge?  I'm not asking to add a configuration option, I just want a way to replicate the old behaviour.

All help in this matter will be appreciated.

(In reply to comment #101)
> My question is the following : Is there a work-around in KDE 4.12.1 that
> would allow me to prevent windows from being snapped to content instead of
> the border when snapped to a screen edge?  I'm not asking to add a
> configuration option, I just want a way to replicate the old behaviour.
Yes, install the kwin script. It's mentioned in one of these comments.

Just for anyone coming here from google, the temporary solution is to download a kwinscript. There are currently two different versions, try either:

        http://kde-look.org/content/show.php?content=160851
        http://kde-look.org/content/show.php?content=163333

Once downloaded, the script needs to be installed via

$ plasmapkg -t kwinscript -i filename.kwinscript

which unpacks and copies files to ~/.kde4/share/apps/kwin/scripts/ but doesn't activate them. In order to activate, use the scripts KCM (KConfig Module) graphical interface:

$ kcmshell4 kwinscripts

and tick the required script.

Big thanks to Andrew and Tino for the helpful info!  It's just a few pixels, but it makes such a huge difference!

(In reply to comment #103)
Thanks very much, Tino, for the easy-to-follow instructions. 163333 worked great for me.

Created an account just to say:
-Thanks Andrew and Tino, saved the day, after I nearly tore my hair out thinking somehow the new version of X (I just upgraded to Slackware 14.2) was to blame. 

-Thomas and Martin - wow, really? KDE has been so good for me, I never in my wildest dreams thought it was KDE moving my konsole window over too far to the left. And when I found it IS KDE, you guys are basically like "everyone else is wrong, we're right, STFU!". Not very encouraging. I would really recommend you make this an option in a new release.

In fact, I'll put my money where my mouth is: if the option to revert to the "normal" behavior (snap to decoration) becomes an option in a future release instead of having to install a KDE script (i.e. I can change it on any KDE system I use out of the box), I'll donate 20 Euros to the KDE project. 30 if I can get a tax deduction in the US :-)