regular users don't care about window geometry

i fully acknowledge that i'm not a regular user. but how exactly does this justify simply nuking an optional feature?

@ossi can you tell me how you used that feature?

---

but how exactly does this justify simply nuking an optional feature?

To simplify relevant interactive more resize code. Given that it's a niche feature, it was dropped rather than making it work with other window types too. As the commit message says, there are other ways to replicate this functionality without kwin changes.

the commit message should have disclosed that actual reason rather than providing a lame excuse about users supposedly not caring ...

The commit message mentions that it's a niche feature and most users have no real use for window geometry data. Some developers may need to check the window geometry, but there are others way to find it, e.g. the debug console (type "kwin" in krunner and select "open kwin debug console" then navigate to windows tab; you'll see a lot more associated properties) or qdbus org.kde.KWin /KWin queryWindowInfo or even plain qDebugs. We certainly can't ship features to cover every edge case. That's why the scripting api exists. And it happens that there's a script already: https://store.kde.org/p/1833846

you're totally missing the point on two fronts:

firstly, one doesn't just go around and remove existing features unless they have clearly become irrelevant (superseded or not applicable any more). it has been implemented for a reason, and you need a really good reason to remove it. which you didn't give in the commit message.

secondly, you're making an argument from a lack of imagination. you don't know what users are using the feature for, and how many (definitely many times over the ones who spoke up on the bug tracker).

it has been implemented for a reason

With projects like kwin it's unfortunately not the case as we've accumulated a lot features, a good portion of which was added at the times when there was little threshold for features to be included. We started taking this issue more seriously later and introduced some guidelines for new features https://invent.kde.org/plasma/kwin/-/blob/master/README.md?ref_type=heads#guidelines-for-new-features.

... and there were features dropped before simply because of doubtful usefulness, not even by me but previous maintainers!

... and I still stand by the decision in this commit. You're correct that I don't know all the ways this feature is used, but I'm fairly certain that most people don't care about window geometry, which is an important factor when deciding whether particular feature should be part of kwin or provided as an extension. Either way, examples what I've heard how the feature used to be used include: not using proper window screenshoting and screencasting apis, satisfying OCD, i.e. a person likes window coordinates to end with particular digits, etc.

you may not be aware of the reasons or you may judge them differently now, but there (obviously) were reasons.

i regularly use this feature to get a ballpark feel for the dimensions of dialogs without doing the math in my head. this is very useful when designing (non-portable) UIs, and a lot more efficient than whipping out kruler each time.

contrast this objectively useful technical function with various bling effects. why exactly are the latter more justified to be included?

Can't this just be implemented as a scripted effect nowadays?

didn't you read the backlog? it can and it has. the discussion about that is happening in !2553. while i made the mistake to let it bleed over here, the actual focus of the discussion here is the suboptimal commit message.