On Tue, May 04, 2004 at 12:20:46PM +0200, Adeodato Sim? wrote: > * Zygo Blaxell at Work [Mon, 03 May 2004 23:52:51 -0400]: > > This is a regression from kwin 3.1.x, which didn't seem to randomly grant > > some windows their full set of titlebar buttons while denying others. > > Generally the three min/max/close options were available for most > > application windows. > > This is not a bug. Each application gets to decide which WM actions > will be available for its windows. So wish & gnome-xbill authors > considered it was better for their apps not to be maximizable, and > xload and xclock were not given the possibility of being minimized. I'm pretty sure this is incorrect, as I've written or maintain a number of applications affected by kwin's change in behavior, and I think I'd remember if I went out of my way to turn off something important like a minimize or maximize button. I'm not even sure how I'd ask for this behavior even if I wanted it. The behavior seems to be defined more by the toolkit the application was written with than whether the buttons in question are useful. For example all Tk apps I've tried so far lack the maximize button in kwin but get the maximize button in all other window managers that I've tried (except of course the WM's that don't have maximize buttons at all). > Every WM has to respect that. I suspect that very few actually do, and with good reason if kwin's behavior is strictly correct. I've tried several WMs and the only behavior consistent with kwin is that gnome-xbill doesn't get a maximize button on either kwin or metacity. This makes sense as the gnome-xbill window is not resizeable at all. > In previous versions, kwin always showed > all three buttons, but you would find that clicking them would do > nothing depending on the app. This is incorrect. Clicking the min/max buttons worked as expected until kwin 3.2.2. I can't think of any reason why they wouldn't work for all application windows under X11, unless the application goes out of its way to force the window to be remapped or resized after a maximize or minimize event occurs, or the application creates an override-redirect window which isn't handled by the WM at all. My understanding of the protocol involved is that the WM simply reconfigures or unmaps the window in question, and X tells the owner of the window later that this has happened. The ability to inform the WM that the option should not be offered in the first place is a relatively recent invention. I think that most of the applications I am having problems with were written before the option to not display WM buttons was widely supported in window managers, if not before the option was even defined, so I don't see how the application could be explicitly requesting anything of the sort. > Since 3.2 (I think) that behavior > changed, and now kwin only displays the buttons *really* available, > which IMO is a good thing. Assuming that the new kwin behavior is correct and that a vast number of legacy applications are incorrect, kwin should at least present the option of ignoring the suggestion for compatibility with those applications that get it wrong. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D
Attachment:
signature.asc
Description: Digital signature