|
Joined: Aug 2004
Posts: 2
Bowl of petunias
|
OP
Bowl of petunias
Joined: Aug 2004
Posts: 2 |
English:
It would like to give the idea of that it was possible to create more colors for mIRC, but these colors would be created by the users.
For example: The //color number $rgb(r,g,b) modifies a color, it would be interesting if we could create our colors, and for the excessively using ones, these colors were seen of the following form:
If I it is created the 16 color for example, it would be equal the color 0(White) for the excessively using ones, the 17 would be the color 1(Black), the 18 (Blue)... Following the sequence.
It would like to know what they find, and if this is possible.
PS: Why of this suggestion? So that the colors of addons and scripts could vary...
Portuguese:
Gostaria de dar a ideia de que fosse possivel os criar mais cores para o mIRC, mas essas cores seriam criadas pelos usuarios.
Por exemplo: O comando //color numero $rgb(r,g,b) altera uma cor, seria interessante se pudessimos criar nossas cores, e para os demais usuarios, essas cores fossem vistas da seguinte forma:
Se eu cria-se a cor 16 por exemplo, ela seria igual a cor 0(Branca) para os damais usuarios, a 17 seria a cor 1(Preto), a 18 (Azul) e etc...
Gostaria saber o que acham, e se isso é possivel.
PS: Por que dessa sugestão? Para que as cores dos addons e scripts pudessem variar...
|
|
|
|
Joined: Dec 2002
Posts: 788
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 788 |
This has been suggested many times over, I imagine one of the main reason there are infact only 16 colours in mIRC is because they are deemed "primary" and suitable for all computers, regardless of that computers graphical settings. Also there is nothing stopping "colour addons" from changing your /color settings. See here. Eamonn.
|
|
|
|
Joined: Apr 2004
Posts: 218
Fjord artisan
|
Fjord artisan
Joined: Apr 2004
Posts: 218 |
Beyond the /color issue, why stop at 16 colors, why can't khaled create 21 colors? ;|
Live to Dream & Dream for Life
|
|
|
|
Joined: Nov 2003
Posts: 257
Fjord artisan
|
Fjord artisan
Joined: Nov 2003
Posts: 257 |
most experienced users should know you can edit any default color in mIRC. Right click the color after you press ctrl + K and you can edit how it appears to you as you see it.
|
|
|
|
Joined: Dec 2002
Posts: 2,985
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,985 |
He can do it but it looks like he's choosing not to. I think it holds mIRC back a little - other clients such as Bersirc manage to be able to support the 32 bit colour range with no problems, as far as theming goes anyway. 16 is ample for sending colours over IRC though and helps compatability a bit.
|
|
|
|
Joined: Jun 2004
Posts: 65
Babel fish
|
Babel fish
Joined: Jun 2004
Posts: 65 |
(correct me if im wrong) wasnt the color spec writen for when the average use used a 16 color monitor?
ofcourse..if you want to write a script to send more colors, hex is the way to go...
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
ofcourse..if you want to write a script to send more colors, hex is the way to go... - Not really. Besides looking messed up in everyone else's display (whereas sticking with the double-digit format would not), a 24-bit number is hardly appropriate to send at run-time. How many people do you think will want to type something like [color:green]^kFF0F0AW ^kAB0E45elcome ^kFF0F0AT ^kFF0F0Ao ^kFF0F0A# ^kFF0F0Amooblahlobster ^k0ADEFF!!!!!![/color]? 24-bit hexadecimal only works in HTML because it's written at design-time.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Nov 2003
Posts: 257
Fjord artisan
|
Fjord artisan
Joined: Nov 2003
Posts: 257 |
|
|
|
|
Joined: Dec 2002
Posts: 349
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 349 |
"ofcourse..if you want to write a script to send more colors, hex is the way to go..."
Scripts aren't 'design-time'?
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
What good are colours that can only practically used by pre-written scripts/programs?
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 349
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 349 |
That depends if they replace the current scheme or complement it.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
Well they couldn't replace anything, there are far too many clients using the current methods. But even as an addition it would still be pointless IMO. Not only because of the non-run-time'ability of it but also because there's simply no need for 16.7 million colours of text. The 98 potentially available to the current method is more than enough. Not to mention that if mIRC put something like this in there would be around 200 other IRC client/library/server projects all with developers seriously pissed off at it. Not to mention the users of all those things and of old versions of mIRC.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 349
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 349 |
No application or operating system would need 16 million+ different colours of text either. This doesn't make supporting the usage of any (and all) of these colours 'pointless'.
The oft-suggested extension to the current 'k'olour scheme (extending beyond k16) has not yet been implemented. Even then, having to change a 'constant' colour simply to display a line in one's chosen colour (and then change it back) seems a kludge. I think this is part of the reason behind @picwins increasing popularity.
The current 16 colours are already limited across IRC by what others assume is the 'regular' colour corresponding to that code. I'd much rather see a persons colour exactly as they intended it. Adding a new control code (or extending an existing one) will cause backwards-compatability issues, there's no solution to that.
Lastly, if it were added, I doubt it would simply be thrown in without a method (popup GUI etc.) to select a colour without typing its RGB value.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
The reason why other programs need that many colours is for photo-quality images, beyond that there is no real need for them. Besides, mIRC itself does support 24-bit colour, it's only the IRC protocol that doesn't, and the protocol doesn't need them.
What is the obsession with seeing what colours people sent in the precise shade in which they were possibly intended to be seen? Does #A0456E make the words 'omfg!?!?!!!' any more thought-provoking then #A04560? The only thing that can be argued is a reasonable level of accuracy for colour portrayal so that a fair amount of colours and shades can be used and displayed without being dramatically changed so that the original intent of the colours (if any) isn't removed and so the colours don't become garish (assuming they weren't to start with) and without having to change the meaning of colour codes. That is precisely what can be done using 98 colours of double digits - without compromising backwards compatability.
Picwin popularity has nothing to do with it since there are no scripts that I'm aware of that even implement 24-bit colour codes, so why would people make displays for a colour scheme that doesn't exist and hopefully never will.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 2,985
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,985 |
You are wrong. Technically a coloured screen will support any visible colour in the spectrum. Monitors are just television sets without tuners. The limitation was in the computer itself.
|
|
|
|
Joined: Dec 2002
Posts: 349
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 349 |
I doubt every client would properly support the extension above ^k16. Older versions of mIRC itself perform N=N%16 when determining the code, which would result in colour far from that intended. My point was that any change to the colour scheme will cause issues.
Most text in a picwin script is coloured to a skin or theme running on that window. I feel picwins are popular because the '//colour | whatever | colour' kludge doesn't have to be used. Also, changing the colours this way has some funky effects on already displayed text.
The fact remains mIRC cannot display more than 16 colours in a single line of text, and often entire screen. What's the obsession with keeping this limitation? Whats the point of extending to 100 colours when by 'dramatically' changing these colours we have the same issue of assumption that exists with the present 16?
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
I doubt every client would properly support the extension above ^k16. Older versions of mIRC itself perform N=N%16 when determining the code, which would result in colour far from that intended. My point was that any change to the colour scheme will cause issues. - Yes of course the colours wouldn't appear correctly in clients that didn't support the system, that much goes without saying. But the new colours will still be recognized as colours, meaning that IRC bots that apply semantics to IRC conversations or generate statistics from logs, clients with colour stripping settings, and even some IRCds that have colour stripping modes will all still work correctly. Most text in a picwin script is coloured to a skin or theme running on that window. I feel picwins are popular because the '//colour | whatever | colour' kludge doesn't have to be used. Also, changing the colours this way has some funky effects on already displayed text. - That's just creating a script to replicate the 'kludge' as you call it. They're not adding any extra colours, just using a script to display the old ones without changing mIRC's settings. The fact remains mIRC cannot display more than 16 colours in a single line of text, and often entire screen. What's the obsession with keeping this limitation? Whats the point of extending to 100 colours when by 'dramatically' changing these colours we have the same issue of assumption that exists with the present 16? - The obsession isn't with the limitation, the obsession is with using a method that is practical for the medium and with using a method that won't be backwards incompatible and ultimately detract from IRC's intended purpose as a communication protocol. It's a lot harder to communicate when one user is seeing hexadecimal codes strewn throughout a conversation.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 349
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 349 |
They're not adding any extra colours, just using a script to display the old ones without changing mIRC's settings. I was referring to /drawtext's -r switch, to specify an RGB value. Beyond @picwins the only way to display a colour not in mIRC's current palette is to use the 'kludge'. I think its established the limitation can't be overcome without breaking compatability. Many users/channels already request users not use colours in conversation - will this change make the users suddenly unable to disable their colours? It may seem selfish, but I see no need to maintain compatability when the feature is terribly outdated and limited, when compatability problems already exist with the current scheme, when the use of such a feature is entirely optional, and when the ability to ban and ignore the people that continue using the feature despite being requested not to entirely possible.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
I was referring to /drawtext's -r switch, to specify an RGB value. Beyond @picwins the only way to display a colour not in mIRC's current palette is to use the 'kludge'. - But /drawtext -r is only displaying more colours locally, they're not sending any extra colours in control codes. I think its established the limitation can't be overcome without breaking compatability. Many users/channels already request users not use colours in conversation - will this change make the users suddenly unable to disable their colours? - No. But it will mean that those who strip colours cannot do so unless they use the right version of the right client. Which means either someone is forced to change their client or someone else is forced not to use certain colours in certain channels - which goes against the current capability of 'to each their own'. It may seem selfish, but I see no need to maintain compatability when the feature is terribly outdated and limited, when compatability problems already exist with the current scheme, when the use of such a feature is entirely optional, and when the ability to ban and ignore the people that continue using the feature despite being requested not to entirely possible. - You seem to think a small number of colours automatically means it's 'outdated'. 24-bit colour is already being superseded by 32-bit colour which has an 8-bit alpha channel, so by your logic why not support that and allow transparency in text? Or how about 48-bit colour that's being used in some scanners and display devices? The amount of colours is infinite, simply because something doesn't use the absolute maximum that the technology will allow doesn't mean it's necessarily outdated or wrong. As far as compatability problems go I don't know of any clients in common use today that don't support the current control code system. The need to maintain compatability is because it's required in order to keep IRC being correctly useable as a chat medium. If we're going to say "compatability doesn't matter as long as the feature is neat or 'up-to-date'" then why not have mIRC add a control code which supports base-64 encoded pictures? Sure it'll create lines and lines of gibberish to non-updated users and force all clients and servers to completely re-work their programs but hey, what's compatability when there's *progress* to be made?
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Apr 2003
Posts: 701
Hoopy frood
|
Hoopy frood
Joined: Apr 2003
Posts: 701 |
Just my suggestion: 1) Keep the standard ^k0-15 codes as they were
2) possible later extension: ^k16-31 for extra (predefined) colors if someone (K?) gets in a colorful mood
3) have the colors in the Colors dialog (Action text, ctcp text etc) be able to use the color codes ^k32-63, codes that do not appear in the ^k-popup. This way you can have colors for sending to other people (normally with a defined color for each color code number) and you have colors for building your own GUI/theme that you can change at will yourself... This would also make it possible to have all colors of the default palette actually be visible (if not readable) in your mIRC window. So the colorr codes ^k32-63 should not be sent to the server, only things like $color(Action text) should return numbers between 32 and 63 for echoing or default display of actions.. The 63 limit is rather arbitrary, since there are now already 29 in use that would only leave 3 codes for new events, but I hope you get the point... (Multiple events can have same color, like it's the case now)
Since ^k0-99 should be supported by most clients and servers (for stripping or at least knowing it's a color code), there's not really a problem. I think other clients use %16 to get a color or just strip it or ignore it...
|
|
|
|
Joined: Nov 2003
Posts: 2,327
Hoopy frood
|
Hoopy frood
Joined: Nov 2003
Posts: 2,327 |
As far as compatability problems go I don't know of any clients in common use today that don't support the current control code system. The need to maintain compatability is because it's required in order to keep IRC being correctly useable as a chat client. 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.
New username: hixxy
|
|
|
|
Joined: Dec 2002
Posts: 349
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 349 |
You seem to think a small number of colours automatically means it's 'outdated'. A weeee bit more emphasis on 'small number' is needed there. doesn't mean it's necessarily outdated Well in this case I think it definitely is outdated. I don't know of any clients in common use today that don't support the current control code system. 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?
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
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?
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
That would mean they all changed clients/versions so they would be able to strip the codes? - 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. 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. To quote myself from a couple of posts up: Yes of course the colours wouldn't appear correctly in clients that didn't support the system, that much goes without saying. But the new colours will still be recognized as colours, meaning that IRC bots that apply semantics to IRC conversations or generate statistics from logs, clients with colour stripping settings, and even some IRCds that have colour stripping modes will all still work correctly. The same is not true of the colour scheme you're suggesting.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 349
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 349 |
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....
|
|
|
|
Joined: Nov 2003
Posts: 2,327
Hoopy frood
|
Hoopy frood
Joined: Nov 2003
Posts: 2,327 |
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.
New username: hixxy
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
Absolutely correct, and I still see no way the scheme could be implemented without breaking compatability. - 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?
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 349
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 349 |
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..
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
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
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
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.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 349
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 349 |
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.
|
|
|
|
|