After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 789137 - Hide cursor on focus out
Hide cursor on focus out
Status: RESOLVED WONTFIX
Product: vte
Classification: Core
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-10-18 09:51 UTC by Egmont Koblinger
Modified: 2018-04-24 21:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proof of Concept (346 bytes, patch)
2017-10-18 13:09 UTC, Egmont Koblinger
accepted-commit_now Details | Review

Description Egmont Koblinger 2017-10-18 09:51:34 UTC
Inspired by https://bugs.launchpad.net/terminator/+bug/1724440

We could add an option to hide the cursor on focus out.

Rationale: That's what pretty much every (non-terminal) graphical app does. The visible cursor is one per desktop, not one per app or one per some widget. For non-focused widgets the cursor position doesn't really matter, it's okay to reveal it only when it gets focused.

Also, it slightly helps locate the focused terminal window in case of i-beam or underline cursor.
Comment 1 Egmont Koblinger 2017-10-18 12:56:28 UTC
Changing the I-beam width can already be achieved with current VTE, e.g.:

~/.config/gtk-3.0/gtk.css

vte-terminal:focus {
    -GtkWidget-cursor-aspect-ratio: 0.15;  /* 2px at my favorite font */
}
vte-terminal {
    -GtkWidget-cursor-aspect-ratio: 0;  /* 1px enforced by vte */
}

Note however that the initial cursor width in newly opened windows is incorrectly the narrow one in about half of the cases in Unity 7; a focus toggle is required to repair it. It works reliably in GNOME Shell. Re-adding the line that was added in bug 727614 and moved elsewhere in bug 787710 does not fix it. Sounds to me either a GTK+ or a Unity 7 bug, perhaps related to bug 788334.
Comment 2 Egmont Koblinger 2017-10-18 13:09:40 UTC
Created attachment 361803 [details] [review]
Proof of Concept

Just a quick proof of concept patch to see if we like this behavior at all.

I'll use this for a while and get back with my experiences.

Obviously it would need to be behind an API or some other kind of config option if we decide to go for it, probably the old behavior remaining the default.
Comment 3 Egmont Koblinger 2017-10-18 13:18:44 UTC
Middle-click paste is one scenario where it's important to see the cursor position in unfocused windows.

It's different in graphical apps (textarea widgets etc.) because there middle-clicking not only gives focus to the app, but also sets the cursor position (where the text is inserted). This latter step cannot be done in terminal emulators.

I personally don't middle-click because my laptop's touchpad has two buttons and I didn't bother setting up some kind of emulation, I'm okay with Shift+Insert or Ctrl+(Shift+)C/V copy-paste. I guess it's the same for many other folks, but by far not for everyone.
Comment 4 Egmont Koblinger 2017-10-26 20:43:11 UTC
Experiences after a week:

The difference is hardly noticeable for me. I never got distracted by the cursor being hidden in unfocused terminals, it never caused any sort of (mental or other) problem. In a few cases it probably slightly helped me not to accidentally type into the wrong window.

If we had such an option, I'd probably enable it. I'll keep using the patch for a while.
Comment 5 Christian Persch 2017-10-27 20:03:19 UTC
Comment on attachment 361803 [details] [review]
Proof of Concept

Let's try this, master only. We can always later add API to select between this and outline cursor.
Comment 6 Egmont Koblinger 2017-10-27 23:17:32 UTC
Well, not sure if we should force this on everyone... even if we do, the outline cursor should be #if 0'd.
Comment 7 Egmont Koblinger 2017-12-04 20:20:21 UTC
The lack of the cursor is also annoying if there's an unfocused window where you're watching new output being produced.

Probably I'd be the only one using this feature, and even I'm not super convinced. Unless you object, I'd close as wontfix.
Comment 8 Christian Persch 2017-12-04 21:41:27 UTC
No objections.
Comment 9 Egmont Koblinger 2018-04-24 21:48:20 UTC
Another case where this is terribly confusing: When it takes a lot of time for a utility to start producing output, you cannot tell for sure whether you've launched that command, or just prepared the command line but haven't pressed Enter.