just a few comments: we cannot introduce any options in the life time of 4.x. The earliest version is the first version on top of KF5 and there it has currently no priority at all with config modules still disabled at compile time.

Then I don't think that this qualifies for a config option at all and would just make the code too complex. We have to see what will be the future of window decorations in any case with GTK just deciding to go for client side decorations.

Since terminal is coming up ever again and another report points "4 rxvt windows in all corners" explicitly and leaving aside any questions on why the border would be really important[1]:

    Is this about more or less tiling setups?

(Otherwise "terminal" is itself not very special, eg. Konsole shows a scrollbar by iirc even default - though i turn it off ;-)

Ie. would eg. a script that places all available konsole (pick your fav. term emu) windows on the proper VD and the proper layout and position do what you actually want to do - and better (more comfortable)

[1] since regardless of all claims: "am uncomfortable with the different look & feel / don't trust the snapping" is irrational but still an acceptable reason.

No, it's not just about tiling setups. I just prefer my terminals on the bottom-left or bottom-right corner.  A terminal app is a good example for the issue about no visual feedback on client-area-end without a border, most other windows are obviously "off screen" or "on screen just without border". (My konsole doesn't have a scrollbar on either side btw, that just takes away useful screen area, so I disabled it)

But regardless of the issue of the above issue, missing borders are just plain ugly in my opinion, so I'd gladly give up any gains coming from "Fitt's Law" to get my borders back... The only application where it's semi-useful for me is my web browser which I happen to keep on the right side, but if it were on the left, it'd be no gain at all. That's why I'd prefer a global default and a per-app / per-window override, but apparently that's not going to happen with 4.x.

Would it be possible to add a special shortcut then if configuration options are not allowed? Something like Alt-Drag for the new content-snapping move and Shft-Alt-Drag for the old deco-snapping move?

Or, if it's easier, a config-file toggle instead of a GUI one? Is that also forbidden for 4.x?

Your script idea is also a possible workaround if it could do a "snap to deco wherever the window actually is", and not just place the window to a hard-coded location. I'm not familiar with kwin scripting, is something like that even possible?

(In reply to comment #3)

> Would it be possible to add a special shortcut
No, same issue.

> Something like Alt-Drag for the new content-snapping move
> and Shft-Alt-Drag for the old deco-snapping move?
Absolutely not in the cards. WMs can have Alt & Meta for traditional reasons - and even that causes conflicts with some applications. Shift+LMB will cause many bug reports far more severe than this here.

> Or, if it's easier, a config-file toggle instead of a GUI one?
Same issue.
(Also is in general avaoided as typical "personal private config option" - GUIless config options are usually only utilized for "settings nobody should ever really have to touch unless the developers want users to try something to determine implementation issues or to workaround broken hardware/drivers")

> Your script idea is also a possible workaround if it could do a "snap to
> deco wherever the window actually is", and not just place the window to a
> hard-coded location. I'm not familiar with kwin scripting, is something like
> that even possible?

"In a way" - what's atm. possible is to catch a window move, check whether a "small fraction" is outside the screen and move it back to screen bounds.

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

Notice that bleeding on multiscreen is fixed in 4.11.2 anyway.

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

> A terminal app is a good example for the issue about no visual
> feedback on client-area-end without a border,

That's actually a more general issue.
KWin decorations support modes without sideborders or any borders. Also kwin supports a completely undecorated mode.

(In reply to comment #4)
> 
> "In a way" - what's atm. possible is to catch a window move, check whether a
> "small fraction" is outside the screen and move it back to screen bounds.
> 
> http://kde-look.org/content/show.php?content=160851
> 

Thanks, that script (along with the coming multi-monitor patch) fixes the issue for me. I'd still leave this issue open for 5.x though as a reminder.

> That's actually a more general issue.
> KWin decorations support modes without sideborders or any borders. Also kwin
> supports a completely undecorated mode.

Well, obviously the folks that use a no-borders-setup with kwin are not the ones who'll come here complaining about the snap-to-content change ;)

anyway, thanks again for the quick hack on that script.

ps: might be a good idea to add a link to the script to the previous "flame-war" bugs, too...

(In reply to comment #5)

> Well, obviously the folks that use a no-borders-setup with kwin are not the
> ones who'll come here complaining about the snap-to-content change ;)

No, but the task is to improve KWin, not to please protesters.

If the inability to notice in screen bounds is a problem, it contradicts those decoration setups. It (as only reason) may prevent ppl. from using them, or render those setups useless altogether (while i wonder how many ppl. would complain if we enforced sideborders ;-)

So a general resolution is clearly preferable to a side effect bypass.

> anyway, thanks again for the quick hack on that script.
No sweat.
Was an ideal mind ping-pong towards an acceptable immediate resolution.
If you're still and really interested in a (configurable) list of exceptions/inclusions i'd add that with an update.

(In reply to comment #6)
> No sweat.
> Was an ideal mind ping-pong towards an acceptable immediate resolution.
> If you're still and really interested in a (configurable) list of
> exceptions/inclusions i'd add that with an update.

No, thanks. The current behavior (with the shortcut to toggle) is perfect for me, thanks again.

Is there any way to have that script also adjust window positioning on initial creation/placement?  At the moment, for the script to take effect, after a window is placed I often have to move it once, otherwise one if its borders remains off-screen.  This happens pretty commonly with the "Smart" placement mode.

Sure, see updated v1.1.

Works great, thanks.

(In reply to comment #6)
> No, but the task is to improve KWin, not to please protesters.

Well, I for one simply don't understand the motivation for this change -- all you gain is a handful of pixels of screen real-estate, at the cost of disorientation.  This might benefit mobile devices, but I doubt that you'd be using non-fullscreen windows on those anyway.
 
> If the inability to notice in screen bounds is a problem

To me it really is -- I'd greatly appreciate it if KWin were to revert to the previous behavior!

(In reply to comment #11)
> all you gain is a handful of pixels of screen real-estate, at the cost of
> disorientation. 

This is the dumb bullshit argument that has been insinuated on the closed bugs over and over again - despite multiple denials.

To state that here again and clearly and once only (bring it again and the bug is closed as well, i'm sick of this game)

         It has *nothing* (NOT A THING!) to do with screen estate. Period!

The point to snap to the client is to allow the clients to profit from the infinite width of the screenedge (reg. Fitts' law).

This can mean to improve access to scrollbars or client internal autohiding panels or just toolbars or whatever else valuable GUI stuff they may put at their edges.

The rationale is that the only mouseinteraction with the border will lead to a repositioning of the border (move/resize the window) what means the only action that benefits from having the client at the screen edge is to remove it from the screen edge.
-> Clients will usually have a better use for it.

The problem for me is that without decorations on the bottom I do not know if the window actually extends beyond the visible screen, so I also don't know if I'm seeing all the content or not.

My opinion is that screen edges are something to be leveraged (Fitt's law, etc.) by the window manager, not by the content; the content should NOT be aware of edges or anything else; the window could be 3D rendered with an oblique perspective (or bubble deformed or split on multiple monitors) and the application should not assume anything in relation with the final rendered shape and position.
Please leave this "fullscreen app" mentality to other platforms or, at least, let me configure them out of my way (as I've immediately done with Vista-like screen edges).

The new snapping algorithm still has some disadvantages, no matter why they were introduced:

- the or some window decorations buttons (all themes?) move off the edge of the screen if you are using large borders

- with some windows that snap to the lower edge of the screen you can never be sure if you see all the content of that window, esp. when they e.g. don't have a status field or tabs at the bottom like e.g. konsole

- the unsymmetric look of windows snapping to either side of the screen are confusing, your cerebellum always thinks something is missing, or just that it looks ugly

Just a few more comments -- my apologies if they have already been discussed in one of the other reports.

If the main intent of this change is to offer window clients, i.e., applications, access to the edge of the screen, then this idea breaks in the following scenarios:

(1) If "Active screen edge actions" are enabled, moving the mouse pointer to the edge of screen will create conflicts between workspace and window behavior. This will make it difficult for applications to make use of the screen edge reliably, thus voiding the goal of this change.

(2) If the "Switch desktop on edge" option is enabled, the mouse pointer will not experience any resistance at the edge of the screen. Again, this will make it difficult for applications to make use of the screen edge reliably.

(3) Similar to (2), snapping to the edge in a multi-monitor setup will not give access to the edge, as the mouse pointer will not experience resistance at the edge.

(4) Even in the absence of (1) through (3), applications simply cannot rely on being positioned at the edge of the screen.

Consequently, I find it difficult to imagine application functionality that would make effective use of the screen edges.

Contrast this with the loss of visual information mentioned previously, which IMHO weighs much more than the aesthetic preferences also offered as counter arguments.

just encountered another issue with the snapping algorithm:
when I move a window toward the border snapping hides the respective deco. But when I resize the window toward the border this does not happen. So I end up with a highly inconsistent snapping behavior depending on how the window approaches the border, i.e. resize or move.

Also, Maximize Vertically and Maximize Horizontally align the edges of the decoration to the edges of the screen when logically (if you accept this misfeature) the edges of the client area should be aligned to the edges of the screen.

It's really sad that the snapping change was implemented so shortly before feature freeze of 4.x. v5 would have been a much better place to make such a change.

I understand that screen edges are high value, but don't understand at all the "infinite width" thing. Reading Wikipedia's Fitt's Law page, and another Fitt's Law page elsewhere, really didn't help.

Of all the reasons for or against the new behavior, the only one that matters to me is knowing unconditionally at a glance where the edge of the window is, which requires the border to be visible. Thus my wish is that if the old behavior cannot be optionally enabled, then the new should be reverted entirely.

I think that the behavior should be optional, because actually I rely on the borders being visible even when "snapped" for the following things:

1) Know whether I have more content outside the screen or not, without looking at the content itself, but just with a glance;
2) Resizing the windows from the edge of the screen.

I saw all the flames on the other post. Please don't disregard the "oppositions" point of view or weaponize this feature. Just put an end to all this mess, with an Enable/Disable option, for good.

I tested the snapToDeco script (http://kde-look.org/content/show.php?content=160851) but unfortunatelly it fails with Plastik, leaving 2 or 3 pixels between the window and the screen edge.

To install it, I used:
$ plasmapkg --type kwinscript -i 160851-snapToDeco.kwinscript

Thanks for the effort.

The developers are wrong here and this "feature" should be removed.

Fitt's law came about in 1954 before WIMP systems arrived and has been abused ever since.

This thing about about "infinite edge" has been implemented wrong due to a misunderstanding. A windows border is a control surface and as such should remain. Fitt's law has been abused to enable control buttons to still be clicked when the pointer has been moved to an edge. However, this should not mean that a windows border should be hidden when the moved to an edge, but it should mean that the control buttons should overlap the windows borders and not be contained within it. If it is implemented this way, then Fitt's law should hold under all scenarios instead of this limited implementation.

There is one law though that the developers have chosen to ignore here, one law that will always trump their argument and we have seen it argued here with the negative views. That law is the law of aesthetics. It does not matter how "better" a feature is, if it fails aesthetically then humans will reject it. Just as we see here.

I thought I would add my 2¢: I prefer having the border around mostly because my I used light characters on a black background for my emacs and konsole windows, and my laptop has a black frame, so without a border there is little visual clue to the end of the screen. 

Indeed, it bothers me much less in the firefox window I'm tying this in, which has a bright background, although æsthetically I find rounded corners on the right and a straight edge on the left rather ugle (as I never much liked the rounded stuff anyway, maybe a good reason to see if a different theme can get rid of it).

As I don't want to be negative, while I don't like the blue haze around screens (but, hey, it is configurable!), I thought in the top left it is very effective in showing that the corner is meaningful: to my children, it used to be very confusing to suddenly have all windows shrink because the mouse didn't seem to have moved anywhere special.

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

Without seeing the window border at the edge of the screen it's difficult to tell whether some part of the window is outside of the screen. Period. Fitt's law has nothing to do with this.

Have the developers conducted usability studies before shipping this change?

I can't grab the windowedge borders to resize the window anymore! :(

> I can't grab the windowedge borders to resize the window anymore! :(
you can always use Alt+right mouse button to resize anywhere the window. 
Borders are not needed at all.

Sure, that seems to work if I want to retrain myself to new habits... but habits are hard to change.

are you really talking about "i move a window to a screenborder to resize it on the border edge" or about resizing maximized windows? (for that, see bug #324011)

(In reply to comment #27)
> Sure, that seems to work if I want to retrain myself to new habits... but
> habits are hard to change.

Especially those requiring two hands to do what one used to. Actions requiring a mouse action and keyboard action in combination never even register here, much less get remembered. I find nothing good about the new behavior, and plenty bad.

(In reply to comment #28)
> are you really talking about "i move a window to a screenborder to resize it
> on the border edge" or about resizing maximized windows? (for that, see bug
> #324011)

Yes, the former. KWin spawns new windows on an edge usually (I find no fault in this), and if it's  bigger than I want, I usually grab that edge (it used to be easiest!) to resize it.

Next problem. With large window borders the outermost window decoration buttons (most of the times the window menu button) are not clearly distinguishable from the window border (resize) itself.

It's hard to select the proper operation when clicking on that area, sometimes the window menu opens, sometimes you get the double arrow that signals a resize operation. Sometimes, I do not yet know exactly why or how, I simply cannot get to the window menu, no matter how hard I try.

The new snapping behavior is infuriating for reasons already well articulated by other folks.  After having used window snapping on screen edges for years, I've now disabled it.  IMO it is a regression and my initial impression was that it was a bug.  I was both surprised and disappointed to find that the new behavior is intentional.

Please consider reverting the snapping algorithm in 4.x, then re-introducing the behavior in 5.x as a configurable option.

Just curious... I see the rationale for this change being quoted as "Fitt's Law", and understand the theoretical benefits, but which applications currently use this? I work in software design / development, so may not be a typical user, but haven't come across any applications which use edge-triggered events in the client area?

Could someone give me some examples of apps which use this - I'm just curious to see this behaviour in action in a real application, and how the client-area events interact with the edge-triggered auto-hide panels I have configured on my window edges.

Cheers,

For my use case, see bug 323504 comment #14. In other words, probably all applications that have a scroll bar. I know many people simply use maximized windows, but I like my windows only vertically maximized. I have also configured some applications to use the tool bar at the left window border, not below the menu bar to save vertical space.

Btw, if you are not using Thomas' script yet, you should try it.

(In reply to comment #34)
> For my use case, see bug 323504 comment #14. In other words, probably all
> applications that have a scroll bar. I know many people simply use maximized
> windows, but I like my windows only vertically maximized. I have also
> configured some applications to use the tool bar at the left window border,
> not below the menu bar to save vertical space.

Scroll bar? Seriously? Hasn't everyone had scrollwheel mice for at least like 10 years now?

But how can an application rely on been positioned at a screen edge?  This renders the complete change useless, particularly on large screens with lot of applications.

And how can a user know that the border of the screen is also the edge of the application? I will always have  the suspicion that part of the window is beyond the screen edge.
For the Nth-time, this change has debatable usefulness and too many drawbacks.
The only reasonable thing to do in the future is to extend the "No borders" property and have 3 "borders visible" states: "always", "never", "if not at screen edge".
If this extension can't be done rapidly, this feature should be reverted.

(In reply to comment #34)
> For my use case, see bug 323504 comment #14. In other words, probably all
> applications that have a scroll bar. 

Right - I get it... I had assumed from the comments that there were a bunch of apps out there with some pop up content triggered on hovering over the client edge  - hadn't considered the good old scroll bar! 

And yes, personally I prefer the previous behaviour, but I am using the the kwin script and this works fine for me.

Cheers,

The asymmetry of no border showing on one side and showing on the other after having snapped to screen edge is extremely bothersome. Does that ever happen in any other DE?

Script snapping that overrides stock snapping and snaps to deco:
http://kde-look.org/content/show.php?content=163333

Thomas's latest script solves the problem for me.

The comments below refer to his first script, which helped, but didn't completely solve the problem:

I have been thinking about why I hate the new mechanism so much.
Here's what I concluded:

For over 26 years I have been working full time on computers
with various operating systems and window managers (starting
with SunOs on a Sun 3/50 diskless workstation).
I regularly have lots of windows open: which I don't want to minimise
because they are showing useful data or producing output.
So I regularly move windows partly off the screen.
So my mind has for 26+ years been working on the basis of the rule:
(1) If you can see the border, the window is on the screen
(2) If you can't see the border, the window is partly off screen
and there may be hidden information.

With snapping it used to be impossible to have *just*
the border off screen: so if you could not see the border,
then there was *definitely* information off screen.

The new system breaks this rule.

Very frequently I grab a window and move it to the edge of the screen
(eg move from one side to the other). Usually it is a terminal window
and the important information is at the bottom, so the corner
I am looking at is the bottom left or bottom right.

With the old system the process is:
Grab window
Drag into position (I can do this very quickly, since I have
  a good quality mouse, and *don't* use mouse acceleration
  -- rant about mouse acceleration available on request!)
Check that it is in the right position (look at the border)
Drop window.

With the new system, it becomes:
Grab window
Drag into position
Check that it is in the right position: oops, I can't see
  the border, so it must be off screen
Drag it back on screen again... *snap* now there is a gap
  between the border and the screen edge!
*Sigh* Slowly nudge it back to the edge of the screen
*snap* again: it looks like I dragged too far and it has just gone
  off the screen but it should be OK
Drop window: your script snaps it back on screen again
Check that it is in the right position.

Without your script I would end up doing this:
Grab window
Drag into position
Check that it is in the right position: I can't see the border,
  does that mean it is in the right position (with just the border
  off screen) or did I drag it a little too far and there is part
  of the content off screen? With an empty terminal window
  there is no way to tell without moving my eyes from the bottom
  of the window to the top to look at the title bar and try and guess
  if there is only just enough of the title bar missing to mean
  that the window is in the right place.
Most likely: 26 years of ingrained "muscle memory" kicks in and
I automatcally assume I moved the window too far, move it back a bit,
and *snap*: a gap appears between the border and the screen edge.
Then every time I switch attention to a window on the edge of
the screen, I have to overcome 26 years of experience telling me
that the window is partly off screen and I need to move it.

What I would probably end up doing with your version of the script:
Grab window
Drag near to the right position
Slowly nudge the window towards the edge
*snap*
Try to ignore the fact that it appears to be off screen
Drop window: your script snaps it back on screen again
Check that it is in the right position.

Changing something as fundamental to a window manager as
"what happens when you drag a window" *without* giving the option
to get back the old behaviour is not just the height of arrogance:
it is also extremely rude. Even if the new way is better:
(1) Is it always better under every circumstance? Not true in this case:
the only advantage of the new system is that *if* the scroll bar is on
the side of the window at the edge of the screen and *if* you want to
click on the scroll bar, then it is a little easier to grab.
All other scroll bars are just as small: so to gain any benefit,
you have to use two different ways to operate a scroll bar,
depending on where it is on the screen.
(Personally, I hardly ever use scroll bars anyway: I use mouse wheel,
page up/down or home/end keys much more often.)
(2) If not: does the benefit massively outweigh the downside for
every user? Then there might be an argument for making the new
way the default.
(3) But even then, some users might still prefer the old way merely
because that is what they are used to. So it is the height
of arrogance and rudeness to take away even the option
of carrying on as they used to.

(In reply to comment #40)
> Script snapping that overrides stock snapping and snaps to deco:
> http://kde-look.org/content/show.php?content=163333

"plasmapkg -i screenSnapping.kwinscript -t kwinscript"

Does one have to have X running for that to work? If yes, it's clearly inferior to a settings checkbox. Some people have too many installations and too many users to need a script to do what a system-level config file line item should be able to do, and can do, for most if not all KDE configuration options.

don't worry.
such person can answer this question himself, check the filetype, inspect the installation process and automize it. easily.

(In reply to comment #43)
> easily

Doesn't look that way from here. Gecko wants to save to disk. Konq displays binary content. Saved and viewed in an appropriate viewer, it looks like XML & JS skills are prerequisite to figuring out what if anything can be done with it other than starting KDE on every installation and finding & running the script.

"Old tricks for old dogs" from its metadata is not funny. KDE's non-standard new standard is a dirty trick on those who have persevered through the horrific early years of KDE4 to get to 4.11+ instead of sticking with KDE3 or switching to Trinity or some alien DE.

You can just use the -g option to plasmapkg to install the script globally on a system, right?  But individual users are still going to have to enable it, in Window Behavior -> KWin Scripts, unless you also automate that somehow...although at that point, it qualifies as merely being a settings checkbox, which is what you wanted to begin with.

+1
Folks, this is a bug. The borders on windows are there for a reason. They provide visual cues, and it should be obvious by now that a lot (I would say most, without any evidence) of people want them.

I have no problem with this being an option, but it should be opt-in.

the script from comment #40 improves the situation partly, but still has major shortcomings:

- border-snapping is broken when resizing the window (this has to be fixed)
- the inner border of multi-monitor configurations is not treated correctly
- fully maximized windows do not have a border. That means that the commen workflow of first fully maximize and than resize one side of the window fails

Any chance the resize script could be updated to retain the borders when a window is run full screen? I have a situation on a multi monitor setup where I sometimes run a terminal full screen on the left screen. I also have a auto-hide panel on the left side of the screen.

Since this change, selecting some lines of text with the mouse has become much harder: moving the mouse to the start of the line to drag a selection now keeps bringing up the auto-popup panel, which is really annoying. Previously, the window border proveded a few more pixels width to position the mouse, and I never really had a problem.

Thanks,

While I've finally kind of warmed up to the snap-to-client idea myself, I still think there are some issues with implementing the idea given how many clients refuse to honor it. For instance, certain apps like Firefox and Thunderbird (or at least, my copies of them) seem to refuse to position themselves beyond the visible screen even though they're supposed to remember their positions, instead re-snapping themselves to the “correct” locations when they start. Since I tile my windows, this frequently results in annoying off-by-a-few-pixels placement issues that I constantly have to manually correct.

Even if the underlying issue is in the apps themselves, I believe that for this feature to really work out well in practice, there really needs to be some way to somehow enforce this policy consistently. I suspect most users aren't going to care “whose fault” it is; if the behavior isn't consistent, it will simply make for a poor user experience.

(In reply to comment #49)
> For instance, certain apps like Firefox and
> Thunderbird (or at least, my copies of them) seem to refuse to position
> themselves beyond the visible screen even though they're supposed to
> remember their positions, instead re-snapping themselves to the “correct”
> locations when they start.

+1. Chromium does this too. Every time I open a new browser window, I am forced to drag it a few pixels to the side so that it tiles nicely. I'd still prefer if KWin didn't insist on bleeding windows off the edge of the screen, but since that ship seems to have sailed, it would be nice if I didn't have to manually fix up every browser window I open.

I'll say this again... The developers have got this wrong, both on an understanding of the problem and the implementation.

This resolves around moving the pointer to the screen corner and expecting to access the window menu, when in fact it is the resize edge.

The developers then chose to move the window off slightly to allow the window menu to be the chosen control by default.

What should have been done, is that the window menu button, instead of being contained within the window edge boundary, should have been overlayed onto the window edge.

This would have meant that the pointer when moved to the screen edge would pick up the resize control, and when move to the corner, would pick up the window menu.

THIS IS THE CORRECT BEHAVIOUR AND SHOULD BE CHANGED, but try getting the developers to change this is unlikely.

that is complete and utter bullshit.
the target scope was NOT the window decoration (titlebar) since that's subject to the decoration plugin alone anyway. the target is the client content, ie. toolbuttons inside the window, scrolbars, ... - and this has been stated MANY times now, so i suggest to stop making a fool out of yourself.

There're two scripts to cope with this, expect no core feature change before "5.1" (since "5.0" is for testing and to get kwin after requried major technical changes "back to reliable" and -imo- not suitable for productive use)

I think you are talking rubbish. Moving to the edge for the client content achieves NOTHING. Try going to left edge, what do you get... NOTHING.  The original research was about picking controls, just as you suggest. Going to the left, right or bottom edges, NEVER gets a toolbutton or any other control, at least unless scroll bars are shown which they are not always. It does get you a scrollbar if shown, PROVIDED it is within a number of pixels from the top and bottom. What do you do then, do you plan to move everything off the window such that only the client window containing scrollable data is show? Nope. If you want to access the scroll bars at the very edge, then have them overlay the windows edge. Moving them off screen is just so monumentally wrong. The scripts should be removed and the previous behaviour reinstalled. If you want this new behaviour, then I suggest you write a script to carry it out. I am sorry, but you have completely misunderstood the research and gone from an acceptable system to one which is broken.

IMHO, there is a #1 bug on the whole thing, which is LACK OF CHOICE. KDE
was always about choice. Being unable to disable this option, is the first
bug to be addressed. It should have been opt-in from start, an EXPERIMENTAL
feature, not something thrown at our faces.



On Thu, Apr 17, 2014 at 1:21 PM, bib <kde@1.kde.bgcomp.co.uk> wrote:

> https://bugs.kde.org/show_bug.cgi?id=325286
>
> --- Comment #53 from bib <kde@1.kde.bgcomp.co.uk> ---
> I think you are talking rubbish. Moving to the edge for the client content
> achieves NOTHING. Try going to left edge, what do you get... NOTHING.  The
> original research was about picking controls, just as you suggest. Going
> to the
> left, right or bottom edges, NEVER gets a toolbutton or any other control,
> at
> least unless scroll bars are shown which they are not always. It does get
> you a
> scrollbar if shown, PROVIDED it is within a number of pixels from the top
> and
> bottom. What do you do then, do you plan to move everything off the window
> such
> that only the client window containing scrollable data is show? Nope. If
> you
> want to access the scroll bars at the very edge, then have them overlay the
> windows edge. Moving them off screen is just so monumentally wrong. The
> scripts
> should be removed and the previous behaviour reinstalled. If you want this
> new
> behaviour, then I suggest you write a script to carry it out. I am sorry,
> but
> you have completely misunderstood the research and gone from an acceptable
> system to one which is broken.
>
> --
> You are receiving this mail because:
> You voted for the bug.
> You are on the CC list for the bug.
>

hey all: please tune down the volume. It's not helping anyone.

I totally understand that there is frustration on the user side and on the 
developer side. But having a shism between users and developers won't help us 
here.

To our users: please accept that in the life time of 4.11 this feature won't 
be changed any more. From developer perspective the current behavior is 
intended and thus not a bug which could be fixed. Development focus moved to 
5.x now. As bad as it might sound but demanding any immediate changes as it's 
still in this thread are as useful as fighting windmills.

Now the way forward is improving in 5.x. I would be very happy to see patches 
to e.g. export the snapping state to the decoration plugin so that the 
decoration can adjust itself and hide the border. Thus we would not have 
bleeding to other screens. Of course I invite everybody to have a look at 
KWin's code base and help improve it. I'm also very willing to show people 
through the code. Yes it doesn't have to be the KWin development team which 
works on this! If there is a strong user demand it must be possible to find 
someone who can write the patch or to find someone who is willing to do paid 
development.

What I don't want to see in this bug report any more are demands from user 
base, verbal attacks on developers and on users. Especially from the users I 
want to see a more rational approach to the topic. Accepting that we as the 
developers try to do what is best, that we have a huge domain knowledge, would 
help a lot. If I see claims like it needs to be configurable, because 
everything in KDE is configurable, I have to wonder how I should consider this 
as a valid option. Code might be complex, UI might get complex and KDE is 
certainly not about configure everything (neither is GNOME about removing 
features).

Window snapping that works is a nice feature - except with KDE, I use it all the time. When it was broken in KDE, I stopped using it entirely. I find the way it works now so irritating that prefer not use it at all.

I'm quite happy that other people have different preferences. What I'm really struggling to understand here is why making this optional isn't the bleeding obvious "everybody wins" solution.

I believe it should be opt-in, but I could live with opt-out. Surely this is the obvious way to keep everyone happy. Or am I missing something?

> I believe it should be opt-in, but I could live with opt-out. Surely this is
> the obvious way to keep everyone happy. Or am I missing something?

As bad as it might sound: making everybody happy is neither possible nor a  
goal one should look for. While a checkbox makes the users in this bug report 
happy, it doesn't everybody else. Instead it just adds another config option 
which clutters the UI (ever heard of KDE software having too many options?) it 
is another code path which needs testing and maintenance. Adding a config 
option comes with real cost for all developers and users. Thus the easy way 
out to make everybody happy is always the wrong solution. If I cut out the 
complete discussion and would judge a code submission to add a config option 
for it with my maintainer hat on I would clearly say no.

The way forward must be improve, not a backflip :-)

(In reply to comment #57)
> As bad as it might sound: making everybody happy is neither possible nor a  
> goal one should look for. While a checkbox makes the users in this bug
> report 
> happy, it doesn't everybody else. Instead it just adds another config option 
> which clutters the UI (ever heard of KDE software having too many options?)
> it 
> is another code path which needs testing and maintenance. Adding a config 
> option comes with real cost for all developers and users. Thus the easy way 
> out to make everybody happy is always the wrong solution. If I cut out the 
> complete discussion and would judge a code submission to add a config option 
> for it with my maintainer hat on I would clearly say no.

This is the attitude which drives many people *away* from GNOME *to* KDE. If some people are unhappy about others having an option to get a different behaviour they desire, that is a problem with the "some people".

> The way forward must be improve, not a backflip :-)

Reverting snap-to-client entirely would be an improvement. If other people really want that behaviour, which is irreconcilable with snap-to-deco, then an option is the only way to satisfy both people (and does, as long as neither wants to force their preference on the other...)

(In reply to comment #58)
> Reverting snap-to-client entirely would be an improvement. If other people
> really want that behaviour, which is irreconcilable with snap-to-deco, then
> an option is the only way to satisfy both people (and does, as long as
> neither wants to force their preference on the other...)

Or the people wanting snap-to-client (whom I would be willing to bet are the minority) could use a KWin script, while the people wanting snap-to-decoration could continue using KWin in the same way as they have always enjoyed.

> > out to make everybody happy is always the wrong solution. If I cut out the
> > complete discussion and would judge a code submission to add a config
> > option for it with my maintainer hat on I would clearly say no.
> 
> This is the attitude which drives many people *away* from GNOME *to* KDE. If
> some people are unhappy about others having an option to get a different
> behaviour they desire, that is a problem with the "some people".

GNOME Shell allows a high flexibility through the extension system. GNOME 
Shell itself is focusing on exactly one work flow and one intended behavior. 
It's targeting exactly one very specific user group and I know many users who 
love it for what it is. In fact I know more people who love it, than I know 
people who switched from GNOME Shell to Plasma. GNOME is doing an awesome job 
at what they are doing and I at least have high respect for what they achieved 
even if I consider their system as absolutely unsuited for my needs.

What the people leaving GNOME Shell don't get is that the system is not 
designed for their way. But there are extensions. Using them gives a high 
level of flexibility back. And if I look at the number of available extensions 
they seem to be doing better there than the oh so praised for it's 
configurability KDE. So GNOME must be doing something right, don't they?

Does GNOME have to provide every possible option people claim? Obviously not. 
It doesn't suit the use cases GNOME is aiming for. It's even contradicting the 
main aim of the GNOME team. But it's possible to have everything and the 
kitchen sink through the extension system. So yes if a specific feature is not 
going to be added to GNOME or even removed it's not against the users.

Now what tells us that for KDE? Well first of all, all this pointing to GNOME 
doesn't help. It's another development metaphor to the way how we do at KDE. 
Thus telling us that we are just like GNOME doesn't cut it, because we aren't. 
Pointing out that GNOME users leave to go to KDE, isn't helping either. If 
users leave GNOME for all the wrong reasons and expect from KDE what KDE isn't 
- we are not the GNOME with all possible options - is not helping either. Thus 
in summary: let's ignore GNOME and look at what we do. GNOME is neither a 
reason to do something nor a reason to do not something.

With that I'm coming back to what I wrote and you described as "attitude". My 
job as the maintainer is to do what is best for the application, not to please 
all users. If I try the latter I'm doing a bad job as a maintainer as what 
remains after I step down is an unmaintainable mess. Now in opposite to you I 
know the code base and I know that it is non-trivial. Thus an config option is 
expensive. In that point you just have to trust my experience as a domain 
expert. It's not about not wanting to have another config option (heck just 
this morning I added a TODO item to introduce a new config option next week) 
it's about the cost this config option would be.

> 
> > The way forward must be improve, not a backflip :-)
> 
> Reverting snap-to-client entirely would be an improvement.

This is the irrational demand I said I don't want to read any more in this 
thread. There won't be a revert, no matter how often people ask for it. 
Period. Won't happen.

> If other people
> really want that behaviour, which is irreconcilable with snap-to-deco, then
> an option is the only way to satisfy both people (and does, as long as
> neither wants to force their preference on the other...)

no an option is the wrong solution to this problem.

So, does anyone in this thread have any recommendations for X11 window managers?

> So, does anyone in this thread have any recommendations for X11 window
> managers?

This is not the place for such a discussion. If you want to move the bug 
report completely offtopic, please do so, but then I'm asking sysadmins to 
close down this report.

(In reply to comment #62)
> > So, does anyone in this thread have any recommendations for X11 window
> > managers?
> 
> This is not the place for such a discussion. If you want to move the bug 
> report completely offtopic, please do so, but then I'm asking sysadmins to 
> close down this report.

On the contrary, this is the logical place to have this discussions. Upset users will locate this thread and, upon seeing that the developers have no intentions of restoring the behavior that they desire, will want to find the next best alternative. If we can have some alternative enumerated here, then that will help them to their goal swiftly and easily.

This bug feels like a twin to the current Linus vs. systemd war, with Linus=KDE users and systemd=KDE devs responsible for dumping this annoying new behavior into KDE so shortly before the v4 feature set was declared immutable in favor of v5, which is where it should have first been exposed to users instead, if ever.

Meanwhile for users of selected distros, KDE3 and/or TDE remain both available, and my preference for routine daily chores, leaving me to suffer KDE4's so-called improvements to lesser extent than those with only one PC or laptop to contend with.

(In reply to comment #57)
> Instead it just adds another config option 
> which clutters the UI (ever heard of KDE software having too many options?)

There already is a config option for snapping.  The request would change it from a checkbox to a three-valued radio button.  Yes, there'd be additional code, but probably not as much as for fixing up the current snap-to-client behavior in the way you mentioned before.

Personally I gave up on this matter by disabling snapping altogether.

> This bug feels like a twin to the current Linus vs. systemd war, with
> Linus=KDE users and systemd=KDE devs responsible for dumping this annoying
> new behavior into KDE so shortly before the v4 feature set was declared
> immutable in favor of v5, which is where it should have first been exposed
> to users instead, if ever.

I hope you also got the part about that systemd developers did some work and 
Linux developers did some work, right? The positive aspects were unfortunately 
not represented in the media. Nobody talked about that there was a very good 
compromise which improved the overall experience. I recommend to read 
http://lwn.net/Articles/593676/

That's what I want to see here, too. I want to see useful suggestions to move 
forward and not to stick with "needs to be reverted" or "what are alternatives 
to KWin". That's not helping, I want to move forward. I want to improve to 
something that makes all users happy. Just config option is the wrong answer.

(In reply to comment #66)
> I want to see useful suggestions to
> move 
> forward and not to stick with "needs to be reverted" or "what are
> alternatives 
> to KWin". That's not helping, I want to move forward. I want to improve to 
> something that makes all users happy. Just config option is the wrong answer.

I don't get why if there is a script that has the effect of reverting the behavior that running that script cannot be triggered by a checkbox in a prefs panel instead of making long-time users who may not even know it exists hunt for a script to get back what they lost.

lookup "frozen" in a dictionary.
change -> workspace decided frozen -> first complaints: "bad luck"

(In reply to comment #66)
> I want to move forward. I want to improve to 
> something that makes all users happy. Just config option is the wrong answer.

The problem is that I find snap-to-client incompatible with active borders.  I'm really not sure how you could possibly reconcile those two features.

> > I want to move forward. I want to improve to
> > something that makes all users happy. Just config option is the wrong
> > answer.
> The problem is that I find snap-to-client incompatible with active borders.
> I'm really not sure how you could possibly reconcile those two features.

What's "active borders" to you?

(In reply to comment #66)
> I hope you also got the part about that systemd developers did some work and 
> Linux developers did some work, right?

I would be glad to "do some work" and write a patch to make this configurable (or reverted).

If you're unwilling to compromise on a config option, then what's the process for making an official KDE *fork* of KWin?

> I would be glad to "do some work" and write a patch to make this
> configurable (or reverted).

As I explained quite often a config option or reverting is not the right 
solution to the problem. What needs to be done is to have a look what the 
problems are the new approach created and to fix them. This could be done in 
multiple ways: better scripting support to influence the snapping behavior or 
giving the decoration plugin more control over snapping.

> 
> If you're unwilling to compromise on a config option, then what's the
> process for making an official KDE *fork* of KWin?

Should I read that as a threat? If yes I wish you good luck with your fork. 
It's git, should be easy to fork.

(In reply to comment #72)
> > I would be glad to "do some work" and write a patch to make this
> > configurable (or reverted).
> 
> As I explained quite often a config option or reverting is not the right 
> solution to the problem. What needs to be done is to have a look what the 
> problems are the new approach created and to fix them.

The new approach *is* the problem. When two groups want different incompatible behaviours, a config option is the *only* solution.

> This could be done in 
> multiple ways: better scripting support to influence the snapping behavior
> or 
> giving the decoration plugin more control over snapping.

Nobody here wants to have to use scripts.

> > This could be done in
> > multiple ways: better scripting support to influence the snapping behavior
> > or
> > giving the decoration plugin more control over snapping.
> 
> Nobody here wants to have to use scripts.

but that's what scripts have been created for. Accepting that it's impossible 
to have a KWin which serves all users equally good by default, but allowing 
full customization through scripts.

(In reply to comment #74)
> > > This could be done in
> > > multiple ways: better scripting support to influence the snapping behavior
> > > or
> > > giving the decoration plugin more control over snapping.
> > 
> > Nobody here wants to have to use scripts.
> 
> but that's what scripts have been created for. Accepting that it's
> impossible 
> to have a KWin which serves all users equally good by default, but allowing 
> full customization through scripts.

Fine, but the default behaviour should at least be the more obvious/expected/desired one: snap-to-deco.
Snap-to-client can then use a script...

> Fine, but the default behaviour should at least be the more
> obvious/expected/desired one: snap-to-deco.
> Snap-to-client can then use a script...

I also already stated that we won't revert. So please don't suggest it again. 
We are moving in circles.

(In reply to comment #70)
> > The problem is that I find snap-to-client incompatible with active borders.
> What's "active borders" to you?

Electric borders - like on inner edges, the edge looses its special value (eventually to the electric border)
Unlike inner edges, there's no bleeding, so the snap position becomes indifferent (where i would personally probably not want to snap to that edge, but some px away from it - if at all)


(In reply to comment #72)
> multiple ways: better scripting support to influence the snapping behavior
> or giving the decoration plugin more control over snapping.

I don't see where moving it to the decoration would get us rid of the option (or lower the code branch which is merely an assignment of 4 integers anyway) - the checkbox would be in the deco config then.
The decoration should (like on quick tiling) be informed about: "you're gonna be snapped to that edge, wanna re-layout?"

The solution will likely be some movecontrol script class which client movements are piped through (for an edge snapping subcategory depending on the distance from outer screen borders, so they don't have to calculate that) unconditionally.
This will allow to treat different clients or edges differently, also keep random distances from the borders etc. and also (for the general move control)  to snap to certain screen regions or positions (instead of "center")

Changing something as fundamental to a window manager as "what happens when you drag a window" *without* giving the option to get back the old behaviour is not just the height of arrogance: it is also extremely rude.  Even if the new way is better.

The questions about "how to fork KWin" or what alternative window managers exist are an expression of the users' frustration that something so fundamental as "what happens when you drag a window" could be changed without even giving the option to restore the old behaviour.

This time we just about "dodged the bullet" in that there is a script-based workaround. But people are, quite reasonably, concerned about what will be the *next* fundamental behaviour which will be changed without notice and with no means of restoring the old behaviour. Will we wake up one day to find that "what happens when you click on a window" has been changed in some fundamental way that the developers think is an improvement, but which removes some vital functionality for some users and which most users dislike?

If that is a real threat, then "what alternative window managers exist" is a reasonable question to ask.

Martin Gräßlin stated: "I want to improve to something that makes all users happy." This concern for the happiness of the users is welcomed, and the answer is obvious: revert to the old behaviour. However, he also stated: "There won't be a revert, no matter how often people ask for it. Period. Won't happen." This implies that the happiness of the users is of zero importance.

Which is it?

(In reply to comment #78)
> This time we just about "dodged the bullet" in that there is a script-based
> workaround. But people are, quite reasonably, concerned about what will be
> the *next* fundamental behaviour which will be changed without notice and
> with no means of restoring the old behaviour.

ONCE AND LAST AGAIN:
THE CURRENT SITUATION MOSTLY EXISTS BECAUSE KDE-WORKSPACE IS FROZEN. THERE'S NO NEXT TIME.
GET! THAT! INTO! YOUR! STUPID! HEAD!

> Martin Gräßlin stated: "I want to improve to something that makes all users
> happy." This concern for the happiness of the users is welcomed, and the
> answer is obvious: revert to the old behaviour. However, he also stated:
> "There won't be a revert, no matter how often people ask for it. Period.
> Won't happen." This implies that the happiness of the users is of zero
> importance.
> 
> Which is it?
The wrong part?
Your bold assumption "and the answer is obvious: revert to the old behaviour."

I'm out of here (that means this bug now goes /dev/null for me) and suggest to close this once more as unreasonable troll bait.

Sorry Radics. Absolutely not /your/ fault.

(In reply to comment #77)
> (In reply to comment #70)
> > > The problem is that I find snap-to-client incompatible with active borders.
> > What's "active borders" to you?
> 
> Electric borders - like on inner edges, the edge looses its special value
> (eventually to the electric border)

Sorry, my bad, I actually meant the "Active Screen Edges".  When I move my mouse to the screen edge, I want to trigger a workspace action.  Having the window react in any way is counterproductive.  (Not that I could actually name an application that would profit from the new behavior ...  And in terms of scrollbars vs. resize handles it appears to be a draw.  But again all of this has been stated before.)

As far as Thomas' reply is concerned, sorry, I don't understand it at all. :-)

> Sorry, my bad, I actually meant the "Active Screen Edges".  When I move my
> mouse to the screen edge, I want to trigger a workspace action.  Having the
> window react in any way is counterproductive. 

Screen edges are reserved to KWin. No matter what the window does it's 
reserved to KWin. So this should not at all conflict.

My comment was not asking for a reversion, but asking how important user's happiness is to the developers. There is a spectrum of possibilities ranging from:

(A) We made a mistake and its too late to fix it in this version, but will address it in the next version.

to:

(B) Its our code and we can do whatever we [expletive] well please with it and if you don't like it, then [expletive] you.

Which is it?

(In reply to comment #81)
> > Sorry, my bad, I actually meant the "Active Screen Edges".  When I move my
> > mouse to the screen edge, I want to trigger a workspace action.  Having the
> > window react in any way is counterproductive. 
> 
> Screen edges are reserved to KWin. No matter what the window does it's 
> reserved to KWin. So this should not at all conflict.

Well, to quote Thomas on the main motivation for the change in behavior (see way down below):

"The point to snap to the client is to allow the clients to profit from the infinite width of the screenedge (reg. Fitts' law)."

In other words, KWin and the client compete for the screen edge, at least _conceptually_.  That's why I think these two ideas do not work well together.

(In reply to comment #82)

> (B) Its our code and we can do whatever we [expletive] well please with it
> and if you don't like it, then [expletive] you.

Sure looks like (B) to me! I'm just stunned at the attitude. Opinions and personal preferences are arrogantly stated as immutable facts. Any alternative view is simply wrong and will be ignored - irrespective of how many people agree. This is as preposterous as it is amazing!

> Well, to quote Thomas on the main motivation for the change in behavior (see
> way down below):
> 
> "The point to snap to the client is to allow the clients to profit from the
> infinite width of the screenedge (reg. Fitts' law)."
> 
> In other words, KWin and the client compete for the screen edge, at least
> _conceptually_.  That's why I think these two ideas do not work well
> together.

ah, but they are on a different stacking layer. The screenedge actions are 
always kept above other windows. Thus it doesn't interfere. Of course with a 
triggered action you don't benefit from the advantage through fitt's law, but 
it's also not a disadvantage.

> My comment was not asking for a reversion, but asking how important user's
> happiness is to the developers. There is a spectrum of possibilities ranging
> from:

sorry but that's a rather ridiculous thing to ask. We provide you a software 
which is probably the most flexible window manager on any system ever existed. 
All of that not only free as in beer but also free as in freedom allowing 
everybody to change the code as will. Our software has an estimated cost of 30 
person years of development, most of that done in spare time. If you really 
think that we don't do all of that for our users, then I think it's best to 
move on. If you still think we don't care for our users consider that I (and 
Thomas) spent quite a lot of time today on answering this bug report in our 
spare time on the first public holiday since January. At least I would have 
better things to do.

Indeed, KDE must be the most flexible window manager on earth, and that's
result of hard work. I must say I'm very grateful for what I (we) have,
freely. No sarcasm here, it's the truth. And I use KDE since 3.x days on
Slackware.

In my case I'll stick with the disable script. The reason is my hardware:
One big monitor at home (2560x1440) and two big at work (1920x1200, page
style, side by side). I use Switch desktop on edge always active, 9
desktops. I'm using all 4 corners also for Active Screen Edge Actions. The
active window is set to follow mouse. Lots of konsole windows. So, for me,
the new behavior adds little, because as far as I understand, the Fitt's
Law is already working for me - to switch desktops and to invoke actions on
corners (maybe I'm wrong). If I was at a small 1366x768 screen, probably I
would make better use of the new feature.

Also, I'll quit the bug list. I think my use case is (probably) too
specific, so I'm done here. I'll stay a few days more, so I can clarify any
questions.

Thanks and good holidays



On Fri, Apr 18, 2014 at 9:53 AM, Martin Gräßlin <mgraesslin@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=325286
>
> --- Comment #86 from Martin Gräßlin <mgraesslin@kde.org> ---
> > My comment was not asking for a reversion, but asking how important
> user's
> > happiness is to the developers. There is a spectrum of possibilities
> ranging
> > from:
>
> sorry but that's a rather ridiculous thing to ask. We provide you a
> software
> which is probably the most flexible window manager on any system ever
> existed.
> All of that not only free as in beer but also free as in freedom allowing
> everybody to change the code as will. Our software has an estimated cost
> of 30
> person years of development, most of that done in spare time. If you really
> think that we don't do all of that for our users, then I think it's best to
> move on. If you still think we don't care for our users consider that I
> (and
> Thomas) spent quite a lot of time today on answering this bug report in our
> spare time on the first public holiday since January. At least I would have
> better things to do.
>
> --
> You are receiving this mail because:
> You voted for the bug.
> You are on the CC list for the bug.
>

(In reply to comment #86)

> sorry but that's a rather ridiculous thing to ask. We provide you a software 
> which is probably the most flexible window manager on any system ever
> existed. 
> All of that not only free as in beer but also free as in freedom allowing 
> everybody to change the code as will. Our software has an estimated cost of
> 30 
> person years of development, most of that done in spare time. If you really 
> think that we don't do all of that for our users, then I think it's best to 
> move on. If you still think we don't care for our users consider that I (and 
> Thomas) spent quite a lot of time today on answering this bug report in our 
> spare time on the first public holiday since January. At least I would have 
> better things to do.

Kwin is without doubt the most flexible window manager on any system ever existed, that is the reason why we can't stop complaining about a feature which was abruptly removed (snap-to-deco).
I'm a everyday KDE user since version 0.9, and I'm not not interested in the GNOME philosophy ("no configuration, good luck with plugins").
You just have to agree that the impossibility to have a well-established and reasonable behavior (snap-to-deco) _IS_ a regression in the most flexible window manager on earth.
Then, ok, the code is frozen and we are out of luck on hoping for a change, and ok, we have to resort to the scripts (which increase the mess about a proper restoring of sessions), but no configurability is not something we, long time KDE users, expect.
When kwin introduced the Aero-inspired auto-full-screen and auto-left-part, auto-right-part annoyances, I just had to spend a few minutes to discover how the hell this new (defaulted to yes) option was called and nuke it once. I couldn't do the same for snap-to-client and THAT is the problem. (And sorry, I really can't believe that having the code for both the alternatives is too complex).

ObDisclaimer.  Big fan of KDE - been using it as my primary desktop & laptop DE for ~15 years, love the work you guys do, understand most of it goes unappreciated.    I was annoyed by this behaviour change last year, saw the original whingy thread, walked away and just kind of got used to the new behaviour, and would just grumble to myself quietly every now and then.  I recently got motivated to research it again - some vague memory of a proposed fix via a theme / widget configuration - and discovered Thomas's kwinscript, which seems to resolve things nicely. (Thanks Thomas!)

I think I've read all the non-sweary bits of the two big b.k.o threads on this, and don't think these two points have been made.

Or if they have, not with quite so many words.

I accept that Fitts' Law makes some sense in a modern DE, but my (previous) use case for window edges at screen edge actually fit the Fitts, as it were - I have many overlapping windows, and would use single-click at the edge to raise, or middle-click to lower.   This is something I want to do quickly and without worrying about accuracy - ie. Fitts.  The change last year meant that I could still do this for any windows that touched the top edge, but only some windows that touched the side edges.  It's the 'some' that was uncomfortable.   On the right-edge you'd often be able to raise, but necessarily change the position of the content of that window.  (Naturally this is surprising and unwanted behaviour.)  On the left, you'd usually be able to raise without side effect, though some icons in Konqueror (I have my toolbar vertically aligned on the left) would be activated as they were effectively on the screen edge.   Lowering (MMB) via hitting the application's border on the left & right screen edges stopped working completely, of course, though as I say it still worked for windows touching the top-edge of the screen.  If I want to scroll inside the active window I'd usually use the keyboard shortcuts available for that application.  Keyboard is faster than mouse, and all that.   But if I want to scroll inside a non-focus'd window without pulling it into focus, then I'd move the mouse to somewhere on that app, and MMB-scroll (some applications have more than one scrollable region, but they're usually a large target area, so this worked well for me).

I guess if you're going to throw to Wikipedia's article on Fitt's Law as a justification, then while you're there it's good to read http://en.wikipedia.org/wiki/Principle_of_least_astonishment , and I gather this is the crux of most people's problem, and what led to the request that it be made a customisable option, rather than an obligatory change.

Second point - when this bug first became apparent around August (?) last year, obviously not all the millions of KDE users experienced it at the same time. Most KDE users rely upon the release cycle of their favourite distro, so you were (are) always going to get a relatively small number of people impacted early on by *any* change.   It just so happens that with something like bleeding edge releases of KDE, these are also likely the power / feature-sensitive / bug & support system-aware users.   Over time as distros bring the newer releases of KDE SC into their LTS (or similar) releases, you'll get increasing numbers of people impacted - unfortunately they're walking into a discussion that's a year old, and now populated almost exclusively by very annoyed people (on both sides).  These are also (generalism follows) the kinds of users that are going to have a much harder time coming up with the right search terms to find threads like this one, and are likely to use a LUG or some BBS/forum tucked away in the corner of the Net.

Point being that not everyone embraces every change made by everyone, natch, but it's risky to assume that a small number of complaints made by the more adventurous section of your userbase *isn't* indicative of the kinds of things that the rest of your users may feel later, when they catch up.

Anyway, thanks again for all your efforts, they really are much appreciated.  Judging by historic scheduling, my next lengthy b.k.o rant will be in early 2018.

Is this thing fixed / looked at for KF5 (or the standalone version of kwin)?

11 months later... could one of the devs just let us know if anyone is going to look at this in KF5? If not, then can we just close it as WONTFIX and move on - that seems better to me than just leaving it open if it is never going to happen. Thanks.

This would be good as a configurable option: snap-to-edge/snap-to-content.  A radiobox maybe, under window behaviour->advanced.  Or just an unhelpful checkbox labeled Fitt, if you prefer.

Yes, yes, yes - a configurable option (as has been suggested by many already) - preferably opt-in, but I could live with opt-out. Letting people run their systems the way they prefer is a central tenet of the Linux philosophy.

Also, I don't accept that restoring this behavior - which is standard in (many/most/all?) other window management systems - would result in an unacceptable amount of extra testing.

For those who care, I've uploaded a KDE5 version of the snap-to-deco script that Thomas Lübking originally posted in comment #40 (as he's told me he won't be updating it himself):

http://www.kde-look.org/p/1135334/

It fixes two new KDE5 problems that I ran across with the script: broken configuration dialog, and newly-placed windows not being snapped properly (if applicable based on your placement policy...)

Bob - very much appreciated, thank you!

cool, thanks for updating.

Thanks, Bob, this is highly welcome.  Great work!

Created attachment 99774 [details]
attachment-2839-0.html

Very much appreciated!  -- Marten

I think this is no longer relevant. We changed snapping behavior to snap-to-frame because it's very difficult to make snap-to-client work correctly with asynchronous updates on wayland.

Can't verify right now, but last I checked, it was still an issue at least on X11...?