Forums Feature Suggestions New colors

I like the way you talk about making it compatible with other clients like it's a big issue, if they want to add the extra codes (if mIRC had them), it would take them an hour, maybe less to add them, if they don't want to add the extra codes, then the users will have to deal with it.

A weeee bit more emphasis on 'small number' is needed there.



Well in this case I think it definitely is outdated.



That would mean they all changed clients/versions so they would be able to strip the codes?



By 'my logic' mIRC would be able to support a wider range of colours, as intended by the sender, without the sendee having to maintain an 'assumed-normal' palette of colours. I'm not talking specifications, absolute values or the 'absolute maximum' of a technology. I'm not saying mIRC should employ each and every possible feature just because it 'can be done' either. I'm suggesting the current palette of sixteen colours (if I was slightly deformed I could count them with my fingers) is limited, and that I think extending beyond this amount would be a great idea.

There is no way to implement the feature without breaking compatability. The other suggestion of extending ^k15 to 99 suffers the same problems as the existing scheme (in my opinion), and if implemented will have the same compatability issues next-time-around if it is ever revised. As I feel these facts are well and truly established I wonder how *you*, in the same name of *progress*, would implement such a feature without breaking compatability?

If you're talking about adding an entirely new colour system, which is what I was talking about in that quote, then you're completely wrong. A few hours to add complete colour handling, colour stripping, interoperability between the current colour method and the new? You think that will take only a few hours? How many fully functional IRC clients and libraries have you written to base that estimate on?

- Yes. That was ten years ago when IRC was a completely different place, with a mere fragment of the users and relatively little software. And even now there's still plenty of people who resent the fact that mIRC added it. And it didn't happen overnight. I'm sure there were several months and years where people would see stupid little characters amongst other people's text.



To quote myself from a couple of posts up:

The same is not true of the colour scheme you're suggesting.

Absolutely correct, and I still see no way the scheme could be implemented without breaking compatability.

*Chalks that onto the blackboard and does the screechy nail thing for added effect*

So the decision is whether the benefits of the new colours will outweigh breaking compatability with older versions of mIRC, other clients, and that guy that IRCs using a tin can. You already know what my opinion on that one is....

Absolutely none, it was a guess, but my guess is it won't even take as long as the current ^K0-15 to implement.

Considering the rgb value is already there (maybe in hexidecimal?), you won't have to see how the users defined ^K4 or whatever, then instead of the current ^K dialog, you can use the windows common colour dialog and it returns the selected rgb for you.

- Yes... which is why I'm saying if, if, extra colours were to be added, they should be done to conform to the current double digit format in which case they wouldn't break compatability beyond the obvious. I've said this three times now, is it getting through?

While those colours would still be 'compatible', they would suffer from the same issues that exist with the current: the colour, as defined by the receiver, can vary wildly from that intended by the sender.

... This would be four times then..

Yeah I'm sure developers will love having to write code that can switch between methods to handle stuff like ^k04hello ^xFF0DEAthere^x, ^xAA6732,788123joe^k!!!^x

Yes, but with 98 colours there would be no need to redefine colours, with perhaps the exception of slightly softening shades - which would make no significant difference to the colour.

That becomes a bit harder where theming is involved. Some MTS themes for example would take the entire palette for their 16 shades of vomit. I guess that is an argument for arguments sake though as I don't like vomit..

I think mIRC should allow colours to be changed 'mid screen' without effecting existing colours, introduce a flag to revert a /colour after a script finishes executing, and an '/echo-without-crlf' option to allow codes to be configured halfway through a line (so that theme could have even more shades of vomit). The added colour code would make these ideas redundant however.