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 349625 - Problems with highlighting
Problems with highlighting
Status: RESOLVED WONTFIX
Product: tomboy
Classification: Applications
Component: General
unspecified
Other Linux
: Normal normal
: 1.4.0
Assigned To: Tomboy Maintainers
Tomboy Maintainers
sandy[affects-ui]
Depends on:
Blocks:
 
 
Reported: 2006-08-02 06:32 UTC by Shaun McCance
Modified: 2014-05-25 02:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Shaun McCance 2006-08-02 06:32:16 UTC
Highlighting is posing two semi-related problems:

In the text editing menu of a note, the actions you can perform are nicely formatted to sort of show what they do.  That's cute.  But when you hover over the menu item, you can't actually read the menu item text, because the background colors stays, but the foreground color does whatever GTK+ does.

On a similar note, the highlight color seems to be hard-coded or something.  If you use Tomboy with an inverse theme, you'll get white text on a bright yellow background, because Tomboy only sets the background color, not the text color.  That's generally an accessibility no-no.
Comment 1 Alex Graveley 2006-08-02 07:00:25 UTC
Regarding the hardcoded color: because GTK+ symbolic colors do not yet specify a highlight color, there is really not much we can do outside of specifying a GConf key to set the color which I doubt is very useful to anyone.

Comment 2 Shaun McCance 2006-08-02 16:19:09 UTC
There are things you can do.  Yelp uses various colors throughout its DocBook rendering, and all of them are computed from the theme.

http://cvs.gnome.org/viewcvs/yelp/src/yelp-settings.c?rev=1.18&view=markup

I'm not entirely happy with all the colors (but hey, I'm color-blind, you can't expect much), but the colors are at least all readable in any theme.

You could, for example, pick a hue and saturation, then construct the highlight color with a brightness that is 90% between the text and background colors of the theme.

Alternatively, at the very least, you should set the text color for highlighted text.  Inverse theme users might not get inverse color for highlights, but at least the text won't end up white-on-yellow.

Comment 3 Vincent Untz 2007-09-27 16:15:43 UTC
The color problem is highly visible when you use a dark theme like darklooks (in gnome-themes-extras).
Comment 4 Boyd Timothy 2008-02-26 19:14:57 UTC
Setting the default assignee and QA Contact to "tomboy-maint@gnome.bugs".
Comment 5 Sandy Armstrong 2009-08-27 13:46:28 UTC
Some other theme/color issues are described in bug #584454.
Comment 6 Eemil Lagerspetz 2009-08-30 06:10:38 UTC
Hi,
> Regarding the hardcoded color: because GTK+ symbolic colors do not yet specify
> a highlight color, there is really not much we can do outside of specifying a
> GConf key to set the color which I doubt is very useful to anyone.

All GTK+ themes define a selected items colour. That is used in other applications for highlighting (try to select text in Firefox for example), so why not Tomboy? You should use fg[SELECTED] and bg[SELECTED], or alternatively replace the fg[SELECTED] with text[SELECTED] and or the bg[SELECTED] with base[SELECTED]. On the other hand, if you want to differ from selecting that text, you can do it in the inverse; themes take care that the colors I mentioned contrast with each other, and so you can interchange bg and fg for an inverted "selected" colour scheme.
Comment 7 Eemil Lagerspetz 2009-08-30 06:12:30 UTC
On the other hand, what Firefox does for search highlight, it sets the text color to black and background to yellow. That works even if the previous text color was white.