Xresources, Xt, and beyond

[Ivan Shmakov]

[Cross-posting to news:comp.windows.x.intrinsics and
news:comp.windows.x, and setting Followup-To: there, for the
discussion is hardly Slackware-specific.]

Cool. I didn't know you could do that. I still don't get the syntax.

There are alot of powerful things about X that have been mostly
forgotten by more "modern" toolkits.

Sad but true.

[...]

In general, there is a hierarchy of tech that adds to the basic Xlib,
such as Xt, Motif, and so forth. If your application uses only Xlib,
then you can only access properties that Xlib provides or that were
provided explicitly by the application. On the other hand, if your
application is written in Motif, which is a layer on top of Xt, which
is a layer on top of Xlib, then you can access all the properties
that a widget inherits from Xt and Xlib, in addition to any specific
Motif properties that a widget may have.

It was my understanding that Xlib doesn't provide any widgets,
and that the core widgets are provided by Xt. On top of which
there were a variety of toolkits, such as Xaw, Xaw3d, LessTif,
and (non-free) Motif.

Unfortunately, other toolkits like GTK or Qt break this X
abstraction, and tend to reimplement this functionality in their own,
more complicated and less regular form.

One possible explanation to this is that these toolkits were
intended to be usable outside of X. The other is that,
unfortunately, there're a number of cases when the X resources
fail to do the thing.

For instance, if the colors, or a font face, is specified once
in app-defaults, like:

App*foreground: wheat
App*background: darkslategray

it's trivial to override this setting via command line, like:

$ app -xrm '*foreground: navyblue' -xrm '*background: gray' &

Unfortunately, there's no easy way to override the colors of an
application whose widgets are colored differently, like:

App*foreground: wheat
App*background: darkslategray
App.Widget.foreground: green
App.Widget.background: black

There, the command above will force the colors for all the
application widgets except the one of the Widget class.

Tk seemingly gets it right, by extending X resources with
priorities. Still, the X server resource database is just one
of these priorities from the Tk's point of view.

[...]

All this reinventing the wheel is one of the reasons that I like to
stick with Motif applications a lot. For example, I recompile Emacs
to use Motif instead of GTK, which makes it easier for me to tweak
with Xresources,

FWIW, Debian includes a Emacs binary linked with Xaw3d.

or I just use the NEdit text editor, which is also written in Motif.

[...]

[Aaron W. Hsu]

Post by Ivan Shmakov
It was my understanding that Xlib doesn't provide any widgets,
and that the core widgets are provided by Xt. On top of which
there were a variety of toolkits, such as Xaw, Xaw3d, LessTif,
and (non-free) Motif.

This is my understanding as well, except that Motif is a little better than
non-free, and IMO should be used instead of LessTif on FOSS machines.

Post by Ivan Shmakov
The other is that, unfortunately, there're a number of cases when the
X resources fail to do the thing.
For instance, if the colors, or a font face, is specified once
App*foreground: wheat
App*background: darkslategray
$ app -xrm '*foreground: navyblue' -xrm '*background: gray' &
Unfortunately, there's no easy way to override the colors of an
App*foreground: wheat
App*background: darkslategray
App.Widget.foreground: green
App.Widget.background: black
There, the command above will force the colors for all the
application widgets except the one of the Widget class.
Tk seemingly gets it right, by extending X resources with
priorities. Still, the X server resource database is just one
of these priorities from the Tk's point of view.

Xresources are certainly not perfect. I think the problem here is that
it is not good style for applications to be encoding colors in their own
app-defaults file. However, it is possible to replace or override an
app-defaults file if so desired, but it is more work than just setting
some resources in Xresources.

I have some applications that work like this, and I have switched their
themes successfully, so I think that mostly tweaks are necessary to make
Xresources better, rather than reimplementing the whole system.

The nice thing about X resources is that they provide a universally useful
means of setting properties, and I hate to see toolkits duplicating this
functionality in ways that makes it impossible to work across toolkits.