Summary: | Window content snapping to desktop edge rather than window border | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Wes <wes> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED NOT A BUG | ||
Severity: | normal | CC: | audvare, cfeck, kde, kde, steve, sw, szo, ultra-shimapan, wes |
Priority: | NOR | ||
Version: | 4.11.0 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
URL: | https://git.reviewboard.kde.org/r/112103/ | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Wes
2013-09-18 13:43:12 UTC
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. |