Tags' background color should be the tag's color

Reported by fonji on 2009-03-09
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Getting Things GNOME!
Wishlist
Unassigned

Bug Description

When you choose a color for a tag, the yellow-background color should be the tag color.
Open windows have to be refreshed when you set the color.
Users may use white but that's not a problem, it's a feature ;)

Lionel Dricot (ploum) wrote :

Bertrand, what do you think ? It might be a good idea, indeed. It should also be the case in the tag drop-down menu IMHO.

Yes, I think that's true. It would be better to strongly associate colors and tags.

Changed in gtg:
status: New → Confirmed
Lionel Dricot (ploum) on 2009-03-10
Changed in gtg:
importance: Undecided → Wishlist
Lionel Dricot (ploum) wrote :

and what about tags without color then ?

Changed in gtg:
milestone: none → 0.3
fonji (fonji) wrote :

Well, I see two options. At least right now.

First, there's a default background, which is not the tag's color. This may come from a constant (current yellow), some option or some color from gnome theme (I don't know anything about gnome themes so I have no idea if there's something like that available).
But this becomes a little weird if the user wants to use the default color as the tag's color.

Second, default color is white. But this is weirder because you don't have a feedback that the tagging has been done, unless there's a font change (bolder?) or some kind of border (or something like that) when the cursor is around a tag.

What do you guys think? Any other idea?

Paul Kishimoto (khaeru) wrote :

I like fonji's idea: use a border/outline, underline, or boldface for tags with no colour set. Boldface is probably best, since there is no way (and shouldn't be) to set task text bold otherwise.

Lionel Dricot (ploum) wrote :

Paul > I agree that bold is an idea but maybe less effective to find tags in a task.

Why do you say that there should not be a way to set text bold ? You can do it in Tomboy, for example.

Paul Kishimoto (khaeru) wrote :

Ah, that's a good point—I usually keep my tags at the top, and I don't have much text in my task descriptions. Perhaps outline is better then, if that is possible.

Regarding rich text—on one hand, I know rich text task descriptions will someday be identified as a helpful feature. On the other hand, time that a user spends fiddling with formatting is time *not* spent actually achieving those tasks. I know I have this problem with Gnote/Tomboy...I format/tidy notes to procrastinate real work.

I don't mean that GTG should be aggressively minimalist. Maybe someone can write a rich text plugin at some point and it will be so popular it gets included in the main application. For the forseeable future, though, if users want to keep a lot of nicely formatted text related to a note, the Tomboy plugin is a better option.

Bryce Harrington (bryce) on 2010-01-30
summary: - Tags' backround color should be the tag's color
+ Tags' background color should be the tag's color
Paul Kishimoto (khaeru) wrote :

Sure enough: bug #511938.

Jeff Oliver (jeffrey-oliver) wrote :

I figured I could whip up a patch that would draw a border around the tag text in the editor view, at a minimum to see what it would look like. This patch doesn't consider someone modifying the text for the tag, so the drawing gets messed up until the next expose event. In other words, this patch still needs work, but I figure it didn't hurt post it in case anyone else wanted to see what tags looked liked with a border.

Luca Invernizzi (invernizzi) wrote :

I like it. Jeff. It helps to better identify that as a tag.
You should open another bug for this though.

Jeff Oliver (jeffrey-oliver) wrote :

It was here due to the earlier comment on what should be done if the tag color matches the background color, or if the tag has no color associated to it. I guess the question is whether or not it would be preferable to always draw a border around the tags regardless of the color, or only in certain situations. If the former, then ok, a new bug could be opened.

Jeff Oliver (jeffrey-oliver) wrote :

I related my development branch to this bug, since i've been playing around with changing the colors of the tags. The branch currently draws a border around the tag's text and it changes the color of the tag from the standard yellow to the color selected for the tag.

Does anyone know an algorithm to determine if the background color is to dark for black text? If the tag is too dark, it'd be nice to switch to white text. Or should the color be faded like the background of a task with that color in the task browser?

Luca Invernizzi (invernizzi) wrote :

IMHO,I like faded better, as strong colors could seems a bit messy when there are a lot of tags.

Paul Kishimoto (khaeru) wrote :

@Jeff: the Python standard library is a treasure trove of neat stuff. For example, searching for "color" brought up http://docs.python.org/library/colorsys.html. There are also lots of cool diagrams at http://en.wikipedia.org/wiki/HSL_and_HSV.

One approach would be to identify a minimum difference in saturation (S) and either value or lightness (V/L); or some combination thereof. Convert the foreground text colour and the tag colour to HS{V/L} and compute the difference. If it's not big enough, adjust S and V/L while keeping H constant. Then convert back to RGB and use for the tag background.

colorsys seems to give S=0 for black, but treating that as S=1.0 might be more useful.

Also, I think this is what you've already suggested, but the border around the tag text should always be the unaltered tag colour.

First, I was not convinced by the interest of this feature. But after some tests, I think that it is really cool. However, as you said, it is important to change the color of the text if the background color is strong.

One more thing, you should probably change the name of your branch to something that have more meaning (for ex tag-bg-color).

Jeff Oliver (jeffrey-oliver) wrote :

Turns out someone already had a helper function in GTG.tools to deal with converting the tag color to a suitable color to display in the TaskTreeView. I just used that exact same function to colorize the tags within the taskeditor. I would think that it would be sufficient in helping distinguishing tags within the editor.

I updated the branch with this change, which has the new name of tag-bg-color as suggested by Alexandre.

Paul Kishimoto (khaeru) wrote :

I added code to change the colour of the outline.

Luca Invernizzi (invernizzi) wrote :

Nice! That really gives consistency to the whole "tag color" thing.

Being a picky guy, I noticed a couple of bugs.
1- when I assign a color to a tag, it is applied to the tag outline instantly(well, on the task editor focus), while I need to close and reopen the task editor to see the background change. We may want to add a "tag-changed" signal for that (don't do it now, a huge refactoring by Lionel is about to land in trunk).
2- tag outlines overlap when tags are on consecutive lines (screenshot attached).

Forgive me, your work is really nice :-D

This looks really good. Besides some cosmetic changes, that's exactly the kind of feature I wanted to see land in gtg someday. Thank you so much for implementing it!

As for updates, yes, I guess that we should create some "tag-modified" signal someday. It will probably be needed to make tags work in the in-progress refactoring.

Bryce Harrington (bryce) wrote :

Is there any further work needed before this can be landed in trunk?

Jeff Oliver (jeffrey-oliver) wrote :

I think the background coloring of the tags is a fairly simple change to the code. There's probably a patch that can be cherry picked for that...the only problem with changing the background color is for the lighter colors or no colors, its tough to know where the tags are. Hence the "draw the border" change. I like the border around the text, however, my patch/tree has problems with drawing the border when the text moves. For instance, as soon as you have enough text to have a scrollbar on the editor, the border drawing doesn't work right anymore.

Lionel Dricot (ploum) wrote :

Is there any reason why this patch hasn't been merged yet ? Did anybody tried it ? Which of the two linked branch should be used ?

Lionel Dricot (ploum) on 2011-08-06
Changed in gtg:
milestone: 0.3 → 0.4
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers