Re: Still need a hint for undecorated windows

[Havoc Pennington <hp redhat com>]

On Thu, 2005-08-04 at 00:58 -0400, Adam Jackson wrote:
> > It also sounds like the app could be much _improved_ with WM support. If
> > you're tiling the windows together, the WM could guarantee they stay
> > that way and stick together in the stacking order, for example.
> 
> That's a possibility, though I think on group raise the app will reposition 
> the windows to be tiled, and then preserve that on control+drag, and really 
> without the decs how else would you move them (yeah yeah, clever pagers; 
> doctor, it hurts when I do this). 

My take on this app from your description is that "just turn off
decorations" doesn't really work well enough if it were a mainstream app
(stacking, pager/tasklist, moving, etc. have little unpolished bits and
oddities). But, my experience with people that use GL development tools
is that they're probably OK with that, since most of the apps like Maya
are sort of highly nonstandard UI-wise, and people have old Tk apps and
stuff like that mixed in also.

This is maybe a good example of the hack being good enough. Though there
is a feature I've thought about for drawers and for xmms's "stuck
together windows" which is to be able to attach one window to another
one. This could apply to your app also if we implemented it.

> > There's a way to get rid of decorations now, which is the MWM hint. I'm
> > not being purist; I implemented the hint along with everyone else. The
> > short-term fix is in place. Great.
> 
> It.  Isn't.  In.  The.  Spec.
> 
> If I need to get my app out the door and I don't have time to wait for 
> metacity to turn around and deliver support, then I want a standard method 
> that gets me to 90% _now_.  Perfect being the enemy of done and all that.
> 
> And you can say "but we have the mwm no-decoration hint everywhere anyway" all 
> day long, but while this list now knows that, no one would discover this 
> feature by reading the spec.  If wm-spec.html is not for documenting the 
> standard interactions with the window manager, what is it for?

It's a reasonable point. Having a note in the spec like "this is how the
legacy MWM hint works, and most WMs support the decorated flag" seems
fine to me.

Metacity supports several of the MWM flags in fact, not only the
decorated flag, but nobody uses the other ones...

> > One of the reasons I'd like to avoid the MWM-hint approach is that it
> > keeps us from narrowing down TYPE_NORMAL; I'd like to really make this
> > type mean "main app window" and push things like XMMS into a separate,
> > clearly-marked type. This allows the WM to do nicer things with
> > TYPE_NORMAL since TYPE_NORMAL becomes more meaningful.
> 
> Wandering slightly OT here, but what nicer behaviour for TYPE_NORMAL would you 
> want?

I think I used to have more ideas, there were some things I did in
original metacity that I had to back off from because they hosed all the
xmms-type apps. Offhand, an example is different placement rules (e.g.
main windows always centered or something).

Havoc