Forums Feature Suggestions More Colors Please

It would be great if mIRC had more colors to choose from for things such as nick color, text color, color schemes, etc. Only having 15 to choose from can be a bit awkward. Would be nice to have varying shades of colors, tints, etc.

Thanks.

ALT + K then right click the colour palettes.

What exactly is "awkward" about 16 (not 15) colours? Windows itself only has a palette of about 16 colours, and it never seemed awkward to me. Websites usually design for somewhere between 3-5 colours, but never much more than that. Certainly 16 sounds enough if you're going to make a sane looking theme.

That said, "more colours" has been suggested before, a few times in fact. The search feature in the forum can help you look at the discussions and possibly chime in on those, if you have something new to add. Until then, it's up to Khaled to take this on.

The reason I would like more than the 16 colors is too support other peoples fonts and have more flexibility for graphic design.

Windows has a pallette of about 16 colors? Maybe win95. A basic windows color pallete using a 640x480 res is 256 colors. A full color palette using "true color" has the capacity for 16,777,216 different possible colors.

One website only uses a couple different colors so it doesnt look messy, but what you are suggesting would be analagous to ALL websites only allowing 16 colors which, of course, is ridiculous.

Bottom line, your opinion is appreciated argv0, but it is only your opinion. I personally would utilize a full color pallete if it were available. I'd like to be able to call colors by their rgb value and not be limited to 16 colors which requires an alias to convert the rgb value to the closest color available among my chosen 16, which is what I've had to do.

You're confusing "colorspace" with "palette". Windows has supported 16BIT and 32BIT colorspaces for a long time (ie. even Windows 95), but the standard system *palette* uses a small set of those colours. mIRC has the ability to render any colour, the only difference is you can only use 16 of them at a time in the text display.

It's one thing to say "you would use this" if it were available, it's another thing to say "you need this". As I said before in other threads regarding this topic, supporting more colours would be great. Calling the current system "awkward" is simply false, though.

In any case, the point of my original response was to point out that this has been suggested before, and the discussion has basically been hashed out to completion. Khaled knows about this, so be patient and let him decide whether to implement it.

argv0, This is a feature request forum, not a forced butt-sex forum.
He's doing exactly what the forum was made for, requesting a feature.
He's not saying that he NEEDS it, but that he'd like it.
</rant>

What I would believe to make sense is to allow users to use custom color values (HEX/RGB) with the echo command with the -c switch

I'm sure this is a feature, but even if we could change the 16 colors, and not have the colors (that are already displayed) change, We could show a lot more colors (limit 16 per line).

Obviously if this was done, people would still complain that there's not enough colors for one line. lol

People will always have something to complain about :P

now that would be really nice. :_)

I believe the default 16 colors should stay untouched for cross clients support but... I agree that it would be really nice to support RGB for local echo. Maybe CTRL+K then #00000,ffffff for background and foreground colors ? or $rgb(0,0,0,255,255,255) urgh!

Yes, i'm with you. Local colouring this way would be fantastic, especially when making themes. But there would have to be some kind of colour palette in the mIRC editor, similar to when you are in the editbox and do ALT +K -> right click a palette -> define custom colours. Otherwise it'd be a nightmare flicking back and forth to get the RGB you needed.

Hum, compatibility with the current coloring system would break for <ctrl-k>#<A>,<B>.
Atm this means "undo coloring" (return to default linke color) but keep e.g. bold/underline formatting. Example:
The #-char also has a special use in IRC - to denote a channel as the target like in
(#mychan might be a channel named #12275 or the like).

Now, a single rgb-digit would in theory work for local coloring via the echo command - if used together with the -c switch. Some switch is required anyway: to distinguish "color $rgb(12,0,0)" (= 12) from "color 12 of the mIRC default palette". This in turn implies some new switch for /aline and the like...
But then, would people be satisfied with the option to set rgb line colors? I think they instantly would request an option to rgb-color parts/words of the line as well. And as it mustn't come into conflict with the established parsing of in-line ctrl-k[N[,N]] it would in turn require e.g. a distinct, new "control code" char, to denote "rgb color digits follow". This char *could* be called by a shortcut like ctrl-k calls a $chr(3), and it *could* open a different rgb-color picler the way ctrl-k opens the default color picker.

@vexed2: As in any case you can use it only locally, that is in scripts most of all: One could e.g. create a "custom" palette for a script by assigning color numbers to catchy variables. Or create a custom identifier $mycol(color title) to return those numbers...

... just some thoughts

I know this thread is old. But, if more colours are added, I say keep the original 16 the same. And since we already have ctrl-k NN,NN, we could just have 99 different colours. Like, for example, 8, 24, 40, etc. are the same colour. Why not have 24, 40, and so on, to be differing colours?

I mentioned in another post to just add in a 6-bit RGB palette. 64 colours, perhaps starting at ctrl-K from 20 to 83.

instead of adding more colors, add the option to set pallete colors after 15
ie:

would set ctrl+k16 to the rrr,ggg,bbb color

That's one idea. But, wouldn't we need some sort of standard to emerge?

Yeah. About the only way to get anything other than an increased number of LOCAL colors (i.e. /echo) is to get all IRC clients (or at least the main ones) to agree on adding the support at about the same time and to add the same colors as default. Even then, if you add more than 0-99, it will always fail on anyone using older clients (the next number would be visible in them). Even so, 100 colors should be plenty for most people and as long as the main clients all agree on a "standard" and update about the same time, it shouldn't break anything. I think most clients automatically change colors > 15 to a 0-15 color... even if it's just the default color.

I'd appreciate just the local colors. Would help making themes and the such alot more versital(sp?)

Urg... you people should probably understand the history of IRC and color. It's not pretty.

I know about the history already. But, I still stick to what I said.

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.