Wandering Thoughts archives

Moving to Fedora 29 has not been one of the smooth upgrades for me

A lot of the time, moving to a new Fedora version is a smooth process for me, where everything basically works the same as the previous version but the software versions are more recent and up to date. Sometimes there are new tweaks that I have to make or changes that I have to adapt to; for example, when I went from Fedora 25 to Fedora 26 I wound up with font rendering issues and eventually decided to switch to standard Fedora font rendering and fonts. Based on my lack of notes about them, my updates to Fedora 27 and Fedora 28 seem to have been smooth. As you may guess from me writing this entry, my move to Fedora 29 has not been so smooth.

The obvious and fixable issue that I had was the xterm border issue, which I don't consider to be a big deal; I saw it right away, it can be worked around, and in the end it cures itself (if you, for example, build your own RPM of the latest upstream xterm, which is what I did). More significant and mysterious are two additional issues I've had in my X environment.

First, something about X keyboard event handling appears to have changed in a subtle way. I have a long-standing FVWM mouse binding where the middle mouse button plus Alt will move the window the mouse is over, and I often use this binding to move Firefox windows. In Firefox, tapping Alt by itself activates the menu bar at the top of the window. In Fedora 28 and previous versions, I could move Firefox windows with my middle mouse plus Alt binding without having the menu bar appear after the move finished; in Fedora 29, the menu bar always pops up after the move finishes.

(According to xev, in Fedora 29 this sequence generates Alt_L or Alt_R KeyRelease events when the move finishes. If I release Alt before the mouse button, it's a synthetic event, otherwise not. Unfortunately I don't have a Fedora 28 system any more to try this on; I upgraded my home machine before I understood what was happening on my work machine. Since I use a hand-built version of FVWM, it's the same window manager binary in both versions but all sorts of other X related things have changed package versions.)

Second, a couple of GTK-based programs I use have an issue where the 'tooltip' pop-ups I normally get when I hover the mouse over things don't always stay visible but instead sometimes flicker madly between being up and being down. For instance, in my Liferea these popups appear if I hover the mouse over an article headline that's truncated (the popup shows me the full headline). In the current version of Corebird that I use, these popups normally appear when I hover over URLs in tweets.

(Unfortunately I don't know if this happens in other GTK-based programs, because Liferea and Corebird are the only two that I actually use. I can run gnome-terminal, but I don't know if it has any UI component with this hover tooltip feature, and anyway this doesn't fail all of the time, just some of it.)

Unfortunately both of these problems seem completely mysterious to me at the moment; I have no idea what could cause them or where to look to figure out why they're happening. The GTK tooltip issue certainly seems like a bug somewhere, but it could be in how these programs are using the GTK API instead of in GTK itself. The X event handling might not be considered a bug, and it might be a change in the X server, the overall event handling chain, or in GTK (which Firefox uses for a number of things on Unix).

Overall it seems unlikely that I'll be able to cure either issue any time soon, which means that Fedora 29 is going to continue to have real points of friction and irritation for me that just weren't there in Fedora 28. This makes me grumpy and irritated, as does the fact that there's basically nothing I can do about any of this (partly because of the amount of software involved and its overall complexity).

Working around an irritating recent XTerm change in behavior

Suppose, not hypothetically, that you have just performed an operating system upgrade that upgraded the version of xterm. On the surface, this version of xterm looks just like the old one; for example, your default xterm looks like this, which is normal and how it used to.

However, you also have 'root xterms' for your su sessions, with a red foreground to make them stand out as special (cf). When you call one of these up for the first time, it looks like this.

That obtrusive, ugly black border doesn't belong there, and it didn't used to be there in older versions of xterm (and this is not a window manager decoration; xterm draws it itself, inside any window manager framing). This border appears because of a change in xterm patch #334:

• color the inner border using the same borderColor as the outer border, rather than filling with the VT100's default background.

What this innocent sounding change appears to do is colour this inner border in your default foreground colour, whatever that is (black, in my case, since my default xterm colours are black on white), unless you are using entirely default colours. The moment you set any or all of foreground, background, or cursor colour, you get the border drawn in. In xterm patch #334 (which is the version in Fedora 29), the only way to avoid this is to explicitly set the border colour to your background colour, whatever that is for any particular xterm.

(The border colour may be set with either the borderColor X resource or the -bd command line argument. Which one you use depends on how you're changing the other colours; for my sins, I have a mixture, so I get to make changes all over.)

In xterm patch #335, this behavior was effectively reversed (as far as I can tell), although the patch notes will not tell you that. Instead you need to consult the xterm manpage, which now says that by default xterm is back to filling the inner border with the background color and you can set the colorInnerBorder resource to change that. Of course, the default xterm resources that your Unix ships may be altered to change this; if they are, you will need to change things back to restore the old default behavior.

The good news is that patch #335 came out only a few days after patch #334. The bad news is that xterm #334 made it into at least one Unix (specifically, Fedora 29). Hopefully your Unix will skip past #334, and also hopefully it won't pick a version of xterm that has other surprises.

As a look at the xterm changelog will show you, xterm undergoes a lot more change than you might expect in such an old and venerable program (certainly more change than I expect, at least). Some of these changes are fixes for bugs and issues, and some of them are useful improvements, but every so often there are things like this change that make me less than happy.

(There was the xterm patch #301 change to $SHELL handling in 2015, for example, which was later recognized as flawed and augmented with the validShells X resource in xterm patch #334. Yes, the same patch that added this new behavior. The irony is thick.)

PS: It is worth looking at the XTerm default X resources file that your Unix provides along with its xterm, because historically various packagers and distributors have been unable to keep their hands off it. The upstream XTerm default resources have been quite stable over the years, a stability that's appreciated by long-term xterm users like me; distribution ones, not so much.