WM SPec purpose (was: Re: wms offsetting XMoveWindow() coords)

[Tim Janik <timj gtk org>]

On Mon, 27 Sep 1999, Nathan Clemons wrote:

> On Mon, 27 Sep 1999, Michael ROGERS wrote:
> 
> > 
> > Alternatively, we could just specify one of these behaviours as "correct" in
> > the spec, so only half the window managers will need to be modified.
> > 
> 
> It seems to me that from what the others are saying, ICCCM has already
> deemed the first behavior as "correct" and the latter as incorrect.
> Perhaps the spec should only serve as a reminder of this fashion, or
> provide a workaround if it seems like it will not be adhered to.

hm, we'd then at least need a _NET_ICCCM_COMPLIANT_MOVES property, that
those window managers set on their WM identification window.

> > > Michael Rogers 
> > 
> 
> On 23 Sep 1999 23:56:30, Eliot Lee wrote:
> 
> > I hate to break it to you, but everyone I've talked to hates that web
> > site. wm-spec-list already exists, is the perfect method for discussing
> > the specification, and is convenient & open. The web site is awkward to
> > use, still isn't totally open for all to access, and requires people to
> > remember Yet Another Password in order to manipulate.

> Ok, this is time for the group to open up and answer the question. Is this
> the general impression that people have of the site? If so, it is no big
> loss. A few hours worth of coding time is by far worth the attempt, even
> if it is a complete and total loss.

imho, the current model of using email feedback was nice (though partly
a bit "unfocused"), i'm keeping a personal archive for occasional review
and am able to use the threading abilities of my mail reader. and -at least
for me- most importantly, i can perform all neccessary tasks offline.

> However, if the site isn't going to do it, then fine, so be it. But my
> second question is, who has been keeping track of the draft spec since
> Marko had to hand it over, and who wants to arbitrate the next one? Is
> that something you want me to do? If so, I will, but you'll have to
> correct me when I'm wrong (though that is the usual mechanism of things).

i don't mind *who* actually maintains the spec and puts out new drafts.
however, a new and updated draft should defintiely be posted here again
soon ;)
i think part of the problem you outlined is due to people (me included) being
lazy in structuring replies on the spec. it'd be nice if the Subject: lines
would identify the _NET_* properties in question, and if several replies would
be formed from a draft for different issues (e.g. properties being discussed).

> My third question is, does anyone have a solid idea of how close we are to
> being "done"? In my honest opinion, I do not believe that we can honestly
> say we are even close when there is still confusion as to what we are
> aiming towards supporting via this specification. We have never concretely
> outlined what this spec covers and does not, and attempts to do so have
> not resulted in comments by members of this list.

i've got a few remaining issues and i'm certain other people on this list have
some as well, so i think we should probably have a new spec posted here,
comment on that and consider new properties/properties to be changed, that
are being brought up, come up with one or two new drafts and crosspost that
for public comments to other forums, e.g. gnome/kde developers.
that way we can have broader feedback for something we consider pre-final,
and concentrate on remaining issues.

on the purpose of this spec, you are definitely right: we have to focus
on the problem at hand, rather tahn fighting over policies or abilities
we give/don't give to the programmers. a good guide line here is probably
what we want to solve:
1) we meant to revise the GNOME WM spec, since it is broken and not well
   though out in some areas
2) we meant to incorporate KWM and GNOME features, so certain wm-related
   facilities are not tight to a particular desktop project and we allow
   for proper wm<->application interaction, regardless of toolkit/desktop-
   project origin of either one

which basically boils down to:
- provide means for applications to hook into root window input events,
  i.e. mouse clicks and key presses
- provide hints for overall appearance, e.g. theme settings or background
  settings
- provide a comprehensive protocol for pager+tasklist interaction with
  the window manager
- provide additional hints to window managers from the applications,
  supplementing what is already specified through MWM hints and the ICCCM,
  so application windows can for instance provide specialized icons,
  announce states, request layering, request desktop/area positions or
  prohibit "delete win" buttons, etc...

we do not want to specify policy (e.g. "always use click-to-focus") or
overly complexify window manager implementations (e.g. basing it on
CORBA) and introduce new dependancies for them (be that MICO or ORBit,
one side will definitely be unhappy, not to mention third party app writers).

as far as window manager customization goes, specification of an all-doing
protocol that would allow an application provided GUI (e.g. a GNOME capplet)
to control all of a wm's behaviour aspects and configuration, is definitely
beyond the scope of this spec.
we'll get nowhere discussing this all over again, and the protocol would
never cover all wms' requirements. if people insist on such a thing, they
are better off starting a new spec project for that purpose only and not
holding off production of this one.

areas where we encounter major disagreements, but still recognize justified
needs can be specified as "optional" in the spec, e.g. the recent layer
discussiong comes to mind. or usage of desktop areas, many wms still don't
provide desktop areas while providing multiple desktops, the last spec didn't
actually take that into account.

other areas where we smell policy conflicts should also be specially outlined
in the spec, e.g. by mentioning that special care should be taken to not let
conflicts appear with wm shortcuts vs. application shortcuts or root window
clicks (similar things apply for the layering hints).

> If we can answer these three questions and move on, I think we will all be
> quite a bit happier and a lot closer to "completion" (as if there is ever
> such a thing).

ok, i've outlined how i feel about the issues you raised, i'm pretty confident
that we can produce a good requirements-covering spec, if we just show a
little more discipline in discussions and present will for cooperation.
i think we can assume that most people have already worked in cooperational
effords and don't want yet-another-wm-spec be released by some side-stepping
minority limited in scope or bound to a certain project, so potential for
finding a common wm-spec basis is definitely in existence.

> 
> --Nathan
> 

---
ciaoTJ