On 7/25/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > Do note that decorations and window functions are orthogonal, and that > asking to be borderless means you've accepted that your life will be hard. > When it becomes sufficiently hard that users complain, you've had enough > usage experience to accurately defined the semantics you want, so only > then are you armed with enough information to extend the netwm spec. > > Cart. Horse. One of these goes first. > > > That said, I agree we have a problem that not enough semantic types > > are covered in the spec. But the right way to converge to a > > consistent solution is to add more semantic hints (and I think you had > > some good cases for adding more) > > How are these semantic hints supposed to be developed before they land in > > the spec? All new semantic types that affect decoration can be emulated > (perhaps poorly) by starting with no decoration and doing your own for a > while.
Very good points. I think it comes by, for example, having some WMs support those deprecated hints (currently, I believe most do)--such apps really only need one WM to do such developing and testing. I also think that it comes with nonstandard extensions that may later be adopted (e.g. _KDE_NET_WM_USER_CREATION_TIME, _METACITY_VERSION, etc.) > > , not to adopt a short term "fix" that > > sends us down the wrong path (besides, I'll note that we already have > > a short term fix--most WMs support these deprecated hints for now > > anyway and will probably continue to do so for the forseeable future) > > If this behaviour is desirable, why isn't it in the spec? Hide it behind > SHOULD or MAY or whatever if you like, but write it down somewhere. When > > app developers go to write new code, and need a wm interaction, they think > to look in ICCCM and net-wm. Obscure Motif docs are not considered useful > sources of information for writing new qt or gtk apps. Obviously looking in (I'll just note that there's a gtk_window_set_decorated() and I'm guessing qt has something similar though I haven't verified--so app authors wouldn't have to look in obscure motif docs) > docs that describe a toolkit you are not targetting is the sane rational way > to get the API you need. Perhaps people are pointed to such obscure docs because there's a feeling that the majority of the usage of such hints is abuse (Tuomo would probably say all such uses are)... ;-) Besides, supporting workarounds tends to defeat forward progress. Granted, I understand that workarounds are needed when progress is not far enough along yet, but that's what the support of deprecated hints is for. Cheers, Elijah _______________________________________________ wm-spec-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/wm-spec-list
