Am 19.03.2012, 02:23 Uhr, schrieb Nikos Chantziaras <rea...@gmail.com>:
On 18/03/12 15:04, Martin Gräßlin wrote:The hint you want to set would only remove the minimize button but does not prevent you from minimizing the window as like I wrote there is no hint to forbid window minimization. This of course applies for all X11 based window managers (other platforms like Mac OS or Microsoft Windows are irrelevant), especially also for GNOME's Metacity as KWin follows Metacity's interpretation of Motif hints: "To quote from Metacity 'We support those MWM hints deemed non-stupid'".Hmm, can you elaborate a bit on this? As mentioned, I tried Gnome (on Debian 6), and Metacity (v2.30.1) doesn't show a minimize button. Also, it doesn't allow for minimizing through the title bar system menu (the "Minimize" menu item is grayed out.)
I'll jump in here since i don't know how much time Martin has at.Aside that the comment is about a decade old or so, Metacity still gives a s*** on your hints ;-) So does compiz. E17 and awesome do not care about MWM hits at all (not even whether the bar is decorated)
The Button layout comes with the NETWM window type (proof attached, feel free to play with it) Metacity does not allow dialogs (any dialog) to minimize or maximize, compiz only to maximize, E17 allows you to configure the decoration style even at runtime and awesome does not have titlebars ;-)
Please trust me or Martin or google for thoughts on MWM hints - whatever is the solution of your issue (i don't say there's none) it is NOT the MWM hints.
Period ;-)NETWM was introduced for the idea that windows should not control their window behavior, but hint a reasonable type and let the WM / DE decide what to do with it.
I wonder if KWin could do the same. On first sight, it doesn't seem to break anything.As mentioned before, kwin used to prevent minimization of transients, the pre-pre-maintainer (not me ;-) altered that because kwin started to handle modal dialogs smarter (see my former mail)
Most important here is that sheer transients (different from modals*) have no strong context with their leaders, ie. if you've an open dialog and allow the main window to be up w/o the open dialog, the main window is "dead" for no apparent reason. On the other hand you can open a bazillion file property dialogs and happily close a bazillion - 1 to unclutter your desktop. Dolphin remains fully usable all the time.
Now, i don't know whether you want to argue that no dialog should ever be minimizable or maximizable, but if you argue for the taskbar, non of my windows should be minimizable because my "taskbar" shows no windows at all.
It's not like we are not aware that the taskbar handling of transients as "skiptaskbar" (yes there's an explicit WM_STATE hint for that) causes an issue in context with the relaxed handling of them in kwin (present bug report, see former mail as well), but:
a) MWM is not a solution (i hope you got that now ;-)b) I still do believe that this should be handled by the taskbar because it is the item with limited access. -> i cc'd plasma and craig - if there'd be consens about handling this in libtaskbar, i'll happily write a patch.
Cheers, Thomas*<dev>there's btw. confusion about that at the mutter fraction, there's a wiki which suggests to rely on MWM hints for that, we might want to contact them</dev>
transiency.cpp
Description: Binary data
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
