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 85821 - Preference for changing cursor color
Preference for changing cursor color
Product: gnome-terminal
Classification: Core
Component: general
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
: 69776 148378 695011 (view as bug list)
Depends on: 695011
Reported: 2002-06-18 22:03 UTC by Mathias Hasselmann (IRC: tbf)
Modified: 2016-02-13 20:21 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

the monster patch (224.95 KB, patch)
2002-06-18 22:05 UTC, Mathias Hasselmann (IRC: tbf)
none Details | Review
the custom-palette-popup (91.32 KB, image/png)
2002-06-18 22:08 UTC, Mathias Hasselmann (IRC: tbf)
more than 32 settings (67.11 KB, patch)
2002-10-22 03:01 UTC, dengen
committed Details | Review
colorized text cursor (17.74 KB, patch)
2002-10-22 03:03 UTC, dengen
needs-work Details | Review
vte support for colorized text cursor (6.66 KB, patch)
2002-10-22 03:04 UTC, dengen
none Details | Review
Follow the "cursor-color" style property (1.22 KB, patch)
2007-01-26 06:09 UTC, Mariano Suárez-Alvarez
needs-work Details | Review
git-format-patch output for implementation of cursor colour profile options (6.99 KB, application/x-compressed-tar)
2016-02-11 17:05 UTC, Tony Houghton

Description Mathias Hasselmann (IRC: tbf) 2002-06-18 22:03:07 UTC
Hi Havoc,
heres another patch for GNOME2.0.x

Originally I just wanted to add code for a custom color popup (see the
screenshot). Since I initially thought I would have to store some of the
popup values in gconf I came to the terminals quite unmaintainable property
code, saw it fixed it to use a struct of bitfields, put common task into
preprocessor macros. Since the are alot of prefs the patch became quite
big: cvs diff got serious problems to diff out the new terminal_profile_update.

Well... Later it pointed out that it would be stupid to store some values
of the popup in gconf, those values are aproximated online by reading the
colorpots now. Since I'm too lazy to separate both patches (popup and
prefscleanup) right now I'm sending you the combined patch, tell me if I
shall separate them.

Hope that I and "cvs diff" didn't broke something.
Comment 1 Mathias Hasselmann (IRC: tbf) 2002-06-18 22:05:03 UTC
Created attachment 9305 [details] [review]
the monster patch
Comment 2 Mathias Hasselmann (IRC: tbf) 2002-06-18 22:08:01 UTC
Created attachment 9306 [details]
the custom-palette-popup
Comment 3 Havoc Pennington 2002-06-18 23:09:28 UTC
I like the general direction of the settings cleanup, thanks for doing
that - it looks like a lot of work!

I'm not sure I understand what happens if I click the "initialize
custom palette" popup though - it seems like it may be a useful idea
to avoid doing the custom palette by hand, though.

There are various small changes I'd make to the cleanup; e.g. I have a
thing where I only use while loops, I put a space around : in "foo:1",
and I'd really prefer it if macros allowed a semicolon at the end so
that Emacs indentation worked. etc.

I would like to handle these two patches separately; presumably the
cleanup comes first, then the color popup. My feeling is that I'd like
to think through the color UI a bit better; one suggestion that's been
made is that we have one idea of schema/palette (one option menu) that
includes both background/foreground and the full palette, since the 
full palette really assumes either a light or a dark

Both patches need to be on the 2.1.x branch instead of the 2.0.1
branch, and the 2.1.x branch doesn't exist yet; I'll probably create
it after we've done the UI review bugs for 2.0.1. I forget the bug
number for that but it's one of the newest gnome-terminal bugs if you
run a query.
Comment 4 Luis Villa 2002-06-25 20:01:53 UTC
bug 85655, FWIW, is the ui-review bug.
Comment 5 Havoc Pennington 2002-09-22 20:10:07 UTC
This would be nice to mop up a bit for 2.2
Comment 6 dengen 2002-10-22 02:59:35 UTC
I've broken out Mathias's monster patch into just the allowing more
settings part since I also want to add another setting. The diff is
against GNOME_TERMINAL_2_0_1. One thing I changed with the original
patch is that in a couple of places emit_changed was being called with
a pointer to a stack local variable as the signal data which didn't
seem like a good idea to me, so I made the setting mask class private.
Someone with more gtk know how should determine if this is the right
way to do it.

The other patch allows the user to set the text cursor color. It also
requires a patch to vte.
Comment 7 dengen 2002-10-22 03:01:19 UTC
Created attachment 11746 [details] [review]
more than 32 settings
Comment 8 dengen 2002-10-22 03:03:11 UTC
Created attachment 11747 [details] [review]
colorized text cursor
Comment 9 dengen 2002-10-22 03:04:09 UTC
Created attachment 11748 [details] [review]
vte support for colorized text cursor
Comment 10 Nalin Dahyabhai 2002-10-22 16:36:20 UTC
What's the rationale for overriding the text cursor color?  The
current behavior is to draw the cell(s) in with the foreground and
background colors reversed, which seems more correct to me.
Comment 11 dengen 2002-10-22 22:15:24 UTC
The rationale is that it's easier to find with the eye especially if
you've turned off cursor blink and have inverse text on your terminal.
Lets say you're in an editor marking a block of text (which is shown
by inverse), when the cursor is at the edge of the block, you can't
tell which is the cursor and which is the block.

You are right that the foreground color should be reversed. This helps
when the cursor color is the same as the text color. The *fore = *back
line should be taken out of the vte patch to get the same (desirable)
behaviour as xterm with a color cursor.
Comment 12 Havoc Pennington 2002-12-08 05:06:10 UTC
I applied the patch for allowing more prefs, before it bitrotted.
Thanks for that.

The cursor color thing can't go in for 2.2 as I missed the freeze;
for reviewing this, it would be helpful to have a comprehensive
"rework the palette stuff" proposal including the changes Nalin wanted
to make, 
and a plan for what that tab of the profile editor dialog ends up 
looking like.
Comment 13 Calum Benson 2002-12-13 18:42:09 UTC
I don't use vte so I'm unfamiliar with its features... but I hope the
inverse video/custom text cursors are just an option :)  To be
accessible the cursor needs to be drawn in the gtk-specified cursor
colour by default.
Comment 14 Christian Rose 2003-08-05 18:31:10 UTC
Is this still valid?
Comment 15 Mariano Suárez-Alvarez 2004-02-14 06:13:47 UTC
Probably. It has become a multi headed RFE...

The “more than 32 settings” patch has been applied and Nalin added
cursor color support to vte, so the patch for that is not longer
necessary. That leaves the patch to add the cursor color and the one
to initialize the custom palette...
Comment 16 Luis Villa 2004-04-28 13:13:34 UTC
Comment on attachment 11748 [details] [review]
vte support for colorized text cursor

per mariano's comment.
Comment 17 Guilherme de Siqueira Pastore 2006-01-12 13:11:17 UTC
Updated summary to reflect what this has actually become.
Comment 18 Guilherme de Siqueira Pastore 2006-01-27 10:41:20 UTC
Wonder why this had the string keyword...
Comment 19 Mariano Suárez-Alvarez 2007-01-26 06:09:49 UTC
Created attachment 81253 [details] [review]
Follow the "cursor-color" style property

With this patch on vte, VteTerminal follows the cursor-color style property set on the style, so that

   style "test" { VteTerminal::cursor-color = "red" }
    class "GtkWidget" style "test"

in your ~/.gtkrc-2.0 file will get you red cursors.

According to Calum, this should be the default, right?

If we want to provide user-colorizable cursors, we need UI like the one proposed in a patch in bug 69776, but vte would also need to provide a vte_terminal_set_follow_the_gtk_cursor_color to toggle this...
Comment 20 Mariano Suárez-Alvarez 2007-01-26 06:13:18 UTC
*** Bug 69776 has been marked as a duplicate of this bug. ***
Comment 21 Mariano Suárez-Alvarez 2007-01-26 06:14:16 UTC
Bug 69776 has a nice screen shot for a proposed UI for this on g-t's side.
Comment 22 Behdad Esfahbod 2007-01-26 06:37:22 UTC
Can't we just make it follow Gtk+'s cursor color unconditionally?
Comment 23 Mariano Suárez-Alvarez 2007-01-26 23:28:57 UTC
The patch is way too naive. We have to deal with vte_terminal_set_color_cursor somehow. 

While we are at it, vte_terminal_set_color_highlight should use the style's GTK_STATE_SELECTED to do highlighting, and take the background color from the style, too. And deal with their vte_terminal_set_* functions, too.
Comment 24 Chris Wilson 2007-01-27 00:32:37 UTC
*** Bug 148378 has been marked as a duplicate of this bug. ***
Comment 25 illvilja 2009-08-21 16:24:51 UTC
Any progress on this?  Right now one might use multiple profiles all having different color schemes for background and foreground color as a way of differentiating between different hosts.  Very useful, especially when every session is associated with a modified Gnome Terminal icon which indicates the color scheme in question.  That way, I can, subconsciously select the right session when doing alt-tab.

Adding the ability to also customize the cursor color for different profiles would make it possible to keep track of even more different hosts, and yes, I would find it very useful.

(Compiled and started latest stable gnome-terminal, version 2.26.3, but there were no support for custom cursor color there.  To my disappointment, the ability to specify a custom icon for each profile had ALSO disappeared... Hm... but that last issue is not the topic of this particular bug so I'll leave it for now)
Comment 26 Armin Jarmusch 2011-10-23 23:46:57 UTC
we still don't have a way to alter the cursor color here, and it should be part of the profile preferences in gnome-terminal. there should also be some intelligence to not layer a bright cursor color over a bright character (i.e. inverting the text color if it's necessary, to increase contrast for readability). color selection should be possible via a color picker popup.

- armin
Comment 27 Tony Houghton 2016-01-07 16:36:38 UTC
(In reply to Armin Jarmusch from comment #26)
> there should also be some
> intelligence to not layer a bright cursor color over a bright character
> (i.e. inverting the text color if it's necessary, to increase contrast for
> readability).

Bug #695011 covers that problem, so it should be marked as a dependency of this one. It also proposes adding support for the cursor foreground colour to g-t's UI so the two bugs could also be merged, but as g-t still doesn't have a cursor (background) colour option I think they're slightly separate issues.
Comment 28 Tony Houghton 2016-02-11 16:12:29 UTC
*** Bug 695011 has been marked as a duplicate of this bug. ***
Comment 29 Tony Houghton 2016-02-11 16:22:15 UTC
I've implemented this and raised a pull request on github <>.
Comment 30 Christian Persch 2016-02-11 16:44:51 UTC
Thanks! Could you please attach the patch series here (either with git-bz, or just as output from git format-patch) so I can git-am it? (We don't use github pull requests.)
Comment 31 Tony Houghton 2016-02-11 17:05:03 UTC
Created attachment 320897 [details]
git-format-patch output for implementation of cursor colour profile options

I wasn't sure how to package these files for attachment, I hope a tarball is OK.
Comment 32 Christian Persch 2016-02-13 19:25:52 UTC
Thanks for the patches!

I've split the non-UI changes out and committed that for 3-20.
Comment 33 Christian Persch 2016-02-13 20:21:47 UTC
I had to change the .UI file anyway since it was totally broken with newer gtk+, so I've implemented the UI in a different way.