Facelifting XClock while using Xrender: A long and winding road

Question

Basically, xclock is a great tool, and every basic X setup would have it "onboard". However, configuring xclock (analog) while keeping XRender active is definitely not for the faint of heart. In particular, beginners will not have any chance to configure the analog clock without delving deeply into the .Xresource realm, since everything you set at the command line will be for the non-rendered mode only (requires option -norender) and ignored by default (which means, that XRender is being used). Plus, the documentation about it is abysmal, and examples which actually deal with XRender are rare as hen's teeth. Hence, I decided to start my own approach.
I wish there was an easier way to do all this, but there apparently isn't. For one, this question will probably help new users as a guide how to set things up for "their" xclock; on the other hand, I'd also like to ask you guys if there is any way to improve my "configuration file" (mind the quotes). Oddly enough, .Xresources is widely deemed "obsolete" and "last century", but what if the application you use does rely on the old-fashioned way, using xrdb, .Xresources and the whole caboodle?

I personally fancied a "night design" because it fit perfectly to my desktop style. So this is what I did:

$ touch ~/.Xresources
$ vi ~/.Xresources

XClock*foreground: #fbfbfb
XClock*background: #000018
XClock*update: 1
XClock*geometry:          210x210+1020+12
XClock.Clock.majorColor:  rgba:f0/f0/19/7b
XClock.Clock.minorColor:  rgba:a0/c0/f0/c0
XClock.Clock.hourColor:   rgba:c9/66/11/72
XClock.Clock.minuteColor: rgba:00/82/9f/72
XClock.Clock.secondColor: rgba:50/93/30/6f

rgba stands for "red, green, blue, alpha" - where the fourth parameter, alpha, will indicate the opacity level in hexadecimal notation: a 00 will make the clock hand or tick mark invisible; a ff will turn any opacity off.
So far, so good. Since we do not want to restart the X server for these things to come into effect, we will simply merge our settings into those that may (or, as usual, may not) be already there:

$ xrdb -merge ~/.Xresources && xclock &

Although I hate to brag, I honestly think it looks way better than the boring design which is default on my desktop.

But during my efforts in getting this to work the way I wanted to, there has also a question come up from my side: I actually "stole" the syntax XClock.Clock.<parameter> from the following resource file:

/etc/X11/app-defaults/XClock-color

Interestingly enough, ALL of those parameters which end in ...Color require the same XClock.Clock.<parameter> syntax as in app-defaults; e. g. XClock*hourColor: rgba:ff/ff/ff/80 will NOT get the hour hand white, nor set the opacity to 0x80.

Why is that so?
Up to now, I thought the * was simply a wildcard meaning XClock<whatever><parameter>.

Answer 1

Your assumption is correct. A resource specification using * is a wildcard. Your issue here is because of the fact that you probably have both an XClock* and an XClock.Clock specifications in your presently loaded resources database. In this instance it will prefer the explicit entries to the wildcard ones. You can see what you presently have set in your resource database for your XClock with appres XClock:

 appres XClock
 XClock.input:   false

If I create a resource file with wildcard resources:

XClock*foreground: #fbfbfb
XClock*background: #000018
XClock*update: 1            
XClock*geometry:          210x210+1020+12
XClock*majorColor:  rgba:f0/f0/19/7b
XClock*minorColor:  rgba:a0/c0/f0/c0
XClock*hourColor:   rgba:c9/66/11/72
XClock*minuteColor: rgba:00/82/9f/72
XClock*secondColor: rgba:50/93/30/6f

And then use a load them with a xrdb -merge xclock operation, appres XClock now shows:

$ appres XClock
XClock*secondColor:     rgba:50/93/30/6f
XClock*foreground:      #fbfbfb
XClock*hourColor:       rgba:c9/66/11/72
XClock*update:  1
XClock*background:      #000018
XClock*geometry:        210x210+1020+12
XClock*majorColor:      rgba:f0/f0/19/7b
XClock*minorColor:      rgba:a0/c0/f0/c0
XClock.input:   false
XClock*minuteColor:     rgba:00/82/9f/72

If I start up xclock, I get your nice shiny "nightime" theme. Now if I were to edit that resource file and replace the wildcard resources with explicit resources (note ! is a comment line):

XClock*foreground: #fbfbfb
XClock*background: #000018
XClock*update: 1
XClock*geometry:          210x210+1020+12
XClock.Clock.majorColor:  rgba:f0/f0/19/ff
XClock.Clock.minorColor:  rgba:a0/c0/f0/ff
XClock.Clock.hourColor:   rgba:c9/66/11/ff
XClock.Clock.minuteColor: rgba:00/82/9f/ff
XClock.Clock.secondColor: rgba:50/93/30/ff
!XClock*majorColor:  rgba:f0/f0/19/7b
!XClock*minorColor:  rgba:a0/c0/f0/c0
!XClock*hourColor:   rgba:c9/66/11/72
!XClock*minuteColor: rgba:00/82/9f/72
!XClock*secondColor: rgba:50/93/30/6f

and merge the resource file again with an xrdb -merge xclock, appres XClock now shows:

XClock.Clock.secondColor:       rgba:50/93/30/ff
XClock.Clock.minorColor:        rgba:a0/c0/f0/ff
XClock.Clock.hourColor: rgba:c9/66/11/ff
XClock.Clock.minuteColor:       rgba:00/82/9f/ff
XClock.Clock.majorColor:        rgba:f0/f0/19/ff
XClock*secondColor:     rgba:50/93/30/6f
XClock*foreground:      #fbfbfb
XClock*hourColor:       rgba:c9/66/11/72
XClock*update:  1
XClock*background:      #000018
XClock*geometry:        210x210+1020+12
XClock*majorColor:      rgba:f0/f0/19/7b
XClock*minorColor:      rgba:a0/c0/f0/c0
XClock*minuteColor:     rgba:00/82/9f/72
XClock.input:   false

Note how both explicit and wildcard resources are listed against the XClock class. In this instance xclock will prefer the explicit resource over the wildcard one, and I get the clock with the non-alpha colours.

To fix the issue use a -load operation instead of a -merge operation (xrdb defaults to -load if you do not supply any options, i.e xrdb file is the same as xrdb -load file).

This effectively clears your resources database, loads the system defaults and then adds your XClock resource settings in that file. A good trick to know is that you can restore "system defaults" with xrdb /dev/null. You can get a copy of the existing resource database (including system defaults) with: xrdb -query -all which can be redirected to a file, and then edited to your tastes.

On most systems putting these in your .Xresources or .Xdefaults will mean they will get loaded when the X session is created, so you don't have to load them manually from X session to X session.

I use wildcards to set most apps to do white on black (I'm not a fan of black on white):

*background: #000000
*foreground: #ffffff

As to what resources you can set for xclock they are covered in the man page (most X11 commands cover their resources in the man page).

Another thing that is useful to know (and not often documented) is that most X11 commands can be passed -name argument which allows you have resources that are separate to the default app settings, so for an example if I were to have:

Leary*background: #ff0000

as a resource setting and then run xclock with xclock -name Leary I will get an xclock with a violent red background. Any explicit/wildcard XClock resources settings are loaded and then they get overriden with ones set by the Leary class. I can then use it to apply the same settings to say xterm, with xterm -name Leary.

There are a number of these "standard" command line options that most X11 commands use:

-display host:n
     Location of the X server. 
-geometry wxh+x+y
     Window size and location. 
-bg color
     Window background color. 
-fg color
     Text and graphics color. 
-fn font
    Text font. 
-iconic
    Initial window to be started iconized. 
-title strings
    Window header title.