Wider Borders in XFCE / Xubuntu

A longstanding Xubuntu / XFCE UI problem has been single-pixel window borders that make click-and-drag resizing essentially impossible. The reason it’s a longstanding problem has been the developers’ unflinching response to any and all issues raised on the bug tracker:

That discussion may be illuminating.

I had never looked for the XFCE theme-building documentation (and, thus, never found any), because building a whole new theme would be a lot of work just to resize the damn borders. It should be feasible to tweak only the borders of an existing theme, but … I stalled.

Repeatedly. On every single version of Xubuntu that’s come along.

Fortunately, someone recently did the legwork and summarized the method, which I slightly adapted:

cd /usr/share/themes/
sudo cp -a Greybird-compact/ Greybird-wide
cd Greybird-wide/xfwm4
for f in bottom left right ; do sudo cp ../../Daloa/xfwm4/${f}* . ; done
sudo sed -i -e 's/C0C0C0/CECECE/' *xpm
sudo sed -i -e 's/A0A0FF/7C7C7C/' *xpm
sudo sed -i -e 's/E0E0FF/E0E0E0/' *xpm

The exact color mapping depends on which two themes you’re using. You can also specify GTK element colors, which seems like a better way to do it. Maybe next time.

Apparently, the corresponding PNG files contain transparency information for the XPM files, but I haven’t bothered to investigate how that works or what might happen if I tweaked them.

Then you select the new Graybird-wide theme and It Just Works.

Sheesh & similar remarks…


Leave a comment

Dual Monitors Redux

My trusty 1050×1680 portrait monitor began resetting itself, which probably indicates failing capacitors in the power supply or logic board; eBay has capacitor kits, but it may not be worthwhile fixing the poor thing. I snagged a new 2560×1440 Dell U2713HM monitor, added a dual-Displayport PNY NVS310 video card, told Xubuntu 14.04LTS to use nVidia’s binary driver, and, somewhat to my astonishment, It Just Worked.

The xrandr report:

Screen 0: minimum 8 x 8, current 4000 x 2560, maximum 16384 x 16384
DP-0 disconnected primary (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440      60.0*+
   1920x1200      59.9
   1920x1080      60.0     59.9     50.0     24.0     60.1     60.0     50.0
   1680x1050      60.0
   1600x1200      60.0
   1280x1024      75.0     60.0
   1280x800       59.8
   1280x720       60.0     59.9     50.0
   1152x864       75.0
   1024x768       75.0     60.0
   800x600        75.0     60.3
   720x576        50.0     50.1
   720x480        59.9     60.1
   640x480        75.0     59.9     59.9
DP-3 connected 1440x2560+2560+0 left (normal left inverted right x axis y axis) 597mm x 336mm
   2560x1440      60.0*+
   1920x1200      59.9
   1920x1080      60.0     59.9     50.0     24.0     60.1     60.0     50.0
   1680x1050      60.0
   1600x1200      60.0
   1280x1024      75.0     60.0
   1280x800       59.8
   1280x720       60.0     59.9     50.0
   1152x864       75.0
   1024x768       75.0     60.0
   800x600        75.0     60.3
   720x576        50.0     50.1
   720x480        59.9     60.1
   640x480        75.0     59.9     59.9

Inexplicably, xsetwacom once again expects the "HEAD-0" parameter that was "DP1" the last time around:

xsetwacom --verbose set "Wacom Graphire3 6x8 stylus" MapToOutput "HEAD-0"
xsetwacom --verbose set "Wacom Graphire3 6x8 eraser" MapToOutput "HEAD-0"

The new display presents crisp characters; seeing 140 source code lines at once is wonderful.


Last of the Energizer CR2032 Cells

All three Energizer CR2032 lithium cells installed at the end of November failed in December, with this being the most dramatic example:

Attic - Insulated Box - Early battery failure

Attic – Insulated Box – Early battery failure

Now, granted, it was mighty chilly in the attic, but failing after 18 hours seems unreasonable. So much for last month’s data.

I’ve started a batch of Maxell cells with the more reasonable date code 3O, which seems to indicate a manufacturing date of 2013 October.

We shall see…


If You See Something, Say Something

Nah, that can’t possibly be a …

Mannequin head - 1

Mannequin head – 1

Tell me it’s not a really bad wig …

Mannequin head - 2

Mannequin head – 2

Gently now …

Mannequin head - 3

Mannequin head – 3


Found on Old Mill Road, just downstream of the Red Oaks Mill dam; the Mighty Wappingers Creek flows on the left.

That’s all I have to say…


Thunderbird UI Tweakage

If you want to change the font in all of Thunderbird’s UI, you must perform this magic ritual:

  • Create the file chrome/userChrome.css in wherever they’ve hidden your profile folder (for Ubuntu 14.04, it’s ~/.thunderbird)
  • Then put this incantation inside:
/* Global UI font */
/* may need !important on each entry */
* { font-size: 14pt ;
  font-family: Arial Narrow ;

As nearly as I can tell, you don’t need the !important tag on the top-level entry, but I don’t profess to grok Mozilla-flavored CSS.

Useful properties:

  • font-weight: normal | bold | light
  • font-style: normal | italic | oblique

Maybe you can do the whole font thing in one shot, but I haven’t tried.

The changes take effect the next time you fire up Thunderbird: dinking with this stuff gets tedious.

This is way too intricate for mere mortals…


Kenmore 158 UI: Button Framework Functions

Given the data structures defining the buttons, this code in the main loop() detects a touch, identifies the corresponding button, and does what’s needed:

if (CleanTouch(&pt)) {
	BID = FindHit(pt);
	if (BID) {
	while(ts.touched())				// stall waiting for release

The CleanTouch() function handles touch detection, cleanup, and rotation, delivering a coordinate that matches one of the LCD pixels. Given that you’re using a fingertip, errors caused by poor calibration or nonlinearities Just Don’t Matter.

This function matches that coordinate against the target region of each button, draws a white rectangle on the first matching button, and returns that button ID:

byte FindHit(TS_Point hit) {

byte i;
TS_Point ul,lr;

#define MARGIN 12

//	printf("Hit test: (%d,%d)\r\n",hit.x,hit.y);

	for (i=0; i<NumButtons ; i++) {
		ul.x = Buttons[i].ulX + Buttons[i].szX/MARGIN;
		ul.y = Buttons[i].ulY + Buttons[i].szY/MARGIN;
		lr.x = Buttons[i].ulX + ((MARGIN - 1)*Buttons[i].szX)/MARGIN;
		lr.y = Buttons[i].ulY + ((MARGIN - 1)*Buttons[i].szY)/MARGIN;
//		printf(" i: %d BID: %d S: %d ul=(%d,%d) sz=(%d,%d)\r\n",
//			   i,Buttons[i].ID,Buttons[i].Status,ul.x,ul.y,lr.x,lr.y);
		if ((hit.x >= ul.x && hit.x &lt;= lr.x) &&
			(hit.y >= ul.y && hit.y &lt;= lr.y)) {
			// should test for being disabled and discard hit
//			printf(" Hit i: %d ",i);

	if (i < NumButtons) {
		return Buttons[i].ID;
	else {
		printf(" No hit!\r\n");
		return 0;


You can enable as much debugging as you need by fiddling with the commented-out lines.

After some empirical fiddling, a non-sensitive margin of 1/12 the button size helped prevent bogus hits. There’s no real need to draw the target rectangle, other than for debugging:

Kenmore 158 UI buttons - hit target

Kenmore 158 UI buttons – hit target

The target shows the button graphics aren’t quite centered, because that’s how the ImageMagick script placed them while generating the shadow effect, but it still works surprisingly well. The next version of the buttons will center the graphics, specifically so I don’t have to explain what’s going on.

Because the margin is 1/12 the size of the button, it rounds off to zero for the tiny button in the upper right corner, so that the touch target includes the entire graphic.

The return value will be zero if the touch missed all the buttons, which is why a button ID can’t be zero.

Given the button ID, this function un-pushes the other button(s) in its radio button group, then pushes the new button:

byte HitButton(byte BID) {

byte i,BX;
byte Group;

	if (!BID)											// not a valid ID
		return 0;

	BX = FindButtonIndex(BID);
	if (BX == NumButtons)								// no button for that ID
		return 0;

	Group = Buttons[BX].Group;

//	printf(" Press %d X: %d G: %d\r\n",BID,BX,Group);

// If in button group, un-push other buttons

	if (Group) {
		for (i=0; i<NumButtons; i++) {
			if ((Group == Buttons[i].Group) && (BT_DOWN == Buttons[i].Status)) {
				if (i == BX) {							// it's already down, fake going up
					Buttons[i].Status = BT_UP;
				else {									// un-push other down button(s)
//					printf(" unpress %d X: %d \r\n",Buttons[i].ID);


	return 1;

The ID validation shouldn’t be necessary, but you know how things go. A few messages in there would help debugging.

The default button action routine that I use for all the buttons just toggles the button’s Status and draws the new button graphic:

void DefaultAction(byte BID) {

byte i,BX;

	if (!BID) {											// not a valid ID
		printf("** Button ID zero in DefaultAction\r\n");

	BX = FindButtonIndex(BID);
	if (BX == NumButtons) {								// no button for that ID
		printf("** No table entry for ID: %d\r\n",BID);

	Buttons[BX].Status = (Buttons[BX].Status == BT_DOWN) ? BT_UP : BT_DOWN;

	printf("Button %d hit, now %d\r\n",BID,Buttons[BX].Status);


The little color indicator button has a slightly different routine to maintain a simple counter stepping through all ten resistor color codes in sequence:

void CountColor(byte BID) {

byte i,BX;
static byte Count = 0;

	if (!BID) {											// not a valid ID
		printf("** Zero button ID\r\n");

	BX = FindButtonIndex(BID);
	if (BX == NumButtons) {								// no button for that ID
		printf("** No entry for ID: %d\r\n",BID);

	Buttons[BX].Status = BT_DOWN;						// this is always pressed

	Count = (Count < 9) ? ++Count : 0;					// bump counter & wrap

//	printf("Indicator %d hit, now %d\r\n",BID,Count);


The indicator “button” doesn’t go up when pressed and its function controls what’s displayed.

I think the button action function should have an additional parameter giving the next Status value, so that it knows what’s going on, thus eliminating the need to pre-push & redraw buttons in HitButton(), which really shouldn’t peer inside the button data.

It needs more work and will definitely change, but this gets things started.


Leave a comment

Kenmore 158 UI: Button Framework Data Structures

The trouble with grafting a fancy LCD on an 8 bit microcontroller like an Arduino is that there’s not enough internal storage for button images and barely enough I/O bandwidth to shuffle bitmap files from the SD card to the display. Nevertheless, that seems to be the least awful way of building a serviceable UI that doesn’t involve drilling holes for actual switches, indicators, and ugly 2×20 character LCD panels.

Rather than hardcoding the graphics into the Arduino program, though, it makes sense to build a slightly more general framework to handle button images and overall UI design, more-or-less independently of the actual program. I haven’t been able to find anything that does what I need, without doing a whole lot more, sooooo here’s a quick-and-dirty button framework.

Calling it a framework might be overstating the case: it’s just a data structure and some functions. It really should be a separate library, but …

After considerable discussion with the user community, the first UI can control just three functions:

  • Needle stop position: up, down, don’t care
  • Operating mode: follow pedal position, triggered single-step, normal run
  • Speed: slow, fast, ultra-fast

That boils down into a simple nine-button display, plus a tiny tenth button (in brown that looks red) at the top right:

Kenmore 158 UI buttons - first pass

Kenmore 158 UI buttons – first pass

The viciously skeuomorphic button shading should show the button status. For example, in the leftmost column:

  • The two upper button are “up”, with light glinting from upward-bulging domes
  • The lower button is “down”, with light glinting from its pushed-in dome

Frankly, that works poorly for me and the entire user community. The whole point of this framework is to let me re-skin the UI without re-hacking the underlying code; the buttons aren’t the limiting factor right now.


The three buttons in each column are mutually exclusive radio buttons, but singleton checkbox buttons for firmware switches / modes would also be helpful, so there’s motivation to be a bit more general.

A struct defines each button:

enum bstatus_t {BT_DISABLED,BT_UP,BT_DOWN};

typedef void (*pBtnFn)(byte BID);		// button action function called when hit

struct button_t {
	byte ID;					// button identifier, 0 unused
	byte Group;					// radio button group, 0 for none
	byte Status;				// button status
	word ulX,ulY;				// origin: upper left
	word szX,szY;				// button image size
	pBtnFn pAction;				// button function
	char NameStem[9];			// button BMP file name - stem only

The ID uniquely identifies each button in the rest of the code. That should be an enum, but for now I’m using an unsigned integer.

The Group integer will be zero for singleton buttons and a unique nonzero value for each radio button group. Only one button in each Group can be pressed at a time.

The Status indicates whether the button can be pushed and, if so, whether it’s up or down. Right now, the framework doesn’t handle disabled buttons at all.

The next four entries define the button’s position and size.

The pAction entry contains a pointer to the function that handles the button’s operation. It gets invoked whenever the touch screen registers a hit over the button, with an ID parameter identifying the button so you can use a single function for the entire group. I think it’ll eventually get another parameter indicating the desired Status, but it’s still early.

The NameStem string holds the first part of the file name on the SD card. The framework prefixes the stem with a default directory (“/UserIntf/”), suffixes it with the Status value (an ASCII digit ‘0’ through ‘9’), tacks on the extension (“.bmp”), and comes up with the complete file name.

An array of those structs defines the entire display:

struct button_t Buttons[] = {
	{ 1,	0, BT_UP,	  0,0,		 80,80,	DefaultAction,	"NdUp"},
	{ 2,	0, BT_UP,	  0,80,		 80,80,	DefaultAction,	"NdAny"},
	{ 3,	0, BT_DOWN,	  0,160,	 80,80,	DefaultAction,	"NdDn"},

	{ 4,	2, BT_DOWN,	 80,0,		120,80,	DefaultAction,	"PdRun"},
	{ 5,	2, BT_UP,	 80,80,		120,80,	DefaultAction,	"PdOne"},
	{ 6,	2, BT_UP,	 80,160,	120,80,	DefaultAction,	"PdFol"},

	{ 7,	3, BT_UP,	200,0,		 80,80,	DefaultAction,	"SpMax"},
	{ 8,	3, BT_DOWN,	200,80,		 80,80,	DefaultAction,	"SpMed"},
	{ 9,	3, BT_UP,	200,160,	 80,80,	DefaultAction,	"SpLow"},

	{10,	0, BT_UP,	311,0,		  8,8,	CountColor,		"Res"}

byte NumButtons = sizeof(Buttons) / sizeof(struct button_t);

Those values produce the screen shown in the picture. The first three buttons should be members of radio button group 1, but they’re singletons here to let me test that path.

Contrary to what you see, the button ID values need not be in ascending order, consecutive, or even continuous. The IDs identify a specific button, so as long as they’re a unique number in the range 1 through 255, that’s good enough. Yes, I faced down a brutal wrong-variable error and then fixed a picket-fence error.

The file name stems each refer to groups of BMP files on the SD card. For example, NdUp (“Needle stop up”) corresponds to the three files NdUp0.bmp, NdUp1.bmp, and NdUp2.bmp, with contents corresponding to the bstatus_t enumeration.

The constant elements of that array should come from a configuration file on the SD card: wrap a checksum around it, stuff it in EEPROM, and then verify it on subsequent runs. A corresponding array in RAM should contain only the Status values, with the array index extracted from the EEPROM data. That would yank a huge block of constants out of the all-too-crowded RAM address space and, even better, prevents problems from overwritten values; a trashed function pointer causes no end of debugging fun.

A more complex UI would have several such arrays, each describing a separate panel of buttons. There’s no provision for that right now.

Next: functions to make it march…