Re: Still need a hint for undecorated windows

[Havoc Pennington <hp redhat com>]

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

 - 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