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 _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list