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

Non-colored nicknames should be disabled and colors should be theme-specific #45

Closed
astorije opened this issue Feb 15, 2016 · 8 comments
Labels
Type: Feature Tickets that describe a desired feature or PRs that add them to the project.

Comments

@astorije
Copy link
Member

FYI, I haven't looked to see how colors for the colored nicknames are handled.

However, in terms of UX, it's very noisy and insignificant to have a checkbox to enable colored nicknames.

This checkbox should be removed, enabling colored nicknames by default. Then, colors should be set in the CSS file (if it's not already the case) so that a theme can decide they want to disable colored nicknames by setting the same color for the whole range.
This also allows theme creators to have full control over the nickname colors (again, if it's not already the case).

@astorije astorije added the Type: Feature Tickets that describe a desired feature or PRs that add them to the project. label Feb 15, 2016
@xPaw
Copy link
Member

xPaw commented Feb 15, 2016

This checkbox should be removed, enabling colored nicknames by default.

Strongly disagree. I don't like colored nicknames in any client, and wouldn't want to modify the theme to change it.

Then, colors should be set in the CSS file (if it's not already the case)

It's not the case, it sets colors using inline attributes.

@ghost
Copy link

ghost commented Feb 15, 2016

If we want to set the colors in the CSS, how many different colors do we want to introduce? Right now I don't think there's a limit since they're randomly generated based on the username. But adding 256 color classes to a css file is a bit overkill I guess. Could we settle somewhere around 30?

@easymac
Copy link
Contributor

easymac commented Feb 19, 2016

Regarding CSS colors:

It's a slightly less-than-trivial decision to make here as there is no real standard for IRC colors.

We're already enumerating the 16 mIRC colors in style.css. As far as I can tell, most clients only support these 16 colors. However, HexChat supports 32 colors. Assuming this Shout issue made it to Lounge, we're probably mapping the additional 16 colors down to our original 16.

I propose that we take advantage of this existing color pallet for nickname colors as well. I've implemented this locally, and I'm very happy with the result. I would much rather have theme-defined nickname colors than any random nickname colors as the chosen pallet is very much part of the theme's appearance.

@xPaw raised the concern on IRC that this might not be enough colors; perhaps to that end we could lean into the 32-color pallet that HexChat defines and not only support more colors in chat but have 32 options for nicknames.

@AlMcKinlay
Copy link
Member

So, this should be partially fixed by #325.

We need to agree on whether we remove the non-colour setting to close out this ticket.

I suggest we do not remove the setting, but we default to colours. Anyone in an objection to that? I don't think we want to remove the config to disable colours.

@AlMcKinlay AlMcKinlay added the help wanted Tickets the community can help us with, by either answering questions or sending us PRs. label May 27, 2016
@AlMcKinlay
Copy link
Member

Assuming that it is just changing the default option for coloured nicknames, that's very easy so I've added the up for grabs label.

@xPaw
Copy link
Member

xPaw commented May 27, 2016

Removing the setting is not a good idea, imo. Default option was already changed to be on by default.

@AlMcKinlay AlMcKinlay removed the help wanted Tickets the community can help us with, by either answering questions or sending us PRs. label May 27, 2016
@AlMcKinlay
Copy link
Member

Ah right. In that case, I'm going to close the issue. If someone wants us to remove the option and has a good reason for it, they can reopen and discuss, but I am strongly against us removing that option.

@astorije
Copy link
Member Author

Opened this almost 4 months ago, and since then I'm not strongly for removing this setting. Now that it's enabled by default and themes can control both their color palette and the nick-colors-disabled color, it seems fine to me.
We might have tabs in the settings at some point (see #85), and this + selecting your theme could be bundled there.

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

No branches or pull requests

4 participants