+++ This bug was initially created as a clone of Bug #323504 +++ I have cloned this bug report in hopes of returning to a rational discourse and actually arriving at a resolution. KDE 4.11 introduced a new behavior where when snapping windows to the edge of the screen, decorations would be ignored and the content of the window would be snapped to edge instead. Decorations are drawn off-screen, which beyond just looking ugly, also has usability impacts. The only vague justification given for the change by the developer is "Go read Fitt's Law." So I did. Fitt's Law stresses the importance of the edge of the desktop because this region has "infinite width" -- your mouse cannot move past the desktop edge no matter how much you move the mouse. This means that UI elements on the edge of the desktop are easier to acquire because you cannot move past them. For example, a scrollbar on the edge of the desktop (rather than inset a few pixels) is considerably easier to acquire because you cannot move past the scrollbar. When you move your pointer towards the edge of the screen, it does not require stopping early or backtracking a few pixels to land on the scrollbar. The unfortunate assumption by this new KDE behavior is that the most desirable UI elements are always within the window border and never the window border itself. As a heavy terminal user, I typically have very little content within my windows that I wish to acquire with the mouse. (Text selection is not helped by behavior at all.) The window borders give visual feedback about the end of the window content. In addition to the false assumption described above, the new functionality was implemented rather inconsistently and negatively affects other UI elements. 1.) The behavior of packing windows, initial placement, and snapping windows when dragging do not all act the same. For instance, I can pack windows to positions that I now cannot drag them. 2.) In multi-monitor setups, this new behavior causes windows snapped to an "edge" between monitors to draw the window content on one screen and place the window decorations on another screen. (A fix for this is already under review.) 3.) Thick borders may cause buttons on the title bar to be shifted off-screen and become inaccessible. 4.) It is much more difficult (or even impossible in some cases) to identify the end of window content without the window border. 5.) Other UI elements drawn based on the overall size of the window may be clipped or missing when the border is also off-screen. Most of these have screenshots demonstrating the bad behavior attached to the cloned ticket. In addition to the developer of this feature, I have seen only one other comment supporting this new behavior. The cloned ticket provides far more examples of users who do not like this behavior. Since there seems to be at least a small amount of support for the behavior (although I've seen zero requests for the behavior), I'm not suggesting the elimination of this behavior, but rather ask that it be toggled. The KDE user should decide which behavior they want, not a single KDE developer.
let's try again and be a little bit more constructive, can we? I don't think there can be a constructive way to address this when we start with "false assumption" and talking about "vague justification". Please remove all emotions and do a report based on technical aspects. Thanks.
Wow. This patronizing tone of voice in response to a well formulated report is really getting me to think of abandoning KDE altogether, if that is becouming the new way of dealing with users.mI can't for the life of me, see why the old behavior can't be made optional, except for "we don't want it thats why".
Fact is, KDE 4.11 unpatched is unuasable for me, because this change totally breaks my work routine.
> This patronizing tone of voice in response to a well formulated report This is a technical issue tracker not a users wish concert or something in that direction. The report is not well formulated as I pointed out. It contains emotions, which have nothing to do in an technical issues trackers. Issues don't have emotions. This is bad style and results in useless discussions like we have right here with you threatening to abandon KDE. You just proofed yourself the point why I closed the bug again. I'm open to a constructive (!) report, threatening to no longer use our software is not constructive. So everyone please: calm down, get to a constructive basis and operate on that. Let's work together to improve the situation. The developers fighting against the users doesn't help anyone.
I listed multiple technical issues which have not been addressed. Do you want me to clone another ticket for those?
(In reply to comment #4) > This is a technical issue tracker not a users wish concert or something in Then perhaps you need to remove the "wishlist" selection from the importance drop down.
I was not threatening. I'd actually hate to have to abandon KDE, but if it becomes unusable to me, that is the only logical conclusion. That in addidion to this unprecedented hostility towards users, which is really something I'd never have expected here.
@Wes Martin is the component maintainer. You're free to question is, but do not again alter a terminating resolution he set. In case you did not understand that: He tagged the report INVALID for being what i'd personally call "troll bait", not because of the claimed subject. --- OT and fyi: "ratio" is actually a latin term and it means "rationale/reason/motivation/consideration/reflection/thought/deliberation/opinion/belief" etc. - it's just much shorter as even any of them.
I would also suggest to report the issues separately. For 1 & 2 patches are already on reviewboard, 3 probably needs to reassigned to decoration developers. I do not understand 5, so it needs clarification in the new report.
In bug #323504, (5) referred to the window geometry effect - and the claim is simply false. The effect uses the entire visible window rect, including eg. shadows - so it did not align to screen edges before either. If screen alignement is a desired behavior, it can be fixed in the effect independently (by simply intersecting the client visbleRect with the screenRect after calculating the center) For (3), i expect Nuno's veto on aligning the buttons towards the client ;-) (Though the present padding indeed matches the "Normal" size) It however mostly affects the "Huge/Very Huge/Oversized" sizes and quick tiling is deliberately handled differently for also this reason (perfect button alignment is more important in a rather static geometric layout) (4) is actually as well a general issue regardless of this change, since Oxygen attempts to merge client and decoration. So while for Wes' "RXVT tiling WM" case the decoration can actually serve this task it can in general not (unless measured by the titlebar which works the same in either case) - not to mention that we support decoration layouts w/o side/base borders or even completely undecorated window management - all exposing this problem unaffected by the snapping change. My best idea on this is so far a simple script that moves the window completely into screen bounds on a shortcut. If we can rely on compositing, it's of course possible to paint around random hints on this (red lines, pulsating arrows etc.) statically or on random occasions (activation)
(In reply to comment #10) > In bug #323504, (5) referred to the window geometry effect - and the claim > is simply false. > The effect uses the entire visible window rect, including eg. shadows - so > it did not align to screen edges before either. > If screen alignement is a desired behavior, it can be fixed in the effect > independently (by simply intersecting the client visbleRect with the > screenRect after calculating the center) How can my claim be false when I have visual evidence that it happens? I may not have covered every possible case where it happens, but that does not invalidate my claim. I don't use shadows myself, so I can't speak for how this effect interacts with them. As a KDE user, I look at KDE as a complete package. I don't know every component intimately or even which on-screen elements are separate components. I rely on the expertise of the developers to find out where the true issue lies. If the effect is what needs to be fixed, Shadows or not, positioning the effect element off-screen and making it unusable just looks bad to the end user. It looks broken. I don't really care that it's the result of some other intended behavior, drawing parts of my UI off-screen looks broken. I realize that isn't even remotely "technical", but it still detracts from the overall quality of the KDE product. If I wanted to use a desktop that looked and acted broken, I'd use GNOME.
(In reply to comment #11) > true issue lies. If the effect is what needs to be fixed, Forgot to finish my sentence... If the effect is what needs to be fixed, let me know what product and component I need to file the bug under so the right people see it. I have no problem submitting more bug reports. I want my bug reports to go to the right people just as much as you do. I don't want to waste my time opening bug reports just to have them summarily marked invalid and ignored.
This is the last, decidedly non-technical, comment I intend to make on this bug report. I will file new bugs for issues #3 and #5 above as well as a "wishlist" bug for the toggle option. I think it will be easier to understand the issues and resolutions, for both developers and other KDE users, if the issues are separated. I apologize for any confusion I may have caused my fellow KDE users and headaches for the KDE developers. My general feeling now as a KDE user about this behavior is that it was released prematurely. I rely on KDE every day to do my job. No other desktop environment I tried can match KDE's power. I've used KDE since late 1.x or early 2.x. I kept true to KDE through all the early 4.x releases with all their missing features and growing pains. The latter 4.x releases have been excellent; really polished and always improving. But this one feature more than any other that I can remember stands out to me as incomplete. I honestly cannot even tell you what else has changed between 4.10 and 4.11 because this one behavior was more noticeable and impactful than any other change. I use a few other KDE applications, but nothing as heavily as KWin. The inconsistency in initial placement, snapping, and packing only lends to the observation that something was broken. I realize these are being fixed, but that's not what was shipped and it's not going to be fixed for me until the next release ships, at the earliest. Without knowing the intentions of the developers, it's very easy to assign the brokenness to the changed behaviors rather than the unchanged behaviors. Either way, something appears broken to the end user and brokenness tends to lower to observed quality of the product. Since the KDE developers seem determined to make this behavior the norm, I'm trying to open my mind to the possibilities. Auto-hiding panels inside clients actually sounds pretty neat and I'd be interested in seeing how that can be exploited. I'm curious to know what else might be planned. The "scrollbar-on-the-edge" use case isn't very appealing to me personally as I have few clients with a scrollbar I want to use and there's only a 25% chance of the scrollbar being on the same side as the desktop edge with my two monitor setup. What I think would really help drive acceptance of the behavior is to actually have some clients that make use of it; right now there is nothing. My terminal window borders are simply drawn off-screen. What is the killer feature that depends on this new behavior? As far as I know, it doesn't exist. The lack of applications using the new behavior highlights the lack in the design of the behavior. Without clients making clear use of this behavior, I expect you will have more and more people think it's simply broken. It's a change with no obvious purpose. I love RXVT, but I would be open to using Konsole again if it was able to exploit this behavior to my benefit somehow. I love Thunderbird, but maybe I could use KMail if it had some inventive use for this (and fixed all the other problem I read about on the Kubuntu mailing lists). I use Konversation every day, how it be made better by this? I really do like inventive, innovative, shiny new things. I'm not afraid of change; I'm willing to adapt if the benefit is there to do so. I trust KDE can provide that benefit eventually. I just wish I didn't have to change now before that benefit could be realized.
(In reply to comment #11) > How can my claim be false when I have visual evidence that it happens? You claim the clipping happens due to the snapping change what is simply false. The clipping happens because the effect paints and painted even outside the decoration and the proof for that is the code and the git log. I frankly stopped taking you any serious, sorry.