Make branch colors stable #70

Closed
FredrikNoren opened this Issue Aug 20, 2013 · 13 comments

Comments

Projects
None yet
4 participants
@FredrikNoren
Owner

FredrikNoren commented Aug 20, 2013

No description provided.

@gausie

This comment has been minimized.

Show comment Hide comment
@gausie

gausie Aug 21, 2013

I've got an npm package (string-hash-colour) that will do this. Will fix and submit a PR as soon as I can get a development copy running (issue #97)

gausie commented Aug 21, 2013

I've got an npm package (string-hash-colour) that will do this. Will fix and submit a PR as soon as I can get a development copy running (issue #97)

@slang800

This comment has been minimized.

Show comment Hide comment
@slang800

slang800 Aug 21, 2013

Contributor

That's a very interesting solution @gausie. However, just hashing the string to get a color provides no filter to how the color may look with the site. For example, the resulting color might end up being very close to the background, or the color of another branch.

Contributor

slang800 commented Aug 21, 2013

That's a very interesting solution @gausie. However, just hashing the string to get a color provides no filter to how the color may look with the site. For example, the resulting color might end up being very close to the background, or the color of another branch.

@gausie

This comment has been minimized.

Show comment Hide comment
@gausie

gausie Aug 21, 2013

I think the current random colour generator doesn't account for this as well, certainly GitGraphViewModel.randomColor doesn't.

gausie commented Aug 21, 2013

I think the current random colour generator doesn't account for this as well, certainly GitGraphViewModel.randomColor doesn't.

@slang800

This comment has been minimized.

Show comment Hide comment
@slang800

slang800 Aug 21, 2013

Contributor

Yeah, you're right, that doesn't either. Though just because the current solution is inadequate doesn't mean its replacement should contain the same inadequacy.

Contributor

slang800 commented Aug 21, 2013

Yeah, you're right, that doesn't either. Though just because the current solution is inadequate doesn't mean its replacement should contain the same inadequacy.

@gausie

This comment has been minimized.

Show comment Hide comment
@gausie

gausie Aug 21, 2013

Right, but it also doesn't mean the replacement is bad. I'll try to implement avoiding being close to the background, but obviously my proposal is better than what we have now.

gausie commented Aug 21, 2013

Right, but it also doesn't mean the replacement is bad. I'll try to implement avoiding being close to the background, but obviously my proposal is better than what we have now.

@slang800

This comment has been minimized.

Show comment Hide comment
@slang800

slang800 Aug 21, 2013

Contributor

Yes, of course it's not bad... it's actually quite clever. I just think that we should try placing constraints on the colors by modifying the hashing mechanism... or perhaps making some way that insures all branches are as far from each other and the background as possible... like by doing something like this:

make a list of all the branches that we're showing, sort them by name, assign colors starting at an arbitrary point on the color wheel for the first color, and then for each subsequent color shift the hue by (2 * PI) / number_of_branches... or something like that

Contributor

slang800 commented Aug 21, 2013

Yes, of course it's not bad... it's actually quite clever. I just think that we should try placing constraints on the colors by modifying the hashing mechanism... or perhaps making some way that insures all branches are as far from each other and the background as possible... like by doing something like this:

make a list of all the branches that we're showing, sort them by name, assign colors starting at an arbitrary point on the color wheel for the first color, and then for each subsequent color shift the hue by (2 * PI) / number_of_branches... or something like that

@gausie

This comment has been minimized.

Show comment Hide comment
@gausie

gausie Aug 21, 2013

Have a look at the new update to the module... it's not perfect but it works.

gausie commented Aug 21, 2013

Have a look at the new update to the module... it's not perfect but it works.

@slang800

This comment has been minimized.

Show comment Hide comment
@slang800

slang800 Aug 21, 2013

Contributor

hmm... that could work. it feels a bit more complicated than the way I pointed out, but eh - whatever

Contributor

slang800 commented Aug 21, 2013

hmm... that could work. it feels a bit more complicated than the way I pointed out, but eh - whatever

@eric-wieser

This comment has been minimized.

Show comment Hide comment
@eric-wieser

eric-wieser Aug 22, 2013

hue = (branch_number / golden_ratio) % 1, defining 0 <= hue < 1, is a nice way to append branches to a list and pick a new unique color for them without overlapping with previous colors or having to recolor existing branches.

http://martin.ankerl.com/2009/12/09/how-to-create-random-colors-programmatically/

hue = (branch_number / golden_ratio) % 1, defining 0 <= hue < 1, is a nice way to append branches to a list and pick a new unique color for them without overlapping with previous colors or having to recolor existing branches.

http://martin.ankerl.com/2009/12/09/how-to-create-random-colors-programmatically/

@slang800

This comment has been minimized.

Show comment Hide comment
@slang800

slang800 Aug 22, 2013

Contributor

thanks for the post @eric-wieser ... maybe we can use this: https://github.com/sterlingwes/RandomColor

Contributor

slang800 commented Aug 22, 2013

thanks for the post @eric-wieser ... maybe we can use this: https://github.com/sterlingwes/RandomColor

@gausie

This comment has been minimized.

Show comment Hide comment
@gausie

gausie Aug 24, 2013

None of these are repeatable for branch name though. The colour needs to be able to be extracted from some unchanging property of the branch each time.

gausie commented Aug 24, 2013

None of these are repeatable for branch name though. The colour needs to be able to be extracted from some unchanging property of the branch each time.

@slang800

This comment has been minimized.

Show comment Hide comment
@slang800

slang800 Aug 24, 2013

Contributor

I don't think it needs to never change... Just to usually not change.

For example, we could use RandomColor and then just store the colors it generates in the local storage of the browser... Meaning it wouldn't change until the local storage is cleared out.

Contributor

slang800 commented Aug 24, 2013

I don't think it needs to never change... Just to usually not change.

For example, we could use RandomColor and then just store the colors it generates in the local storage of the browser... Meaning it wouldn't change until the local storage is cleared out.

@eric-wieser

This comment has been minimized.

Show comment Hide comment
@eric-wieser

eric-wieser Aug 28, 2013

@FredrikNoren: What's to stop that generating a black node? While it makes sense to extract the "random" information from a hash, you probably want to work harder than taking it plain. At a simple level, force the components of the the color to average to (say) 256

@FredrikNoren: What's to stop that generating a black node? While it makes sense to extract the "random" information from a hash, you probably want to work harder than taking it plain. At a simple level, force the components of the the color to average to (say) 256

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment