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
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
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.
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
xterm. On the surface, this version of
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
borderColoras 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
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
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
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
xterm users like me; distribution ones, not so much.