🚀 go-pugleaf

> None of these worked.  Yes, I did reload my .Xresources every time.
> If you have any ideas, please mail me directly, I don't think I am on
> the epoch mailing list.

I didn't look closely enough at your description, but you were talking
about a file called .Xresources.  May be you mean .Xdefaults?  If not,
then you need to rename that file to .Xdefaults.

-kam

I have had to give up on using the class and name from an attribute
list to get what I want.  Debug your situation using 'xprop', an X
goodie that tells you (some of?) the properties on a window.  I betcha
it isn't getting set as you expect.  I decided that GWM (my window
manager) is somehow negligent, but it could be epoch problems.  My
trouble is that WM_CLASS is of type string, but seems to be composed
of two strings.  I have trouble setting these.

--
B<   Brian Kahn   blk@security.mitre.org   "may the farce be with you"

In article <9105141520.AA20233@atlantis.coral.com>, don@atlantis.coral.com (Don Dewar) writes:
> Ok, uncle, I give.  I tried the following to be able to set resources
> for specfic epoch screens from my .Xresources file, which I load with
> xrdb.

Sigh. This isn't what the window name and class refer to. Resources
are loaded by the application name and class. The window name / class
default to the application name / class, but are primarily only for
the use of the window manager. The X resource information is loaded
only once, at startup time.

If you've applied patch 1 and 2, you should have a primitive available
called (get-default), which you could use to query the default values.
Again, because of the way X resources work, you'll get the value at
the time Epoch started, not the current value.

If you get really desperate, you can always just get the xrdb
informtion into a buffer and hack it directly.

On a related subject, Brian Kahn writes:
>I have had to give up on using the class and name from an attribute
>list to get what I want. [ ... ] My
>trouble is that WM_CLASS is of type string, but seems to be composed
>of two strings.  I have trouble setting these.

Yes, the WM_CLASS property consists of 2 strings, null seperated, the
name and class. If you want to set them inside Epoch, use a construct
like

(defvar xa-wm-class (intern-atom "WM_CLASS"))
(set-property xa-wm-class (list "Window name" "Window Class"))

You can examine the current value with (get-property xa-wm-class),
which should return a list of 2 strings. Note that a WM does not have
to notice changes to this property except upon an unmap / map of the X
window.

-- 
Alan M. Carroll          <-- Another casualty of applied metaphysics
Epoch Development Team   
Urbana Il.               "I hate shopping with the reality-impaired" - Susan

Epoch will not make use of alternate (xrdb) resources if you change
the name or class of a window.  Epoch checks the resources when it
starts up, and uses those values for all windows.  This means that one
cannot get a new window to use a different font just by changing the
name or class attribute/property on creation (or thereafter).

Is this a bug?  Reading the resources every time a window opens might
be slow, I suppose.  Does it take long to query the Xserver for
name*resources?


	
--
B<   Brian Kahn   blk@security.mitre.org   "may the farce be with you"

|> Epoch will not make use of alternate (xrdb) resources if you change
|> the name or class of a window.  Epoch checks the resources when it
|> starts up, and uses those values for all windows.  This means that one
|> cannot get a new window to use a different font just by changing the
|> name or class attribute/property on creation (or thereafter).
|> 
|> Is this a bug?  Reading the resources every time a window opens might
|> be slow, I suppose.  Does it take long to query the Xserver for
|> name*resources?

Certainly there will be some overhead, but not enough to be worried 
about.  Xt fetches all kinds of resources every time an object is
created.  It does not require a trip to the server because the application
(toolkit) builds it's own copy of the resource database at startup.  In the
OI toolkit, we also fetch resources on a per object basis and have found
through profiling that it is NOT a big time consumer.

--
(I kid you not)Tom LaStrange        toml@Solbourne.COM