Re: Still need a hint for undecorated windows

[Lubos Lunak <l lunak suse cz>]

Dne so 25. června 2005 22:51 Havoc Pennington napsal(a):
> 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.

 Agreed.

>
> > 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.

 I'm not sure what exactly you mean, but should these be toplevel windows at 
all? If it's really part of the window, it should really be a part of the 
window.

>
>  - 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)

 _NET_WM_TYPE_WEIRD_APP :) ?
 
>
>  - OS X style "drawers" if someone implemented those might need a hint

-- 
 Lubos Lunak
 KDE Developer