Re: Still need a hint for undecorated windows

[Bill Haneman <Bill Haneman Sun COM>]

Havoc Pennington wrote:

> On Sat, 2005-06-25 at 12:19 -0400, Adam Jackson wrote:
>  
>
> > On Thursday 23 June 2005 10:52, Havoc Pennington wrote:
> >    
> >
> > > So my more serious answer is that if we want a non-semantic hint the MWM
> > > hint is fine. It's ugly and crufty, but realistically we have to support
> > > it anyway in both toolkits and WMs, so why add an additional hint to
> > > write code for.
> > >      
> > I don't disagree with this approach, but it would be delightful if this were 
> > noted in the spec.  The current language (in my reading) makes it sound like 
> > the TYPE hints are intended to be a complete replacement for the mwm hints.
> >    
>
> My take would be that they _are_ intended to be complete replacements -
> i.e. ideally we would like to have semantic hints that cover all the
> reasonable cases people want to use the mwm hint, and so if a case is
> not covered, either it's a spec bug, or an out-there app we don't care
> about for the sort of relatively-mainstream scope of the spec.
>
>  
>
> > I've had a few cases now of people wanting to be netwm-compliant in their 
> > toolkits asking what the "correct" way to get an undecorated window is.
> >    
>
> I think the answer is 1) either fix your app or report a wm-spec bug,
> and 2) use MWM hint while you're waiting.
>
> I do agree the spec could explain this further, and perhaps also note
> cases we've already decided are too "out there" to spec.
>
> My sense is that we have pretty complete semantic coverage, fwiw. All
> the usage of MWM hint mentioned in this thread so far has been pretty
> weak.
>
> Missing semantic things I know of:
>
> - popups that are really part of the window they are transient for, 
>   e.g. Epiphany toolbar editor used to be like this but didn't work
>   with current WMs, or it sounds like the Eclipse thing Billy mentioned
>   though I haven't seen that thing, or maybe some input method stuff. 
>   These windows might be undecorated and be moved along with their 
>   transient parent maybe.
>
> - onscreen keyboard, which we could never specify the behavior of
>   in enough detail to put in the spec, or maybe we just decided 
>   it was a dock, I don't remember
>  
DOCK doesn't work because it means that the onscreen keyboard is liable 
to be obscured by other windows of type DOCK, in particular focussed 
popups.  So we need something that is really truly in a higher layer : 
not just for onscreen keyboards, but also for magnifiers.  The 
always-on-top hints don't seem to work because of the interpretation of 
how stacking within a layer is supposed to work,  so the consensus was 
IIRC that we needed a new layer.  I prefer TYPE_OVERLAY or TYPE_TOP (the 
latter implying that any future additions would be guaranteed to stack 
underneath this type).

Bill

> - maybe "WINE window" (which could be the same thing as XMMS
>   and Gkrellm really, only the WINE example is more legitimate IMO)
>
> - OS X style "drawers" if someone implemented those might need a hint
>
> Havoc
>
>
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>