Forums Feature Suggestions More colors PLEASE!

I'd do it a bit differently. I know mIRC supports colours from 0 to 99 already; it just repeats every 16 colours. I don't see why 20 through 83 can't be used for a 6-bit colour palette, with 16 of them being the original 0 through 15. However, those 64 colours should be locally customizable.

See: EGA Colours

There would be a lot of duplication / wasted indexes if you just appended the EGA palette on top of mIRC's. That seems like a poor use of the precious index values.

Since when? Nothing from ^K16 to ^K99 generates any colors for me. For me, ^K16 to ^K99 act like ^O but without also undoing bold/italics/reverse/underline. They all "undo" color, resetting a line back to its default color.


Heaven forfend. Let's please not unearth that relic. It's little more than a set of 4 variations of the original CGA/EGA text mode color palette.

If there is going to be an extension of the IRC color code system, it should either be:

* Direct RGB, and to balance excessive color control code lengths against color granularity, it should probably be a 4096 color RGB system using a brand new color ^control code + "000" through "FFF" [+ "," + "000" through FFF"]). This would limit each code's length to 8 characters maximum (4 when background color isn't also given) while otherwise still offering extremely fine-grained color selection (for a text medium, anyway).

Or:

* A carefully designed, non-customizable, 82 color palette compatible with the existing ^K system (by using values 16-98, saving 99 for transparency). I say non-customizable because one of the main complaints people have with ^K00-^K15 is that nobody can ever be sure which colors they will produce in other users' clients. If the IRC color code system is to be extended, the new color range should not be allowed to inherit that problem. To compensate for the inability to customize it, it should simply be carefully designed: so as to be "chromatically unbiased," with every possible primary, secondary, and tertiary color represented, and each one in multiple luminosities. Doing that would actually eliminate most desire to customize, since with such careful palette color selection, people will already be able to find very close matches for whatever hues they actually desire.

Personally, I prefer the second option. And the reasons are the disadvantages of the first option. Direct RGB most definitely will require a new ^control code followed by up to 7 characters, for up to 8 characters total. Unlike the recent addition of ^I for italics, where old clients only see one strange character per use, the sight of ^?XXX,XXX will cause much more offense to those using older clients, especially in cases of multiple invocations (think colorful channel topics). People will take sides, bots will be scripted to auto-/kick, ad nausea. Also, IRC daemons with color code-stripping and color message blocking channel modes will require updates to handle stripping and blocking of the new ^?XXX,XXX format RGB codes.

Comparatively, isn't it true that most (if not all?) existing IRC clients treat ^K16-^K99 the way mIRC does (by treating ^K16-^K99 as "go back to line's default color")? If so, the ^K16-^K98 palette method would not heap plagues of control code gibberish upon users of older clients. (The worst ^K16-^K98 would do is cause older client users to see no color where color should exist. King Legibility, though, would be preserved.) Also, most IRC daemons with color stripping (or color message blocking) channel modes either look only for ^K, or simply parse for and strip "^K##,##". So the ^K16-^K98 palette method would require no updates in most of their cases.

On that note, I put this together. Please note: while I can pass tests like this one with flying colors (pun intended), I do not own a professional, ISF calibrated monitor. As such, the palette color values you see in the image below should be treated as extremely "alpha" -- requiring fine-tuning by someone with both excellent color sensitivity and a big, expensive, accurate display device. Nevertheless, even in its "alpha" state, this palette still nicely illustrates the effectiveness of the design goal stated above (offering multiple luminosities of all the primary, secondary, and tertiary colors). Done that way, it's very hard to argue that even more colors could be necessary for a text medium.

The problem is that whatever new colour indexes are added have to be customizable. This is one of the most important requests in each colour discussion. Users want local use colour palette that they can modify to fit their schemes. There is not nearly enough granularity in your proposed palette to back off from customizable palettes, and therein lies the rub.

IF mIRC adds colour codes, they need to be private use. In other words, they should not be meant for sending data over servers. Frankly, I think we have enough colours in 0-15 to represent "colours" on IRC-- what we need is colours 16-98 that can be reserved for local client usage. That way, mIRC would not use 0-15 for echoing local data and instead use codes 16-31 (or fewer) to represent the various event types.

For instance, $color(info) would be mapped to 17 instead of 2, $color(ctcp) would map to 19 instead of 4, etc.-- this would allow every event type to have its own colour code, rather than multiple events sharing a single colour (like join/part/kick/modes). It would also let users change the event colours without affecting colours coming from users, since the indexes are separate. And being local only, it will have no effect on the existing control code support in other clients, since nobody else will be seeing codes above ^K16.

Of course, we could meet in the middle here and reserve a smaller set of values for "local use" while still extending the "remote colours" range to ~64 or so. 32 local colours should be sufficient for a client side scheme, although it does cut it a bit close (there are 20 event types in Alt+K, which would mean about 20 separate local use colours would be reserved for these events under my proposal, leaving only 12 for custom script usage).

Alright, I understand your thinking and can say that I mostly agree. One exception however: if mIRC ever does introduce private use colors, they absolutely should not use the ^K#[#],#[#] format. That would automatically harm future efforts to expand the over-the-wire IRC color palette, which would undoubtedly seek to use any or all of ^K's presently-free values. No client should hog a public resource to itself, even partially.

That being said, as long as a private use system wasn't limited to the boundaries imposed by the ^K#[#],#[#] format, it could be a true RGB system: perhaps using a format like ^K#FFFFFF (where # is literally the # symbol).

Ideally, both ideas could be implemented simultaneously. I still think the 16-98 palette idea I proposed above has merit in two ways: because (IMHO) 16 colors aren't enough, and mainly, because a non-customizable palette would at long last bring color consistency to IRC: knowledge that the colors you were sending out were being seen as you sent them.

(A thought: because the palette design I propose is still very granular -- multiple luminosities of all primary, secondary, and tertiary colors, it would also be possible to create a CTRL-SHIFT-copy function if both systems were simultaneously implemented. CTRL-SHIFT-copy would scoop up all ^K codes verbatim (as CTRL-copy does now). CTRL-copy however would be changed to assume you intend to paste what you've copied back into the channel/query window, and would replace every local ^K#FFFFFF code encountered with the ^K#[#],#[#] color having the nearest-matching hue. This would solve the problem of "how would CTRL-copy deal with local colors?".)

I suppose this is possible, but it would introduce backward compatibility issues. How wide-spread those issues would be remains to be seen, it would be up to Khaled to figure out if it's worth the effort or not. I personally don't mind a palette system, and, in fact, I think it's better than hardcoding colours, especially because one of the benefits of a palette is that it's tied to user settings, not the script itself. In other words, if a user wants to apply a different theme to their local colours, mIRC could theoretically reapply the new colour scheme to an existing window by redrawing it with the updated palette-- which would not be possible if colours were hardcoded by scripts. For that reason, I disagree with this on "best practice" rationale, not for technical reasons. We would be moving in the wrong direction if mIRC encouraged users to hardcode colour values in /echo and the like. Think about what would happen if a script hardcoded some shade of blue because the exact variant wasn't in the palette, rather than defining a special index for it. Then, if a user wanted to change their background to a similar shade of blue, things would get messy really fast. Hardcoding things always reduces customizability and resiliency to change. We want to avoid that as much as possible, and indexes are the best way to do it.

That said, I don't think we disagree about the need for a standard colour system for remote messages. This is exactly why I suggested we reserve only the indexes ABOVE 15 for local use. Users would no longer be able to redefine 0-15 (or whatever the remote usage palette size is), which would solve the "standardized colour scheme" problem, but would still allow scripts to have an abstraction for colour schemes that are not hardcoded to specific colours, which is important for scripts to coexist with user settings (and other scripts), as mentioned above.

Finally, the copy paste idea might work, but again, because I disagree with the benefit of rgb colour codes, I don't really see the value. Also, adding in another key combination for copying doesn't really sound very user friendly, especially given that your suggestion CHANGES behaviour that users have relied on for 10+ years. If anything, Ctrl+Shift+Copy should be the local copy, which would preserve backward compatibility and not be surprising to users who upgrade. This is important since the users who use colours are more often the less technically inclined, and if you changed the behaviour and started throwing invalid colour codes into their copied text, we would start seeing messy invalid codes creep into public messages. Presumably, mIRC could auto-convert ^K#NNNNNN codes when sending outgoing messages too, but now we're adding extra layers of complexity into the program simply to solve the unnecessary complexity we just added.

Sigh. Serves me right for thinking aloud in a state of sleep deprivation. Yes, let's amend my previous post:

First, pretend that I never proposed an RGB FFFFFF format for local color specification. As you said, and for the reasons you said, hardcoded color values would be bad. (You even said this the first time -- "whatever new colour indexes are added have to be customizable" -- but my mind discarded it.)

Second, let's also pretend I never suggested the idea of ^K + "#" as the literal prefix for signalling a local color sequence. ^K + "#" already exists as a "valid" sequence over-the-wire (^K + anything != 0-9 == already interpreted by IRC clients as "transparency".)

Had I been wide awake, I probably would have suggested something more akin to:

• ^K#[#][,#[#]] = the extended public palette
  
  • with 0-15 continuing to behave as they do now, for 100% legacy compatibility (re-definable by client authors/users);
    
  • with 16-98 being hardcoded hues from a globally agreed-upon "IRC palette" for over-the-wire consistency;
    
  • and with 99 continuing to be what it is now (transparency).
    
• ^?#[#][,#[#]] = new local palette whose control sequences are never sent over IRC, nor even between clients via things like DCC chat (0-99 being locally re-definable palette entries)

As for which control character would be best for local colors (?), that's a tough one. Any character not already in use on IRC would be a candidate, but using any of them would still constitute robbing a public resource for private use. Perhaps, then, the correct choice would be a character already disallowed by the IRC protocol. Does it disallow ASCII #0? If #0 is disallowed on IRC, and if #0 wouldn't also pose an internal challenge to mIRC (on account of it being a C creature), and if #0 also wouldn't be a problem for any of the text editing Windows APIs mIRC uses, then #0 would work wonderfully -- Khaled could just map a local key combination to spew it (perhaps CTRL-SHIFT-K).

Regarding the CTRL-SHIFT-copy idea:


That's what I said. CTRL-SHIFT-copy would be a verbatim copy, copying all control codes verbatim and changing nothing. CTRL-copy would also copy control codes, but would convert each private control sequence it encountered to the 16-98 public control sequence whose hue was the nearest match to the private sequence being converted. I had the same "don't change expectations" idea. "Don't change the expectation that any codes picked up by CTRL-copy will be compatible with sending over-the-wire." If CTRL-copy performed nearest-match local -> public code conversion, that expectation would not be disrupted.

However, now that I think of it, mIRC would already need something buried deep within its I/O routines to at least strip local color control sequences from outgoing messages (assuming users attempted to send them from an editbox or via /msg type commands in scripts). So, as long as it would be inserting a stripper, it could just as easily insert a converter at that same level instead. In which case having CTRL-SHIFT-copy in addition to CTRL-copy would be pointless; CTRL-copy could just stay as it is, a non-converting verbatim copier.

/me hopes he got everything right this time

$chr(0) definitely does not work with the way mIRC handles C strings. You can only get \0 inside of bvars, so that severely limits its use. I highly doubt you'll ever see this change. Way too many moving parts in mIRC rely on C strings right now, and changing all of them at once would result in HUGE amounts of new potential security issues. This is absolutely not worth it.

I still disagree with your proposal of using only 0-15 for legacy compat. Specifically, again, because what we need is more LOCAL indexes, not over the wire colours. At the end of the day, I don't think Guest18542 cares whether Jane158 thinks the "Royal Blue" is a smidgen too dark for her liking. Local colours are the issue, I think... and as I pointed out, there are already 20 local events that could benefit from having their own separate index, which is already more than the allocated space, and that doesn't even count any user defined colour codes. User defined colour codes being the most important part here.

You're also not going to get an "agreement" on 80 more colour codes from other IRC clients at this point in time, so that makes it harder to implement this over the wire stuff. Local changes can be made much more easily.

As for your comments about Ctrl+Shift+C, I think I might have been reading it the other way around the first time, thinking you would copy remote codes and translate them for local use. I see your point now. The problem is, many users already hit Ctrl+Shift+C because they aren't entirely sure whether the combo is Ctrl+C or Ctrl+Shift+C. Both work right now, so this change might be surprising to *those* users.

I think an IO routine would be more appropriate though, and would be needed anyway, since those codes could leak out no matter what. For example, a script could accidentally or even intentionally send ^K<localuse> codes if that data is being shared for both local and remote usage -- see my example to Riamus a couple posts back regarding storing of user input variables.

Agreed, it wouldn't be worth it.


There is an excellent and compelling reason not to change the nature of 0-15. Even while 0-15 are re-definable, they tend to default to the same colors in most clients (because their origins are the EGA/VGA text mode color palette). So while different clients might not use exactly the same RGB value for ^K04, ^04 usually tends to be bright red; and while different clients might not use exactly the same RGB value for ^K02, ^K02 usually tends to be dark blue; etc. (In the opposite sense, there are also groups (channels) where everyone communally employs the same alternate RGB definitions for 0-15.)

Considering both those factors, any new "standard" that either (a) suddenly standardized 0-15 by prohibiting their re-definition, or (b) gave license to haphazardly re-defining 0-15 for local use, would upset and further complicate this balance for users of older clients. IMHO, 0-15 is simply a sleeping dog best left lying. It is widely understood to imply "public and usually standard, but re-definable," and that understanding is entrenched and shouldn't be meddled with.


I can imagine that argument having been made by the designers of 16-color video cards to the ones advocating 64-color video cards. (And if Guest18542 didn't value greater color variety, Guest18543 would.)

Besides, that comparison misrepresents my intent: I didn't join this discussion to advocate extreme public color granularity. I only chimed in to give support to the idea of releasing IRC from its legacy public 16 text mode color prison. (In any sense that I did propose granularity, it was while I was still thinking that there was no point to having private colors at all; so I included the notion of granularity in the proposed public scheme just for the benefit of its local uses. As long as there would be a private color range, however, then I still propose expanding the public range. And on that note, there's a difference between proposing that in the interest of excess, and proposing it in the interest of escaping inadequacy. (Just trying to clarify -- no belligerence or anything intended.))

Anyway. Considering that 0x00 is out of the question, robbing some public resource for private use becomes, I guess, the only option. And because it would be bad to waste an entirely new (non-^K) control character on something that could never be employed over-the-wire, how about this:



Two rows of hardcoded colors were eliminated, reducing the "guaranteed always the same color" range to ^K16 - ^K69. That range still represents every possible primary, secondary, and tertiary color, but now offers 4 instead of 6 luminosity choices for each. Grey has also been reduced to 4 luminosity choices. With ^K70 - ^K98 now freed, a total of 29 palette positions are available for local/private re-definable hues -- which is the 20 you're advocating plus room for 9 more in the future.

Your thoughts? Anyone else's thoughts?


Was there ever an agreement on the first 16? To my knowledge, one influential client author simply introduced them, and the others followed suit for compatibility. Yes, there was a brief chaotic period (due to existing clients, which didn't yet support color, leaving the new color control codes visible). But again, that wouldn't happen this time considering that existing clients hide the control sequences for 16-99.

In any case, I'm not even saying that that approach should be taken again. This time, the idea could be discussed among the influential client authors. And in that case, I don't see a good reason why any of them would be flatly against the mere idea itself of extending the IRC color scheme (unless some were just "against change").

What client authors would be agreeing/disagreeing upon is:

1) Is the current public color scheme outdated and restrictive compared to what most users of color might prefer?
2) Should a new scheme incorporate the old scheme (and its behavior) for legacy compatibility (to prevent possible chaos and confusion)?
3) Is it a known problem that color consistency cannot be guaranteed on IRC (that John's ^K04 isn't always the same color as Jane's ^K04)?
4) Would a new range of ^K## codes whose RGB hues were hardcoded solve that problem?
5) Would the best choices for those ^K## codes' RGB hues be a handful of luminosity iterations of every possible primary, secondary, and tertiary color?
6) Can we mutually agree to deem any remaining ^K## codes "hereafter off limits" (forevermore reserved for local client use only)?

Seems to me like "yes" would be an easy answer to 1-4, and a fairly easy answer to 5-6.


Well, it's pointless to further debate this as long as a deeply-buried I/O routine were present to strip (or convert) local use codes.

But just for the sake of answering you anyway: sucks to be them. Not doing things to blindside people who're accustomed to properly using key combinations is one thing, but holding back on change because it might blindside people who don't RTFM is a bit much. It would be nice not to upset their habits, but since people can misuse things in any number of ways, most new ideas would be relegated to the forbidden bin by adhering to such a principle.


(Edited for typos and other clarifications, including updated inline image URL.)

A long time ago, I drew up a palette for 256 colors that expands on the standard 16 mIRC colors, and I'll just post it here as a possible suggestion. I'd like to see your opinions on it, positive or negative.

It adds in hexadecimal numbers and is numbered from ^K00 to ^KFF, but the original 16 colors remain in their spots, from ^K00 to ^K09 and from ^K10 to ^K15.

It has no duplicates or spaces left over, and has the following types of colors:
* 16 standard mIRC colors
* 216 6*6*6 RGB cube (aka "web-safe" colors)
* 6 tertiary colors of the rainbow
* 6 darker versions of the tertiary colors
* 12 quaternary colors of the rainbow
* 16 shades of gray

The set of colors was made by first inserting the mIRC colors where they would be if represented as decimal, at 0x00 to 0x09 and 0x10 to 0x15.

6*6*6 RGB colors were calculated and inserted at the end of the set, beginning on 0x28. The duplicate colors in the cube were removed, and replaced with 8 other shades of grays not already in the set.

Tertiary hues were inserted at 0x0A to 0x0F, and darker versions of these were inserted at 0x1A to 0x1F. Orange was replaced with the darker version of yellow at 0x0A, because that did not exist in the mIRC colors. Finally, the quaternary hues were inserted in the remaining spaces, at 0x16 to 0x19 and 0x20 to 0x27.



It's nearly fully compatible with the original ctrl+K colors and takes up the same amount of space, assuming you always used two digits for the colors.

However, it has a few disadvantages. It doesn't have any space for private indices (can get rid of the rainbow colors and shades of grey for that), lacks a transparent color, and a 6x6x6 RGB cube is probably not the best for displaying a large and perceptually uniform range of colors.

Normally I'd prefer a full 24-bit color set for IRC, as that's extremely simple to achieve, except that the IRC protocol has an imposed message length, and it would necessitate a new control code for them.

pishposh, I think your idea comes close to what should be done.

We need to keep things simple.

00-15 should be legacy. These numbers are already mentioned in the EGA Color Table.
Ignore the numbering scheme for the sixteen colours in the graphic.

16-63 should be the other 48 colours in the EGA colour table.
There is no need for redundancy in having the first 16 colours twice.

64-75 should be for shades of gray.
Since 000000 (black), 555555 (dark gray), AAAAAA (light gray), and FFFFFF (white) are already included in those 64 colours above, that leaves 12 shades of gray in 4-bit grayscale.
111111 ... 444444, 666666 ... 999999, BBBBBB ... EEEEEE

76-95 should be for local customizable colours.
Of course, some people may use them remotely, but oh well.
I do agree, 20 seems like a good number.

96-98 should be reserved, otherwise more local customizable colours.

99 should be for transparency.

+1 to Doomstars' proposal.

This could be done via how the browsers do it, say ^k#ff8d8t then mIRC could internally interpret the colorcode from that to display the text in that color within other mIRC clients.

Other clients would just simply show #ff8d8t as apposed to the actual color, so it would not break other IRC Clients, unless they standardized the colorcode format across their irc clients.

Well thats my 2 cents anyway.

No-- this would not be backwards compatible. This would break mIRC users as well.



Not properly displaying a colour is the definition of breaking a client. The idea that a client is not "broken" because it falls back to displaying regular text isn't exactly a good argument on a text-based protocol. This was the same argument made by MS Comic Chat, but that only led to the client getting kicked from every channel because nobody else could parse the gibberish coming from those users. It's just not a good experience for other clients.

overall reply:

I think at some point, mirc needs to break away from older clients so it can advance. It did it when breaking away from 16bit OS, it did it with codepages, and it's doing it with other things. Sticking to an antiquated standard just because it's the standard (and nobody cna agree on a new one) halts progress. This same argument was used for Italics and we have that now too. Personally, I think if mirc was the guiding light for colors, everybody else would quickly follow suit due to how popular the clieht has been for the past 20 years.

No, I don't code anything I need to support by millions and millions of users, but if I did, I would have the same approach, "In the future, here's how things will work. You have the choice of either upgrading (if you can), or staying where you are. In the case of colors and mirc, if it was me, I'd send a message, to all my registered users, with a website, which had a script that would work for older mirc's to take the new method and parse it back to the old method.

If mIRC is made to support 24-bit colors (^k#000000-^k#ffffff), then it ought to also support longer messages; much longer than the IRC protocol's limit of 512 characters and mIRC's limit of (somewhere around) 1000 characters. This is necessary for both 24-bit colors and Unicode text.

It's possible to write an IRC server that allows for messages longer than 512 characters (I have done this already), and most other IRC clients (X-Chat and irssi for example) support messages of arbitrary length. mIRC oddly enough does not.

This is patently false and also misleading. mIRC supports "arbitrary" sized messages, though if you have an on input script it would limit to 4k. mIRC will break up the lines into ~450-500 char chunks by default, but this can be disabled via options. What you are probably complaining about is the editbox beep that goes off when you go past the ~500 char length limit. This does not disable you from writing more, it's simply a notification that your line will either be truncated or split.

More important however, is the comment about servers being able to support >512 chars. Yes, you *can* write a server that supports arbitrary length lines. The reality, however, is that few servers actually modify this line length. Most networks limit lines to around 512.

Khaled doesn't control how IRC servers behave, so the idea making colour codes 6x longer on average is going to force IRC networks to increase their line length is false. It will simply mean users will only be able to fit a third to a sixth the number of characters in a message that relied on the heavy use of colours. It doesn't matter how long a line mIRC can send, because servers will still work the same way they have for years.

Here's a few screenshots to show what I'm talking about:

• mIRC: http://i.imgur.com/QDbXJDm.png
• X-Chat: http://i.imgur.com/tYaBzJt.png
• IRSSI: http://i.imgur.com/QVYmzEm.png

The mIRC in that screenshot is a freshly-installed one, version 7.29, with no scripts installed aside from the ones that come with it by default.

It turns out I was incorrect about X-Chat supporting messages of arbitrary length, but my point still stands. IRSSI shows the original message in its entirety, and mIRC truncated the message coming from the server to 983 characters.

I know this won't make existing IRC servers support longer messages unless the hosts decide to implement support, but it would be beneficial to those who do use servers that explicitly support messages longer than 512.

And it would encourage existing server owners to make their server support longer-than-512 messages, because more IRC users can view them.