evans@decvax.dec.com (Marc Evans) (08/03/90)
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 ===========================================================================
mikey@eukanuba.wpd.sgi.com (Mike Yang) (08/03/90)
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