Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!decwrl!bacchus.pa.dec.com!decvax.dec.com!decvax!evans
From: evans@decvax.dec.com (Marc Evans)
Newsgroups: dec.news.software,comp.windows.x
Subject: Re: WM_CLASS doesn't appear to be proper
Keywords: WM_CLASS, xrn, XRn
Message-ID: <183@decvax.decvax.dec.com.UUCP>
Date: 3 Aug 90 11:49:24 GMT
References: <177@decvax.decvax.dec.com.UUCP> <3209@decuac.DEC.COM>
Sender: news@decvax.dec.com.UUCP
Reply-To: evans@decvax.DEC.COM
Followup-To: comp.windows.x
Organization: Synergytics
Lines: 55

In article <3209@decuac.DEC.COM>, murphy@ufp.dco.dec.com (Rick Murphy) writes:
|> 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"? Personally, I
|> > think these programs should be of the same class, so that if for
some reason
|> > a user switches between them, resources defined using the CLASS
string would
|> > effect both programs. Any comments?
|> 
|> Actually, it's 'mxrn' or 'dxrn' depending on how it's compiled.
|> At one point, I fixed this bug by changing the names to MXrn and
DXrn. It broke
|> everyone's resource files, so I changed it back.
|> 
|> I don't think changing the class back to 'XRn' would be very
productive; while
|> there's some number of similar resources, much of the contents of my
resource
|> files for the two variants (dxrn and mxrn) are different. I would expect an
|> even larger change for an Athena based application.
|> 
|> And of course, the argument is that my program is *not* Xrn.. it's derived
|> from it, but the differences these days are pretty major.
|> 
|> Anyone else feel strongly about this?

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. mxrn, dxrn, and xrn all
fit into that catagory. I would compare this to all of the clocks that exist in
the X community. Virtually none of them use the same CLASS strings. This makes
it a pain to switch between clocks with any consistency (i.e. make any client
of CLASS "Clock" have geometry G). The following is taken from the output of
the xprop program:

WM_CLASS(STRING) = "oclock", "Clock"
WM_CLASS(STRING) = "xclock", "XClock"
WM_CLASS(STRING) = "Clock", "DXclock"

Talk about confusing, eh, especially the first and third classes.

You have in fact followed suite in what most X clients in the world do, define
yet another WM_CLASS. Personally, given this trend, I see little benefit to the
differentiation of the values WM_CLASS and argv[0]. I am probably sending this
to the wrong audience though (I'll send it to comp.windows.x as well).

- Marc

===========================================================================
Marc Evans - WB1GRH - evans@decvax.DEC.COM  | Synergytics     (603)635-8876
      Unix and X Software Contractor        | 21 Hinds Ln, Pelham, NH 03076
===========================================================================