Creating windows without a minimize button

[Thomas Lübking]

Am 19.03.2012, 02:23 Uhr, schrieb Nikos Chantziaras <realnc at 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transiency.cpp
Type: application/octet-stream
Size: 702 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120319/97bb103e/attachment.obj>