| Summary: | decorations should have different images for Close vs Quit | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Gioele Barabucci <dev> |
| Component: | decorations | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | bluedzins, eulenreich, praseodym+kdebugzilla |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Gioele Barabucci
2004-03-02 22:13:26 UTC
*** Bug 97626 has been marked as a duplicate of this bug. *** Are there hopes to see this enhancement in KDE 4? I don't think so. The window manager knows nothing about what action the application is going to take when the button is pressed. To really "solve" this issue, you would need to get window manager and application writers to agree on a convention to use, for all the toolkit that use X. IIRC other optional extentions like this has been proposed and approved by the XDG. Wouldn't it be nice if someone with the needed knowledge propose this extension? It is a common problem, at least it is for me, to understand if the X button will close the current window of quit the application. *** Bug 161963 has been marked as a duplicate of this bug. *** @Luciano, of course it cannot be done fully automatic, so API is required and application cooperation. Without API not much cannot be done, though. And it would solve the issue. Another approach would be to treat this as window behaviour, so user could register all apps that dock in systray. It could work not only for KDE apps then. *** Bug 241038 has been marked as a duplicate of this bug. *** As explained in comment #3 the window manager cannot know whether the close button will close the window or the application. There is hardly anything we can do about this. Because of that I think it does not make any sense to keep this request open in the hope that something happens which makes this possible. The current behavior seems to be that the button closes the window and the applications inform if it does not close the application. So I would even say that the request is actually implemented, just in a different way. (In reply to comment #8) > The current behavior seems to be that the button closes the window and the > applications inform if it does not close the application. So I would even > say that the request is actually implemented, just in a different way. This seems to be a misunderstanding. The request seems to be for a hint on strict ./. weak MDI, ie. whether closing the (last) window will also close the application, where "close to systray" would be a common implementation. The killhelper works different by pinging the window and offering to kill it on no echo. The original request is bait for a flamewar (apple has strict SDI ever ;-) and actually does require a hint from the client to be done for half baked SDI systems. (In reply to comment #6) > Another approach would be to treat this as window behaviour, so user could > register all apps that dock in systray. In case this suggest to "minimize to systray" - this doesn't cut it, because closing is not minimizing (for the latter, the WM just takes the window out of sight, while upon closing, the client will really destroy the window. free resources, alter processing etc.) ie. eg. make amarok minimize to systray would likely break amarok's current systray behavior. "The request seems" I rephrase: 1 icon = 1 meaning 1 meaning = 1 icon Current state of UI is in this regard buggy. That's all what I wanted to say. HOW to solve this I can only suggest, there are several ways to do this. |