Forums Feature Suggestions More Colors Please

Regardless of the history, color changes can still be done. We would just want to keep the history in mind in order to learn from it and prevent any issues that happened before from happening again. It does not mean that we should completely forget about making changes to colors or adding new ones.

As far as your history link, it sounds more like ircle's author is whining about not having his method become standard instead of mIRC's. He's even suggesting fewer colors with a single digit fixed width color standard (0-9). Yes, he does offer a variable width option, but requires even more characters by requiring the use of []'s, which as far as I'm concerned looks bad and isn't nearly as quick to type. Obviously, there is the potential for messing up colors in mIRC if you're not paying attention as ircle's author mentioned, but it's far from difficult to avoid that. In most cases, you don't even have to use 0-padding, even with numbers, depending where you put the color. And I think most users have no difficulty with mIRC's system. Even back then, it was easy to work with.

Anyhow, I'd rather see a real history link rather than a whining link if you want to show how it was developed and any issues that may have come about ***in all methods used***. That's much better than a one-sided complaint page.

You are misunderstanding his proposal. His proposal does not require that colors be assigned to the ASCII digits 0-9. Instead the byte following the control code can be any ASCII character which would allow for hundreds of colors. I'm not saying I agree with that design, but just clarifying what he meant.

Also, the brackets [] are just indicating that a second byte is optional. You aren't actually typing out those characters.

Personally, I like the way the current implementation uses written numbers because it is a lot more intuitive to users who don't understand what is going on under the hood. The only thing I would change would be possibly adding another 16 or so colors using the current system.

Ah, I see. Still, Ctrl-K + X ? I'd rather remember numbers than letters for colors. But, yes, that does add many more than 10 colors and actually does offer the fewest extra bytes needed in a message while allowing for a very large number of colors. It does, however, break all scripts that use Ctrl-K by itself to go back to default color unless it has a space after it. So it has pros and cons.

Even though the brackets were meant for optional, he was still saying there had to be an ending character of some sort. I suppose that isn't necessarily bad, but it's not great either. And, not only does it break scripts than use Ctrl-K by itself, but it would break every script that uses colors because none would have that ending character.

In the end, like you, I think the current system works fine. I'm sure there may have been better ways of handling it originally, but I don't think there are any better ways now because most ways that would be considered better would break too many scripts. So the best way to handle it would be to use the current system and make use of colors 16-99, which shouldn't break any scripts and is compatible with most other clients that are already compatible with the mIRC system.

The only other options I can think of if we wanted to go to a new system would be to have some non-printing code (even if it's just a set of 4 Ctrl-B/U/I/O/K characters like BBBB or BBUU or whatever that won't show or affect text) that can be added at the beginning of a line telling mIRC to use the new system and if it's not there, mIRC uses the old system.

Or mIRC adds a script conversion "button" that will convert the current format to a new format so users can update any scripts they use even if the author no longer supports it. I doubt an automatic converter would work all that great, though.

I suppose we *could* also add a new Ctrl code for "advanced colors", but that wouldn't be supported by any other clients or older versions of mIRC and wouldn't show up properly.

So, in the end, only the current method with 00-99 is "safe" to use for colors. And I think 100 colors is plenty. With that many, I think we'll end up with a lot of color spammers as it is. Even so, I'd like to see more colors for messages sent over the server and an RGB option (preferably with color wheel) for local text. I'd like a color wheel for use with /drawtext as well... maybe as a button at the top of the script editor and in mIRC's toolbar that pops it up and inserts the RGB values at the cursor.

That's why the colours should just be *LOCAL*. You'd only get compatibility issues with older versions of mIRC...

How about something like:



$rc(r, g, b) would take the RGB value and insert some special magical control code (or something along those lines), with the RGB value after it. Obviously it should also include support for direct rgb values (i.e. $rc(57843))

Just my 2c. Someone will likely find a flaw.

Riamus, read the *entire* article. And it's not CNTRL-K it's CNTRL-C as CNTRL-K with mIRC inserts a ^C not a ^K. And Ircle introduced it's standard before mIRC supported rich text. Khaled originally agreed to use Ircle's standard but for some reason didn't. And this made developers pretty furious. And since 1996, Khaled hasn't changed his color system at all, despite numerous recommendations.

Do you really expect Khaled to change it now? To do anything about it now? 15 years this debate has gone on, and nothing has changed.

Colors have become the bane of IRC. No one likes them. Whose to blame for this is anyone's guess.

I did read it. That's why I said it was whining. Who cares who was first? mIRC did it how Khaled wanted and it's became as close to a "standard" as we're likely to get. That says that it's at least good enough that people are willing to use it. Maybe another way would be better. Maybe not. mIRC's works just fine. And it doesn't matter if Khaled said he'd use ircle's method. If Khaled decided it wasn't good enough or wouldn't work the way he wanted it to, it's HIS software to write however he wants. Colors weren't a part of the RFC and were not in any way a standard that needed to be followed. Just because one company wanted their way to become a standard doesn't mean people had to agree. And one company's method of doing something doesn't make it a standard just because they were the first to do it. It can only become a standard if others accept it and follow suit. In this case, mIRC's was used instead. Now, if there was already a standard and mIRC ignored it, then there would be reason to fault Khaled's choice. That wasn't the case, so there was nothing wrong with Khaled choosing his way. He also isn't obligated to provide development details to other companies even if they offer theirs to him.

As to what character is used, if I say Ctrl-K, then I'm referring to the key combination ... just like everyone else.

And, no. Khaled isn't likely to CHANGE how colors work (such as changing the format to ircle's method). And I don't think anyone here suggested he would. However, there's a good chance he'll add more color support using the same or an extended version of what is already there.

And "no one likes them" is obviously not true considering the number of requests for MORE colors. Don't make generalizations without facts as has been said to you before. You'll just continue to be wrong.

If you don't like colors, don't use them. MANY others will continue to. More colors being added is one of those things that aren't an issue for people who don't want them. If you're already blocking them, then you don't have to change anything to avoid seeing them. For everyone else who does want them, it adds a lot more support for doing things with themes and other types of scripts.

I think the method you suggest there is way too long to be useful. Something like that will very quickly become too long if you want many colors in a line. Yes, RGB is often suggested and might work, it needs to have some good way to handle it without it taking up anywhere near that much space. RGB converted to Hex without commas and you'd at least drop it to a maximum of 7 characters + a control code. Still rather large, but better than a max of 9 + a control code or multiple characters for an identifier like you show + 2 commas.

Example of yours with Hex (using Ctrl-R for RGB even though it's used for Reverse... not sure what's best for a control code):


Much shorter. And it could be done with even less by using base 26 (A-Z) or base 36 (0-Z) -- 1 character less for each color.

In any case, that's just an example. I'd rather see something short like that than a long drawn out line like what you were showing. And I'm sure there are better ways still that can be used than what I'm showing here and issues involves with using this method. Whatever method is chosen will need thorough testing to determine if it's a good way to handle the colors.

If you don't care about breaking an existing standard, then why would you say...



It doesn't matter which one is better. It's matters that you break an existing standard. Why does CNTRL-K insert ^C and not ^K? Then both standards would exist. (Well ^K is /x09 which is \r, but CNTRL-K could enter anything like ^E).



mIRC's meathod is standard. I don't expect him to change back to IRCle's meathod. But a *new* meathod that wouldn't break either has been suggested many times...

BTW, what's wrong with using HTML markup for this? No need for control codes. An existing robust standard. The obvious choice.

It's not exactly a standard, it's not exactly obvious.

1. There is no HTML markup to represent colours. HTML markups represents content, not layout. The closest you can get is the deprecated <font color="#aaa"></font> syntax.

2. Any HTML/BBcode syntax is likely to be way more obtrusive than control codes are. "<color=red>hello</color>" is already 17 characters longer, and that's only for a single colour. Multiply that by 8 and you're talking about ~140 characters of markup in your editbox that have nothing to do with the message. mIRC's current system could represent the same codes with just 16 characters.

3. Using HTML syntax to declare control codes means you can't use those same HTML codes in a message unless mIRC creates some magical way to escape HTML syntax, which would lead to all around ugliness. Its probable that someone would want to send a message including the literal "<color>" tag. Control codes on the other hand are out of the printable range, so can reasonably expect that they are not part of any IRC message.

I think the real solution here is, as suggested, just to extend mIRC's 16 colour palette to 0-98 (99 is reserved) and allow each one to be customized. This would support the current syntax and would need no changes. It's unlikely people would complain about 99 colours being too limiting. mIRC could also reserve 100+ for local colour palettes which scripts could take advantage of.

In this case, rather than having to find a syntax to support in /echo, you could keep the same syntax and have scripters setup their palettes in advance. mIRC could extend the /color command to register colours to any index at 16+. This would be advantageous to scripters, since it gives you built-in customizability. mIRC could provide its own interface for users to manage their palettes and scripts wouldn't have to. Also, scripts wouldn't be able to screw up by hardcoding colours in their scripts, since everything would be indexed.

The new /color command could be in the form:



You could then use it as per the following example:



Of course, scripts would not call /color each time they /echo, they would do this in their initialization (ON LOAD), so it would be the same as setting their global state.

Also, $color(NewUser) would == 100 in this case, so you could use that too:



mIRC could then provide an extension to the Alt+K dialog to customize all of these registered colours. This would mean any theming script could offload its colour customization settings to mIRC's Alt+K dialogs, making the interface a lot simpler and streamlined for the users.

The only problem I could think of would be multiple scripts registering the same indexes. One thing mIRC could do is opt to remove the index altogether and just use the name via $color(NAME) to refer to any custom colours... but IMO that would make the simple case more difficult. I'm not sure colour clash would be that big a deal. The compromise would be that mIRC could make the index optional so that it would be auto-assigned if missing, that way scripters (who cared) could make use of /echo $color(symbolic_name) instead of numeric indexes and not worry about index collision.

Wait... you seriously think that you can apply a color code change with PUBLIC messages? Umm... no... too late. This is solely for local displaying. This would only apply to local echo commands. You make *any* change to the existing public IRC standard and everyone and they're mother will have a major fit. It's not mIRC's decision to make anymore. You want color changes, they are ONLY going to apply to local displayed messages.

/echo <COLOR="Info Text"/> -a <COLOR="RED"/>Hello <COLOR="FFFFFF"/>World<COLOR="BLUE"/>!

That's not as ugly as it is now...

Well, remote or local doesn't really matter, it's going to equate to a lot of visual noise. You still end up with 8x the data to represent the same thing.

This might be subjective, but I'd bet most people would agree that the syntax you just showed is uglier than the current system. In fact, all you end up doing is introducing yet another syntax that people have to deal with.. an extremely verbose one. Part of the reason Khaled chose control codes over the already existing ANSI codes that other IRC clients supported was for their simplicity and brevity. Even ANSI codes take up less space than your suggested syntax (by a factor of ~2), and Khaled thought even that was too verbose. Not to mention you still have to deal with how someone would be able to express the literal '<color="something">' value in a message.

Exactly! Stick to 0-99 (99 being reverse as argv0 mentioned). It's much cleaner *AND* it works for both public and local messages without breaking anything as any major client I've seen automatically uses a valid color if a number over 15 is used (mIRC uses the default text color). So it helps everyone and doesn't break a thing. Then, as was mentioned, local colors can extend beyond that because it's only local and any changes don't have to be handled by other clients. And, even for local, we want to keep is short and simple.

HTML is absolutely NOT the way to go. You're right MeStinkBAD... yours isn't as ugly as the current method... it is MUCH uglier. It takes much more time to wade through all of the tags to see what the real text is (sometimes causing you to miss text because you miss the end of the tag) than it does to look around control codes. The fact that you can't get anyone to agree with you should tell you something.

I don't understand. This is to be used in scripts... not the input line. And in scripts, you want to be verbose. With the input line you are going to have to still use the current method, CNTRL-K and 00-15.

No one has offered a better solution. And I know HTML syntax works fine, as Colloquy uses full HTML syntax, which allows for far more flexible display output.

Hey, Riamus. Go spend sometime using Irssi... some serious time. Or some time with X-Chat. Or some other client than mIRC. If you respond w/ "I don't want to mIRC is just fine I don't need to learn how other clients do things" then STOP ASKING FOR FEATURES AND CRAP ONLY TO SLAP DOWN EVERY IDEA YOU DON'T LIKE BECAUSE IT'S DIFFERENT! You seriously have *no* idea what you are talking about. Period.

HTML has no relevance in mIRC scripting language. The formats are all wrong for mIRC. Adding it to mIRC scripting would make no sense and would confuse things. There is no legitimate reason to do so when the same functionality can be added using mIRC's format/style as has been explained multiple times in this thread alone, let alone all the other color threads out there. There have been good suggestions offered in the many threads on this and Khaled will choose what he feels works best with MSL.

Just because other things use HTML doesn't make it a valid solution for mIRC. Just like you wouldn't want to see other languages added to mIRC, such as C, VB, PHP, Java, etc. You shouldn't combine two different languages unless you absolutely have to. Differences in formatting make doing so very confusing for users and offers no benefit if the same thing can be done using just one language.

Btw, I don't "slap down" ideas because they are different. I support multiple suggestions that are different as they offer options when Khaled chooses how to do something. However, if I think an improvement can be made to a suggestion, I'll offer the improvement. If I think a suggestion is a really bad idea, I'll say so. Keep in mind that *you* do the exact same thing in this and other topics.

Keep things simple. Simplicity is the key to changes. But that's my opinion.

We can keep things simple by extending it from 00-15 to 00-98, with 99 reserved. However, what would these extra colours be?

Use the EGA colour table. That's 64 colours, and assign numbers 20 through 83 to those numbers. Whether they'd be sequential is another issue. Perhaps matching colours close to what they'd normally be would be best. For example, 24 is currently the colour yellow, so I would suggest one of those 64 colours to be close as possible to that colour.