🚀 go-pugleaf

In article <221@roo.UUCP> janssen@parc.xerox.com (Bill Janssen) writes:
> In article <9002231624.AA01344@devnull.sun.com>, dshr@SUN (David Rosenthal) writes:
> >...It is necessary to be very careful when you quote the ICCCM.  Here are
> >the actual words from Section 5.1.1:
> >
> >	The client communicates with the session manager by placing
> >	two properties (WM_COMMAND and WM_CLIENT_MACHINE) on its
> >	top-level window.  If the client has a group of top-level
> >	windows,  these properties should be placed on the group
> >	leader window.
> > ...
> >There is no implication that multiple top-level windows have to be in the
> >same group...
> 
> I feel there is a very *clear* implication that top-level
> windows of a single client should be in the same group, and that a
> client with multiple top-level windows should create a group and place
> its top-level windows in that group.  But I agree that ICCCM does not
> explicitly *say* this, but rather says something less precise.

The ICCCM says exactly the right thing.  For instance, suppose that I
want to run something like WINTERP as a server into which I down load
the UI part of my application.  This interpreter/server might be
simultaneously running several distinct application's IU drivers, but
it would be, from the point of view of the server, just one client.

Or consider a "deskset" suite of applications.  These might all be
driven all from one client but would conceptually be different
applications (or not).

Or consider a hypothetical extremely huge all-singing all-dancing
editor. [I won't name names, but its initials are GNU :-).]  You
might have one of these things per client machine acting as an editing
server and have an editor-client command which really just asks the
editor server to pop up a new window for you.  But why do *you* care
how it works?

There is no reason why anything in the ICCCM should preclude this
architecture or any other in which a single client implements distinct
"applications" (which would probably want their windows in separate
groups).

Stan Switzer  sjs@bellcore.com