Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSS classes in themes for nick colors #325

Merged
merged 3 commits into from May 17, 2016
Merged

Conversation

astorije
Copy link
Member

Advantages compared to the current system:

  • Individual colors can be tweaked color by color in the theme if one appears to be problematic (too light, too dark, too close to background color, ...)
  • Each theme can control their colors entirely, not relying on the "system" ones. One can create a monochrome theme, or an accessible theme (with only very contrasted colors)
  • Themes can define a subset of colors by assigning multiple classes to a same color or filtering using CSS selectors
  • Custom CSS can override a class, for example if a user doesn't like their own color
  • Less inline style
  • One less library

Main drawback of course is new themes have to ship between a few colors up to 64 (but that's the whole point 😄). A quick HTML tool to generate classes will be very easy to do in a few lines of code using randomColor package or whatever solution so that theme authors can bootstrap this in no time.

About the colors themselves:

  • Colors for the default style (and therefore for crypto as well) have been generated based on the existing code. It's difficult to tell the difference between master and this PR. However, we have the same issues than current system, meaning some are too bright, etc.
  • Colors for Zenburn and Morning have been built using the randomColor package featured in Generate better nick colors #322
  • I set up the 64-color threshold arbitrarily. We can do more, we can do less, but note that whatever the generator (current code or the randomColor package), I noted a lot of "visual semi-duplicates". My guess is 32 should be enough, but it doesn't really matter.

Screenshots:

Example before Example after Morning before Morning after
screen shot 2016-05-12 at 02 16 07 screen shot 2016-05-12 at 02 16 22 screen shot 2016-05-12 at 02 18 19 screen shot 2016-05-12 at 02 25 32

In situ:

Example Morning
screen shot 2016-05-12 at 02 34 35 screen shot 2016-05-12 at 02 26 53

@astorije astorije added the Type: Feature Tickets that describe a desired feature or PRs that add them to the project. label May 12, 2016

return "color-" + hash % 64;
}
);
Copy link
Member Author

@astorije astorije May 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can definitely be improved with all sorts of crazy hashing. However, considering the end goal, I don't think having a not-perfectly-random solution is not a big deal.

Also, I didn't cache classes as we currently do. I don't think this is going to affect performance though. A fast hashing function (fast over randomness quality) is probably the way to go anyway.

Suggestions welcome :-)

@AlMcKinlay
Copy link
Member

This looks pretty good to me. The only issue is that the dark theme colours are quite similar (it looks like we have maybe 6 or 7 distinct colours). However, I think getting this PR in first and improving the colours over time would be a good plan, because currently it's very hard to see nearly half of the usernames on the dark themes.

@@ -752,6 +752,71 @@ button,
color: #50a656 !important;
}

#chat .user.color-1 { color: #1396cf; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your indexes are off. Either you need to add 1 in colorClass function or re-index classes to be 0-63.

Copy link
Member Author

@astorije astorije May 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops my bad, good catch. Fixed in the colorClass function.

@astorije
Copy link
Member Author

Just out of curiosity, I tried reducing from 64 colors to 32.

Example 64 Example 32 Morning 64 Morning 32
64 32 64_m 32_m

Seeing this, I think 32 colors are enough. Shuffle them and you won't be able to tell which is which :-)
(Also, don't pay attention to your own color, if hashing function changes before merging, the index does as well, plus we'll probably change colors before merging)

@thelounge/maintainers, what do you think? 32 or 64? I'm fine either way, leaning towards 32 though.

@AlMcKinlay
Copy link
Member

I think 32 is probably fine. The colours look much better and less similar, and very rarely are you going to have 32 people chatting for it to be a problem. My vote for 32.

@xPaw
Copy link
Member

xPaw commented May 12, 2016

32 is OK. I looked at HexChat, and they have mere 9.

@astorije Change no-color to color (inverted option) as we discussed, and then this can be merged.

@astorije astorije force-pushed the astorije/color-classes branch 3 times, most recently from c2f63c5 to 62a8417 Compare May 13, 2016 05:05
@xPaw xPaw added this to the ★ Next Release milestone May 13, 2016
These colors were built using the current generation function to have
similar style.
These colors have been generated by the randomColor package
This will reset users' preference regarding colored nicknames but it's to make
it more specific than just "colors".
@astorije
Copy link
Member Author

Alright, I'm all set @xPaw! Let's ship it, I have further unrelated improvements to make but I don't want to do that before it gets merged :-)

@@ -437,7 +437,7 @@ $(function() {
var settings = $("#settings");
var options = $.extend({
desktopNotifications: false,
colors: false,
coloredNicks: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't rename the option, as you break previously stored setting.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for the record:

16:07 +xPaw astorije, looks OK except for the renamed settings, i'll test it today or tomorrow
16:08 +astorije xPaw, what's wrong with the renamed settings§?
16:08 +xPaw backwards compat
16:08 +xPaw I would rather leave renaming settings to Max-P's PR
16:08 +astorije I know it breaks settings, but if we are jumping 2.0.0 I'm not too complexed about it
16:09 +astorije To be honest, I am not too happy having a class that is system specific like that simply called "colors"
16:09 +astorije And leaving the renaming to Max-P's PR means changing 32 * 4 lines
16:09 +xPaw i specifically mean the setting name
16:09 +xPaw class can stay
16:09 +astorije Oh right, my bad
16:09 +astorije Yeah
16:10 +astorije I'd say the earlier the better, especially if we jump 2.x
16:10 +astorije If we end up not doing it (which I doubt more and more), then fine, but otherwise...
16:10 +xPaw eh, fuck it, fine
16:10 +xPaw i'll test it later to make sure nothing broke
16:10 +astorije lol
16:10 +astorije Sure
16:10 +astorije I tested the 4 themes in private browsing fyi

@xPaw
Copy link
Member

xPaw commented May 16, 2016

👍 Looks all fine to me.

The only unrelated thing I noticed is that we use button in user list, and a in chat. Perhaps we should change all the clickable nicknames to be button? Not in this PR obviously.

That would do two things:

  1. Remove hover with url that browsers display.
  2. Link color that comes from #chat a.

@AlMcKinlay
Copy link
Member

Perhaps we should change all the clickable nicknames to be button?

Can't do that, it breaks highlighting on firefox. I thought we changed the userlist to use links, but apparently not.

@xPaw
Copy link
Member

xPaw commented May 16, 2016

Can't do that, it breaks highlighting on firefox.

Hm, what about <span role="button">?

@AlMcKinlay
Copy link
Member

Hm, what about ?

I'll have to test that later. I don't run firefox at work anymore (used to, that's how I found the bugs). Will check sometime.

@astorije
Copy link
Member Author

astorije commented May 16, 2016

What about the original PR, @YaManicKill?
I agree with both of you, it should not be a link, but I made it a dedicated issue to discuss testing and consequences, including in accessibility, see #338.
I'm obviously not planning to add this to the current PR, let's ship it! :)

@AlMcKinlay
Copy link
Member

What about the original PR, @YaManicKill?

This PR? Yeah, I'm happy with it. 👍

I'll merge as this is second review. Good job, @astorije I'm really looking forward to having this in release.

@AlMcKinlay AlMcKinlay merged commit 304314d into master May 17, 2016
@AlMcKinlay AlMcKinlay deleted the astorije/color-classes branch May 17, 2016 07:15
matburnham pushed a commit to matburnham/lounge that referenced this pull request Sep 6, 2017
@AlMcKinlay AlMcKinlay removed their assignment Mar 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Tickets that describe a desired feature or PRs that add them to the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants