org.gnome.desktop.interface.cursor-blink-timeout not honored

Bug #1798481 reported by Steve Stevenson on 2018-10-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone
vte2.91 (Ubuntu)
xfconf (Ubuntu)

Bug Description

Xubuntu desktop 18.04.1

$ lsb_release -rd
Description: Ubuntu 18.04.1 LTS
Release: 18.04

gnome-terminal: 3.28.2-1ubuntu1~18.04.1
libgtk-3-0: 3.22.30-1ubuntu1
dconf-editor: 3.28.0-1

Per workaround instructions in comment #8 on bug 838381 (of which this is not a duplicate), I set /org/gnome/desktop/interface/cursor-blink-timeout to a large value, less than the stated maximum of 2^31 - 1.
I saved the change, exited dconf-editor and restarted the computer.

What I expected to happen:
Cursor in GTK-based terminal emulators will no longer stop blinking after 10 seconds.

What happens instead:
Cursor in GTK-based terminal emulators continues to stop blinking after 10 seconds.

Of note, the cursor-blink-time *is* honored.

Those are VTE based terminal emulators, so I suggest that you forward this issue to the GNOME developers.

Egmont Koblinger (egmont-gmail) wrote :

VTE does have code in place to support these variables and they work for me. No need for reboot, not even to restart gnome-terminal, it should pick up the change immediately.

It stops blinking the cursor when the focus is lost, and restarts blinking it when the terminal is focused again. Are you sure this is not what confused you?

What are the exact values of your cursor-blink related values in dconf?

Could you please download VTE tarball (or git), and try the test app with debug options, like:
  tar xf vte-0.54.1.tar.xz
  cd vte-0.54.1
  ./configure --enable-debug
  VTE_DEBUG=misc ./src/app/vte-2.91

Does it print a line beginning with "Cursor blinking settings"? How does it look like?

If you modify the dconf settings, does such a line appear again?


#2 Thanks for the comment. I'm accustomed to blinking following focus. The values I have in dconf are:
cursor-blink: true
cursor-blink-time: 1200
cursor-blink-timeout: 10000

I built vte 0.54.1 and ran the test app with debugging messages on as you described. There is a line referring to "Cursor blinking settings" which appears during launch:

Cursor blinking settings: blink=1 time=463 timeout=10

No new debug messages appear when I adjust cursor-blink settings in the dconf editor and save them. Relaunching the vte test app after saving new cursor-blink settings in the dconf editor does not change the "Cursor blinking settings" line at all, unfortunately.

I had adjusted the cursor-blink-time yesterday to something shorter to verify that THAT setting was being honored, and at the time it was - and presently that shorter blink time is reflected in the vte test app, gnome-terminal, xfce4-terminal, gedit and the pidgin instant messenger input pane.

Do gedit and pidgin have some relationship with vte? (I'm not very familiar with the GNOME ecosystem.)

I changed cursor-blink-time to 1205 and rebooted my system to see if that made any difference and the vte test app still reports "time=463" and all those GTK apps still have the cursor blinking fast. So it seems yesterday I at least had the capacity to affect a change to how fast the cursor blinks but now I've lost that capability. I'm not sure where to look next. Thanks!

Egmont Koblinger (egmont-gmail) wrote :

> cursor-blink-time: 1200
> cursor-blink-timeout: 10000
> time=463 timeout=10

Oops, time should also match and it doesn't.

Can you confirm that blinking is pretty fast for you, that is, the duration of an entire cycle (on + off phases) is a bit less than half a second (463 ms, rather than 1.2 seconds)?

As seen at, VTE refers to the widget settings' "gtk-cursor-blink" and friends properties, which are somehow mapped to gsetting's /org/gnome/desktop/interface/cursor-blink and friends – or well, in your case, mapped probably somewhere else.

It'd take help from a GTK+ expert or investigating GTK+'s source to check this mapping, to figure out where it takes these values from if not from gsettings's /org/gnome/desktop/interface/, and how that can be configured.

What desktop system do you have? Maybe if let's say you use Mate then these values might come from /org/mate/... or so, I'm wondering.

Could you do a "dconf dump /" and look for 463 in its output, to have a clue where this number comes from, assuming that it comes from dconf at all. And see if changing that value takes effect in VTE.

> Do gedit and pidgin have some relationship with vte?

They all use GTK+ and perhaps even some higher level GNOME libraries. Other than, not much. Gedit also has a VTE plugin but that's most likely irrelevant, and Pidgin doesn't have such.

The blink time does seem to be a bit less than a half second. If I count the seconds out loud it blinks twice each second with a little time to spare.

"dconf dump /" doesn't yield any instances of 463, but does show 1205 for cursor-blink-time (so it's in harmony with the dconf-editor GUI), and that's the only instance of 1205.

I'm running Xubuntu 18.04, using xfce as my desktop environment.

Poking around in dconf-editor, there's an org/xfce section but it only contains data for mousepad, the default plain text editor. There an org/gtk section, but it doesn't have anything related to cursors. There's an org/mate/desktop/interface section, which has cursor-blink, cursor-blink-time but not cursor-blink-timeout. I changed the value of mate's cursor blink time to 1,195 but vte still says it's 463. (And all the GTK apps still have the cursor blinking at that speed.)

I wonder if I should grep for 463 on every file in the system... (but then I suppose the value is just as likely to be obfuscated in some binary file as it is to be plain text). Thanks for your help.

I grepped for 463 against everything in my home directory and this was at the top of the list:
    <property name="CursorBlinkTime" type="int" value="463"/>

(Apparently I'm also not very familiar with the xfce ecosystem.)

It seems there is some mechanism by which changes to properties in dconf propagate to xfconf, but this mechanism seems to be less than 100% robust.

I quickly found "Settings Editor" (the GUI for xfconf). Within the xsettings "channel" there exist the following properties:


Changes to CursorBlinkTime were effective immediately in GTK interfaces upon saving the value in xfconf ("Settings Editor").

There's no /Net/CursorBlinkTimeout. I tried creating an integer property by that name and setting a value of 20, but it did not have an effect.

There exist several /Gtk/... properties in the xsettings channel, including /Gtk/CursorThemeName
and /Gtk/CursorThemeSize. Nothing about blinking.

As a shot in the dark, I tried creating /Gtk/CursorBlinkTimeout as an integer property with value 20 and it was effective immediately, with the new value being reflected in the vte debug output the instant it's changed in xfconf.

I suppose the bug should be a request for enhancement to include in the xfce Keyboard settings GUI an affordance for setting the value of /Gtk/CursorBlinkTimeout, so that this setting is discoverable. (The Keyboard settings dialog has "Show blinking" checkbox and "Blink delay" slider which set the values of /Net/CursorBlink and /Net/CursorBlinkTime respectively.)

Thanks for the guidance.

Or perhaps such an addition wouldn't be appropriate because it only applies to GTK applications and the xfce team would only want to include such a control if it were universal? In any case, I'll try to bring this to the attention of the xfce maintainers (and add answers to, etc).

no longer affects: gnome-terminal (Ubuntu)
no longer affects: xfce4-terminal (Ubuntu)

It seems the symptom is specific to xfce, where the values in xfconf seem to control the relevant behavior. The cursor blinking timeout for GTK applications can be controlled by adding a new integer key "/Gtk/CursorBlinkTimeout" to the "xsettings" channel.

Egmont Koblinger (egmont-gmail) wrote :

Thanks for the investigation!

In the mean time I've tried xfce, icewm and windowmaker – /org/gnome/desktop/interface/cursor-blink* weren't used by VTE in any of them, some hardcoded defaults were used. I guess some dconf or gsettings daemon needs to be running to have the required binding in place (not sure).

Steve, did you contact the Xfce developers?

I really don't have much experience reporting bugs with large open projects. I tried asking in what I thought was the correct venue but didn't get a response. As long as people who were in my situation can discover the solution via finding this report or the answer I posted to the related question on then I'm satisfied and I don't mind this report being closed ("invalid" I guess, not sure what statuses are available). I'd close it myself but I can't find an affordance for doing that.

Your suggestion in comment #8 looks like something that is worth to forward to the Xfce bug tracker (Xfce Core -> Xfce4-settings).

The new key could be added to the xsettings.xml, and maybe even be exposed in the keyboard settings dialog too.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers