Return to Answer

The same sort of trepidation arises from

 color_buttons[i].color->pixel |= 0xff << 24; 

This line mysteriously initialises one member of a struct whose complete definition (and use) requires a bit of research. malloc() is not calloc(), so there's every possibility that uninitialised values may be different between compilations. What appeared to work for the past month suddenly exhibits bizarre behaviour.

Don't allow variables to wander off uninitialised!

Finally, why create this alias?

typedef XftColor Clr; 

There are so many variations of "color" (abbreviated, plural, w/ suffix) that the code becomes difficult to track. As noted by @Chux, the only place Clr is used is where it should not have been used. Try to simplify, not to make things more opaque.

 int i = 0; for ( ; i < NUM_COLORS && cur_win != color_buttons[i].win; i++) { /* scanning through array */ } if ( i < NUM_COLORS ) XSetForeground(dpy, ... else XDrawPoint(dpy, ... 

 int i = 0; while( i < NUM_COLORS && cur_win != color_buttons[i].win ) i++; // scanning through array if ( i < NUM_COLORS ) XSetForeground(dpy, ... else XDrawPoint(dpy, ... 

Avoid extra variables

There's a very small gain to be had by eliminating one superfluous variable:

 int flag = 0; // Say bye-bye, flag! for (int i = 0; i < NUM_COLORS; i++) { if (cur_win == color_buttons[i].win) { XSetForeground(dpy, ... flag = 1; break; } } if (!flag) XDrawPoint(dpy, ... 

And, without flag:

 int i = 0; for ( ; i < NUM_COLORS && cur_win != color_buttons[i].win; i++) { /* scanning through array */ } if ( i < NUM_COLORS ) XSetForeground(dpy, ... else XDrawPoint(dpy, ... 

It's fewer lines, and one trivial stack variable removed.
In this instance, the reader is trying to keep track of these (unfamiliar?) library objects and functions, the sequence of operations, the coder's approach to solving the project, and a bevy of transient variables.

As long as clarity (and correctness!) is not sacrificed, strive to maximise the utility of fewer resources.