add option to randomize new tag colors

[evogelsa]

Hello! This PR is mostly a draft of an idea, so open to suggestions or contributions for how to improve this.

I like to have colorful tags to create visual distinction on my timeline, but I don't really care to set colors myself, and manually randomizing the color each time is somewhat annoying since I commonly make new tags. This PR adds an option to the user settings for how to determine the default tag color. The options I added are:

• Default - use the current "brand yellow" color
• From Tag Name - I noticed some old code for this, so it could maybe be brought back here, but I don't think it's currently functional as is
• Random - Randomly generate a color

This seemed mostly functional when I tested it, but there's definitely some room for improvement. A couple notes:

• Random currently feels a little jarring because it will change the preview color of the tag as you type the name
• Making the color options into an enum might be a little nicer than passing around raw strings
• The from tag name setting didn't seem to work, and I didn't really try to make it work. Not sure if it's even something worth keeping around or not.

[almarklein]

Sorry for getting back to this after so long.

Generating the color from the name was an early idea to give unique (pseudo) random colors to tags, without actually needing to store the color. I think we can re-use that idea here?

Right now, when using "random colors", the color changes every time a tag is shown, so it should look like a dico or something? 😅

What if the default tag color can be "from name" or "yellow"?

[evogelsa]

Sorry for getting back to this after so long.

No worries 🙂

Generating the color from the name was an early idea to give unique (pseudo) random colors to tags, without actually needing to store the color. I think we can re-use that idea here?

I see, makes sense. I don't know if there's a way to keep the from tag name option without have the "disco" colors since changing the tag name would then have to change the color. Maybe the tag color could be generated when the dialog closes, but IMO I'd prefer to see the color in the dialog even if it's changing as you type.

Right now, when using "random colors", the color changes every time a tag is shown, so it should look like a dico or something? 😅

Yeah, agreed that was definitely the most jarring part of this. I've updated the "random" option in the most recent commit to generate the next color once when you open the dialog, and use that for any new tag created in that dialog. It's not perfect since creating multiple tags in the same dialog will result in them all having the same color, but I think it's still an improvement from always having new tags be yellow.

What if the default tag color can be "from name" or "yellow"?

Hopefully I understood this correctly, but I updated the selection options in the settings dialog to be "Yellow", "From Name", and "Random".

Yellow = current brand yellow default
From Name = use the tag name to generate the color
Random = Use a randomly generated color

Let me know what you think! I'd love to get this integrated if you like the changes.

[evogelsa]

Oh, and I also added a small bug fix to the random color generation. I noticed it would generate colors with a leading zero, e.g. #0abcde. However, leading zeros were being dropped from the color string, and this caused them to not display correctly. I added a zero pad if necessary to ensure this would not happen.

[almarklein]

So if I know create a new tag, and have it set to random colors, in what cases will it change color?

• Does it change color every time the app is rendered?
• Does it change color every time the app is reloaded?

[almarklein]

Oh, and I also added a small bug fix to the random color generation

Nice! 🙏

[evogelsa]

So if I know create a new tag, and have it set to random colors, in what cases will it change color?

It should only get a new color when the tag is created. It's using the same mechanism as clicking "random" from the edit tag dialog to generate the color, and the color is saved to the tag store like a custom color. Reloading the app should not affect the existing tag colors.

[evogelsa]

@almarklein friendly poke🙂

Do you have any other feedback for this PR or could it be merged?

[almarklein]

I think there's still a few problems with this PR, like using the settings to set next_random_color, which is not what settings are for, and also fails when creating multiple new tags. Plus it generates and stores new colors for all tags previously created. And when the user dislikes it and sets it back to the default, the colors stay the random version.

All of these problems can be solved by using the color by name feature. So two options for the default color: Yellow, or byname. You can still call it random in the form and use the from-name implementation.

[evogelsa]

Ah okay, I see the point you were trying to make earlier now regarding the color by name. Thanks for the feedback!

when the user dislikes it and sets it back to the default, the colors stay the random version.

What are the steps to reproduce this? When I tested the pressing the "default" button in the tag color dialog, it still used the default yellow color iirc.

All of these problems can be solved by using the color by name feature.

I'm not sure if I entirely agree with this statement however. I think using the color by name will still end up with the "disco" colors while typing out a new tag, unless the tag color is not generated until after the dialog is closed. I think a better option may be to still generate random colors, and store those in color generator class rather than the settings. To fix the issue of new tags sharing the same random color, the random color can just be popped each use to cause the next one to be new.

[almarklein]

What are the steps to reproduce this?

• Change the setting to use random colors.
• Create a new record with a new tag, it will be a ramdom color
• Change the setting back to use yellow
• The new tag will still be the random color that was assigned when created.

This is not too bad in itself. But the thing is that a tag is assigned as soon as it encountered. So let's say that we accept the PR as it is now. What happens for all users is this:

• By default the setting is yellow, so every tag that the application is showing will be assigned yellow in the first moments that the new version is loaded. This happens to every tag for which get_color_for_tag() is called. So for all tags that are displayed at some point.
• Now the user changes the setting to 'random'.
• The tags that were visible stay yellow. New tags become random.
• But now the user scrolls back to last week, these tags were not shown yet, and they will turn to random colors.
• Now the user sets back the setting to use 'yellow' colors.
• Indeed new tags will be yellow. But the tags from last week are still random.

Basically, the fact that tag colors are assigned based on whether they are shown or not is very unpredictable and will be annoying.

Using the color-by-name fixes this, because it does not need to store the color. I agree that the tag changing color as you type it looks a bit funny, but IMO that's a small price to pay.

[evogelsa]

Gotcha, yeah I was able to reproduce this now with your latest comment. I agree past tags changing color is not the intent, and would be confusing.

The new tag will still be the random color that was assigned when created.

This part however was intentional, so I'd like to keep that behavior, and using the from name option is a creative way to solve that issue. I did not realize that currently the default color is not being saved to the DB with each new tag, and that definitely limits the available options. I'll update this PR in a bit with those changes. Thanks for taking a look.

[almarklein]

The new tag will still be the random color that was assigned when created.

This part however was intentional, so I'd like to keep that behavior,

Well, the way I see it, tags can have a default color, or a user-overridden one, that they set in the dialog and then gets stored in the settings. In my view, all new tags start as unset, and should stay unset until the user explicitly overrides the color.

The new setting you introduce here, toggles how colors that don't have a user-set color should be colored. Toggling the setting should apply to all tags that have no set color, and should not affect what users have a set color in the settings.

[evogelsa]

In my view, all new tags start as unset, and should stay unset until the user explicitly overrides the color.

That's a fair view to have, but from my POV as a user, this setting serves the purpose to change how new tags have their initial color set. The specifics of how the database works like whether or not the initial color is actually stored, or how the initial color is generated should be hidden from me. Having the color of existing tags change under me when I switch a setting that in my mind only affects how new tags are created, would be strange to me.

The issue I was attempting to solve was that I prefer visual distinction between each tag I use. A default color of yellow for every tag does not provide that distinction, and manually randomizing the color of each tag is a tedious process. So in other words, an option to set a new random color for each tag is precisely the feature I want. If in the future I decide I want to return to a monotone color palette for new tags, I don't think that previously created tags should have their color changed from under me.

However as you brought up, the current way the default color is implemented unfortunately limits the options since it must be assumed there is not an existing color in the database for each tag already. I also don't love using the from name color generation since the disco effect when typing new tags out just feels unrefined. I do plan to revisit this soon and get the feature working in a way that solves my problem but also works for the project as a whole, but for now I'm just using a forked version until I have time to polish it more.

[almarklein]

from my POV as a user, this setting serves the purpose to change how new tags have their initial color set. [...] I don't think that previously created tags should have their color changed from under me.

Thanks for your explanation. I see what you mean. The complication here (and I think the source of confusion/disagreement 😃) is that tags are not created explicitly, but just happen to exist as they appear in a description. This is by design.

So in order for this option to work as "how the color of a new tag is determined", the record dialog should examine each tag in the description, determine if its new (i.e. no such tags exist yet) and if it is, assign a new color in the settings. Determining whether a tag is not used yet is possible, but does not "fit in well" and may also inhibit later refactoring. Which is why I am hesitant to the idea.

If we think of the option as "how tags are colored by default (having no user-set color)" then things fit a lot better in the system.

since the disco effect when typing new tags out just feels unrefined.

Maybe a delay can help? Colorize the tags e.g. 2s after the user stops typing?

I do plan to revisit this soon and get the feature working in a way that solves my problem but also works for the project as a whole, but for now I'm just using a forked version until I have time to polish it more.

👍 Thanks for your work so far!