Path: utzoo!utgpu!water!watmath!clyde!rutgers!mailrus!umix!husc6!bloom-beacon!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!hpcea!hpfcdc!hpfclp!diamant
From: diamant@hpfclp.HP.COM (John Diamant)
Newsgroups: comp.windows.x
Subject: Re: Decoration Properties
Message-ID: <9740009@hpfclp.HP.COM>
Date: 12 Feb 88 03:55:38 GMT
References: <8802101710.AA17136@audi>
Organization: HP SDE, Fort Collins, CO
Lines: 42

> In particular, to tell wm's that you want xterm to have purple
> headers, you can put in your defaults file
> 
>     Wm.xterm.HeaderBackground: purple

The use of the "Wm" resource class for all window managers has always
bothered me.  I recognize this from the conventions manual David Rosenthal
is writing.  The problem is that the standard convention for res_class
is the "name" of an application (typically argv[0]).  Now, I understand
that the name doesn't always have to be argv[0], but I believe it does
have to be something that uniquely identifies one application from another
(even another application which performs the same function).

If you follow a consistent set of conventions, then the window manager
res_class must be something like "uwm" or "wm" (that specific window
manager) or whatever, but not "Wm."

What this boils down to is the need for more than two levels of class
structure in the resource database.  We need:

unique identifier of instance (res_name -- buffer1)
unique identifier of application (res_class -- emacs)
class of application (??? -- Editor)

Both you (Ellis) and I raised mentioned this issue at the Toolkit
BOF.  You've come up with a way of doing this apparently by specifying
the superclass in the .Xdefaults (app.Superclass or something, if I
remember correctly), and we've proposed using an #ATTACH pseudo-op in
the .Xdefaults file (#ATTACH Editor TO emacs).

I don't care which method is used, though I believe a standard
method would be much better than everyone coming up with their own.

I think it is strongly indicative of the need for such an enhancement
when a document designed to specify conventions must violate the
very conventions it is documenting, in order to provide a piece
of needed functionality.

John Diamant
SDE				UUCP:  {hplabs,hpfcla}!hpfclp!diamant
Hewlett Packard Co.		ARPA Internet: diamant%hpfclp@hplabs.HP.COM
Fort Collins, CO