Forums Feature Suggestions More colors?

I wish I had more "nuances" of the colors..

It really makes for a great envirment, when one can use the same color, in diferent shades.

Thank you for hearing me, and pleas help!

here is a picture to ilustrate what I mean; Sorry for my spelling and grammars.

When you have the mIRC colours dialog open, put the mouse in one of the colours and right click.

lol..

I should have know..

Thank you so much for answering such a "silly" question!

Great!


Edit..

still cannot do it some places though.

would be neat to have it all the places, like in the display meny settings thing.


like here i.e.

those are the 16 possable colors, so if u alter a color it alteres there.

By the way, maybe some people would like to see more colors added. I mean, being able to send messages using "true colors" (24/32 bits) for example.
I'd like to highlight the fact that the colors' implementation is client dependant (so for example, the display may not be the same under mIRC and xchat, if any).
What's more, the current implementation needs to embed color codes using special characters. I'm not sure it can be expanded so as to allow for "abritrary" colors to be sent.

The problem is that it would use too much of the message lenght. I think a max of 100 colors would be nice. (0-99)

0-98. The 99th is the transparent color

Id like to point out..


IT IS OK THAT THERE IS ONLY 16 COLOURS FOR SENNDING..


OR else MIRC would look like a [censored] rainbow!
:tongue:

No one wants that..

Theses Colours I request is ONLY SEEN BY THE PERSON USING THAT SINGUALR VERSION OF MIRC!

But i see now what the confusion is about, and I see why this may or may not help out there..

I think you're wrong, a lot of people want that, I've seen this being requested many times here and there (and I'm aware that I'm just discussing it again, but since you've brought the subject...). Additional colour spots (16-98) would be great.

mIRC would look like a [censored] rainbow only if its particular user wanted it to look like that. I can't see what's wrong about it. The colour values aren't shared through IRC, only the ctrl codes they associate with are. Other people would see the colours they wanted mIRC to show.

Of course, I could see a problem with people creating autocolour scripts using 30, 40 colours per message. To avoid this particular problem, my suggestion is: make additional colours local (ie. IRC messages with ctrlK+16 would still show up with the same colour as ctrlK+0, but you could use ctrlK+16's unique colour for things other than messages sent or received - for displaying purposes). If they're local, then no autocolour scripts like in the example mentioned would be possible.

mIRC theming (as in old 5.xx "efnet" scripts like opal, convex, one, etc etc) could rise from the dead if such feature existed.

Sorry for bumping an old thread (with such a frequently discussed subject, though), but I've just noticed that the idea I've been suggesting here is supported (or even created) by Ircle's colour coding protocol: a list of private colours and another list of public ones, the former being known as "static" and the latter as "dynamic". The suggestion here is almost behind the same idea, and I thought this was worth mentioning: it's been done, I think it would be great if mIRC did the same or something like that.

I don't mean mIRC should apply to Ircle's method, because I don't think anyone would like the idea of "static" colours, or the lack of background colours, etc. It's too late to change the colour system, in my opinion. However, mIRC could base its own method behind the "public-private" principle, and then people could use all the colours from 16 to 98 (as private colours) as they'd want for their scripts, leaving 0 to 15 as they currently are (public colours).

For more info on Ircle's colour coding protocol and the debate behind the different protocols, click here. There are some good points in that page, in my opinion. I realize there must have been a lot of discussion about this subject in the past, but after reading that, I thought I should at least point out where the idea comes from.

I'd like the the colour argument for /echo to accept RGB values.



I don't think the human eye would really be able to tell the difference between 0 to 15 on the RGB scale (I can't anyway), so it could still accept those values as mIRC colours, and people could use 16 for black.

I can't think of a single problem with this method, but I'm sure someone else might.

I think an RGB value for /echo is a good idea for a simple coloured info line or something, but that's about it, that's very limited for the matter at hand...



I'm not sure I understood what you're talking about. Which values are "those"?
Edit: nevermind, I've read the first post on this thread again, now this makes sense.

Just in case anyone else misses the point, what I meant was that /echo [0-15] would use the colour for that index set in the box that opens when you hit ctrl+k, but anything above 15 would refer to the RGB value of a colour.

/echo 37463 -a t would be valid, for example.

As for it being limited, it will let you locally use any colour in the spectrum. I don't actually think it can get any better than that :p

I cant see no harm in locally extending the colours. Wouldn't put them to use myself though.

It can get better. I mean, this would be limited because this wouldn't support colour themes natively. You still wouldn't be able to assign such an RGB colour to "info text" echoes, for example, without compromising the ctrl+k+0-15 colour range.
This is the whole point of having a local colour range: to make it work with mIRC colour themes. Otherwise, of course, a simple RGB switch for /echo would be sufficient... but it's not.

I would definately support that idea for extended /echo RGB color chart.

I could see how compromising the 0-15 color range could bug people who were using older versions of mIRC, the code might show up on their screen, and be non-interpretable to thier current version?

As a stepping stone, enhancing local colors would be great. I think it would catch the eye of alot of users who aren't into using dll's as a means of theme enhancement. Dll's are nice but there is a sense of satisfaction that comes along with knowing that the scheme is a result of ones own fabrication rather than whatever result the dll produces. Not to mention that a dll, is generally for advanced users, ...people who arent sure how they work have a hard time taking the step to learn. Especially when they dont really know what its doing, you just get what you get.

As to where giving them more colors to make code the way they already know how, might make things more interesting for level 1 or otherwise starter writers. In turn, promoting mIRC.

replied to last in thread:


I dont know if anybody mentioned this, but perhaps mirc could (maybe thru dll - I dont pretend to know about this stuff) base it's color range based off of video display settings. For example, my video card (GForce FX 5600) is set for 32bit color. If mirc were to allow local color enhancements, it would be good to use that as it's starting point to see how many colors can be used, and then do (for sake of example) the hexidecimal (the way HTML can do it - if I called this wrong) codes. Basically:

1) Gather video card settings to figure out displayable colors
2) on the local side, allow for a pallette for us to choose from


Make any sence?

Sorry, I don't quite follow you here... but if you're by any chance suggesting a modification in the colour "protocol" mIRC uses, I'd say that's not the way...

Im saying expand (not change necessarily) how mirc handles LOCAL colors not colors that go out over the net. I'm beyond trying to change mirc's EXTERNAL behavior for reasons of never wanting to hear the words "that's not in the RFC standard" as the excuse for why nothing gets changed for the better.

Yeah, I didn't get the handling, though.

What I was suggesting is base mirc's LOCAL colors on how many colors the video card can handle vs a set number of new colors - some of which a card might not be able to handle.

If more colours are allowed locally then just stick to 24-bit colour. Windows will handle the colour conversion for the system's display settings. It's unnecessary for that kind of control to be implemented in software, especially when we're talking about coloured text.

see? that's why I love this forum, because there's soo much expertise on here that there's a wealth of information I get your point and it makes a lot of sense. I wasnt trying to say let MIRC handle the colors, I was saying let mirc tap into WINDOWS handling of colors. I probably didn't explain myself right, in which case, I am fully agreeing with your post

Never re-installed a PC where you had to safe-boot with networking support to get the display drivers from the internet ? You'll get there as it will still display but the colours are horrendous!

You're right, I never have, but a reformat should not be considered normal operating procedures. If it WAS, there would be MANY more features people would want and to be quite honest, if you need to do that continuously after the reformat, the OS sucks to begin with :P

Although that sounds good, Windows really does run better if it's reinstalled at least every couple of years. Of course, perhaps that DOES say something about the OS.

Well, ignoring the MS rants that people tend to do here, I still think mirc should, IF it plans on supporting more colors, take the S.O.P. (standard operating procedure) and use that instead of catering towards those who need to "backdoor" the video stuff.

how about

/echo rgb37463 -a t

I don't see the point. Could just make an extra switch rather than do that (if you feel that's necessary), to keep it consistent with the rest of the language. /echo -R

I have better luck with every 6 months :p

But back to the topic.

I like the local/public colors idea. This gives the user the ability to use up to 98 (I personally would like to see 0-255) colors, but, for clients that like to colorspam for god only knows what reason, its still only going to be in the 16 base colors.

Though, if these are added, dialogs will have to be redesigned to show the new colors. Adding in a simple 'More..' button would do the job. Pops up a larger display much like ctrl+k that shows all colors. (16x16 grid would be perfect for 256 colors..) Im sure an option to Enable/disable the extra colors would be needed to as there is prolly some users out there that dont want the extra colors.

If you take a look at irc servers.. how many of them follow the rfc standard anymore? Why should clients be forced to do the same? The server programs are trying to innovate.. I would think clients would do the same :p

some copy/print screening and messing with colors results in this:



This is just 64 color boxes. (and being lazy, only filled most of them) While doing this, i realized.. 64 is a LOT of colors.. and might be plenty. Forget 98 some :p

why not let mirc use html colors
and even the option ( on/ off ) to display the other users their color.

The main thing to keep in mind is that other clients are used rather than just mIRC. Adding additional colors (except locally), would just cause problems. Additional local colors wouldn't be bad for scripted events and other things, but I don't think you need hundreds of them.

Using html colors would have to be local only, otherwise only mirc would be able to understand it (unless other clients adopted it)

Staying with ctrl+k is the best way to 'upgrade' colors.. and the local colors only would prolly be the best route out of all of them.

I would think doing it this way would be less of a coding nightmare, it wouldn't change the already established 'protocol' and other clients would have the option to add more colors or not. This would also keep people who use other clients from seeing new mirc color codes as random giberish on their clients :p

@all

I don't know if it has been mentioned before, but I think mIRC used to consider color codes 16-98 to simply be repeats of 0-15. Now, it seems to consider 16-98 to be default text color. If other clients do the same thing (accept color codes 16-98 without errors) then mIRC could actually send extended color codes to channels. The non-mIRC clients would simply see the colors as however their client is set to render them. Other mIRC clients would see the correct colors, of course.

-genius_at_work

Interesting... I knew it rotated through the colors after 15, (16=0, 17=1, 18=2...) but didn't know that it changed recently.. perhaps its being changed for more colors? we can only hope :p

Just for comparison, Ircle supported 28 colors... seen here...


Beleive me, 28 colors was enough. I don't see why the number of colors (for text) should be more than 32. MSPAINT also has a default palette of 28 colors.

Of course... when will mIRC's editbox be WYSIWIG? It still can't display color or styles. Nore can the SCRIPT editor. Rather you still see "03Hello World" instead of "Hello World". This needs to be addressed!

If you feel this needs to be addressed, then it should be done so in it's own topic.

I dont agree, if the editbox is made WYSIWYG, then how are you to know WHERE the control codes are? and how are you to easily edit/remove them?

I assume he means to make it like IM or Word or whatever, where you have a color pallete that you highlight text and select the color and it changes it and you never see control codes. I'd rather just see colors based on what command(s) you're using like you see in many programming languages.

You would still not know where in the text the control codes were, so editing would be a pain, even if you think you cleared some control codes, it may just be that those left are not visible to you (control+o or a control+k before a space with a control+o after it).

The wysiwyg method works fine for word processors, but i have my doubts about its convenience and usefulness in a chat client like mirc.

When done programmatically, it's true that it might create a mess such as "^b^b^b" (instead of just "^b") - although there are ways to reduce this, and it would really only be a problem for large lines anyway. Even if the control codes are a mess, it doesn't really matter as long as they can be sent and viewed by other clients.

Formatting shouldn't be hidden from the scripter. It's simply a bad idea. Syntax highlighting which somehow differentiated each of the control codes so they could easily be told apart would be great, but WYSIWYG is something for end users, not people writing code.

Consider some simple situations:

echo -a $replace(04,)
becomes:
echo -a $replace(,)

echo -a 2hello, 1,0there
becomes:
echo -a hello, there
as does:
echo -a 2hello, 1there
and:
echo -a 2hello, there

var %warn = 04 | echo -a %warn $+ DANGER!: This isn't coloured properly!
becomes:
var %warn = | echo -a %warn $+ DANGER!: This isn't coloured properly!

There are obviously thousands of variations on these, but I think you get the picture. WYSIWYG doesn't work in code where the formatting could be coming from any number of places besides being literally inputted into the script, and can cause a lot of headaches for a scripter if he's getting a bug because of characters he can't even see.

In my head, the idea would be that you can select a bunch of text with your mouse to format it, but if you hit Ctrl+K/B/O/U you would still see the control code.

And I was also speaking only for the editbox, not the script editor. I don't think WYSIWYG has any place in a coding environment.

Yeah, looks like the whole conversation was about that. For some reason I got it into my head that this was about the script editor. Feel free to disregard my post.

Yeah, I think the editbox would be okay. I don't think we need the script editor to be WYSIWYG.

starbucks_mafia: In case you misunderstood my comment about syntax highlighting, I wasn't referring to control codes changing how the syntax looks. I was referring to making stuff like variable names be one color and channel names another and commands a third and so on.

Yeah I got what you meant about syntax highlighting (I assume you're probably talking as much about the script editor as I was). I'd like to see syntax highlighting in mIRC's script editor too, but in addition to the traditional highlighting (commands, identifiers, variables) I'd like to see the control codes highlighted differently. I don't mean highlighted based on what kind of formatting effect they have on the text but just highlighting the actual control code characters themselves so that it's easy to see whether you're looking at [Ctrl+K], [Ctrl+B], [Ctrl+R], or [Ctrl+O] instead of the current situation where you have to copy the character and go out of the editor to a mIRC editbox to test what it is.

Now *that* would be nice.

Note that if I install the Asian language pack (code page), then the square boxes  show up as "L"-shaped things that are rotated based on what control code you use. The only problem is that Ctrl-O happens to look like a space, which doesn't break a script that you already have, but does prevent you from putting Ctrl-O into a script. If that one code was changed, then it would be perfect.

also ctrl+u (underline) doesn't even appear at all when you have asian language support installed :-P

now with Vista coming it's an even bigger annoyance since that has this behavious by default from what I have heard and read

Ah, maybe it was Ctrl-U and not Ctrl-O that was the "space" that I was talking about. I haven't used it for a long time because that was such a problem.

I think that if mIRC could change the Ctrl-U character so that it wasn't a space/blank in the Asian language codepage, then it would work out well. The problem with that is that, to do so, you'd have to change the $chr used for it and that would break scripts and wouldn't be compatible with other clients unless mIRC worked behind the scenes on it and just converted it for internal use. No idea... just commenting on the issue. Having the codes a different color or something would definitely help to make it easier to see the difference.

Control codes are not meant to be seen. They are used for some type of CONTROL (in this case how text is displayed).

There should be identifiers for control codes. $bo = bold! $ul = underline! You get the idea I hope.

Until then, I have my own identifiers for control codes...

I'd rather see them and have the use of a quick Ctrl-K# rather than trying to nest a lot of identifiers. I can just imagine what someone trying to make rainbow text would need to do and how confusing it would look (not that I like rainbow text, but it was an example). Obviously, you can script a loop to do it without the identifiers, but if you do, then you're still doing it the same way as it is already.

I think you are over generalising and lumping mirc into the same catagory as instant messengers and word processor type programs.

The only situation i can think of where your above identifiers would be of much use would be when storing information in an ini file.

Which is when I use $replace and replace the stored control codes with something unique that can be stored so that I can read it back out later and replace it with the ctrl codes again.