Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!decwrl!sgi!shinobu!odin!eukanuba.wpd.sgi.com!mikey
From: mikey@eukanuba.wpd.sgi.com (Mike Yang)
Newsgroups: comp.windows.x
Subject: Re: WM_CLASS doesn't appear to be proper
Keywords: WM_CLASS, xrn, XRn
Message-ID: <11363@odin.corp.sgi.com>
Date: 3 Aug 90 16:38:53 GMT
References: <177@decvax.decvax.dec.com.UUCP> <3209@decuac.DEC.COM> <183@decvax.decvax.dec.com.UUCP>
Sender: news@odin.corp.sgi.com
Reply-To: mikey@sgi.com
Organization: Silicon Graphics, Inc.
Lines: 47

In article <177@decvax.decvax.dec.com.UUCP>, evans@decvax.dec.com (Marc Evans)
writes:
> Why is the CLASS of mxrn "xrn" while the original sources from which the
> program is derived (xrn from berkeley) uses the CLASS "XRn"?

In article <183@decvax.decvax.dec.com.UUCP>, evans@decvax.dec.com (Marc
Evans) writes:
> Well, I don't feel strongly about the issue, but it does bring out a nit that
> I have about the use of WM_CLASS. It is my opinion that programs which
are used
> for a same primary purpose belong to the same CLASS.
>
> ...
>
> Personally, given this trend, I see little benefit to the
> differentiation of the values WM_CLASS and argv[0].

The class of mxrn (a Motif-modified version of xrn available within
DEC) probably should be the same as xrn just so that people who have
xrn resources don't have them duplicated once for xrn, and again for
mxrn.  Although mxrn isn't xrn, it mostly understands the same
resources.  Otherwise, conventions says that the class for mxrn should
be "Mxrn."

WM_CLASS is set by the author of the program.  argv[0] depends on the
installation.  This is why it's a good thing for me to specify my xrn
geometry as "XRn.geometry: ..." rather than "xrn.geometry" because the
former will not work if my xrn binary is called "xrn6-10" because I
have multiple version laying around.

Although a "superclass" designation like "Clock" would be useful for
extremely common situations like geometry or color, unless there was
some standard for the set of resources understood by "Clock" programs,
being able to designate resource specifications for all "Clocks" would
have limited utility.  The fact that mxrn is derived from xrn makes
sharing resources possible and useful.

On the other hand, there are situations other than resource
specification which makes superclasses (WM_SUPERCLASS?) desirable.
For instance, identifying all the windows with superclass "Editor"
would be useful if there was an ICCCM protocol which all "Editors"
understood.  Then, programs like xrn or xmh could share an available
editor window on the display, if desired.

-----------------------------------------------------------------------
                 Mike Yang        Silicon Graphics, Inc.
               mikey@sgi.com           415/335-1786