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 74695 - gtkcellrenderertext strange background behaviour
gtkcellrenderertext strange background behaviour
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.0.x
Other Linux
: Normal major
: Medium fix
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2002-03-14 19:56 UTC by Andreas J. Guelzow
Modified: 2006-05-26 00:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andreas J. Guelzow 2002-03-14 19:56:08 UTC
Treeview showing several columns of a listsort including a column shown
with the gtkcellrenderertext. The background of the cells may be set to a
certain colour (corresponding to the colour the user has chosen for a
certain tab) as well as the text maybe rendered inanother (hopefully
contrasting) colour similarly chosen by the user. Selection of a row
obscures the background color (and in effect replaces it with a light blue
at least in my case).

There are several problems with this:

If the text colour should be similar to the `selection highlight colour',
the text becomes virtually invisible upon selection.

The background colour is also obscured (which would be okay if that
background colour were solely decorative, but in that case it should not be
set anyways, but it removes an important aspect of the information
presented when the colour is not decorative).


In effect the whole fore/background colour support of the
gtkcellrenderertext becomes pointless in the case of selections.
Comment 1 Jonathan Blandford 2002-03-14 22:07:42 UTC
Color support is sort of dodgy, anwyay.  Theme changes can make the
text totally unreadable.  To really work, App authors need to:

1) listen for theme changes and pick colors that don't clash
2) Control their environment
3) Always set a complementary fg/bg color.

This leads me to think that, for 3, we should have the bg color be
drawn  even when the text is selected.  Previously, you wouldn't know
about the selection, as there was no vertical padding.  Now you'll
generally get a 1 pixel selection border around the cell, in the worst
case (and other cell renderers can affect it too, obviously).  Owen, I
can quickly make this change, but I want to know if it's too big a
change for the 2.0.x series?  Should it wait for 2.2.x?  I already
helped Andreas work around this.  Marking as 'future' until I know
when it should be changed. 
Comment 2 Owen Taylor 2002-10-05 22:17:28 UTC
I'd say definitely skip it for the 2.0.x series. Drawing
the bg color on top of the selection sounds a little dubious
to me, but I'll leave the decision up to you guys on
this. (Is the border guaranteed to be visible for all themes?
Does it get thicker for the large-print themes?)
Comment 3 Jeff Hostetler 2004-06-16 02:30:48 UTC
i think the problem here is that the text cell renderer
draws the background (in either the color from the 
SELECTED state or the color you load) --- but it always
draws the foreground color in the color you loaded.  it
doesn't use the foreground color from the SELECTED state.

in my case, it would be fine for the entire selected row
to "go reverse video" and lose my coloring.
Comment 4 Andreas J. Guelzow 2004-06-16 03:02:03 UTC
Well, have a look in the sheet manage dialog of gnumeric. There the _user_
chooses the colours and it would be nice if the colours would be recognizble
even in the selected state.
Comment 5 Kristian Rietveld 2006-05-26 00:37:08 UTC
I agree with Owen that drawing the bg color on top of a selection is pretty dubious.  Marking WONTFIX.