mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#92409 02/08/04 12:50 AM
Joined: Aug 2004
Posts: 2
C
Bowl of petunias
OP Offline
Bowl of petunias
C
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...

#92410 02/08/04 09:41 AM
Joined: Dec 2002
Posts: 788
C
Hoopy frood
Offline
Hoopy frood
C
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.

#92411 04/08/04 01:08 AM
Joined: Apr 2004
Posts: 218
P
Fjord artisan
Offline
Fjord artisan
P
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
#92412 04/08/04 03:21 AM
Joined: Nov 2003
Posts: 257
A
Fjord artisan
Offline
Fjord artisan
A
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.

#92413 04/08/04 05:40 AM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
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.

#92414 05/08/04 12:54 PM
Joined: Jun 2004
Posts: 65
S
Babel fish
Offline
Babel fish
S
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...

#92415 05/08/04 01:24 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Quote:
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.
#92416 05/08/04 09:22 PM
Joined: Nov 2003
Posts: 257
A
Fjord artisan
Offline
Fjord artisan
A
Joined: Nov 2003
Posts: 257
lol

#92417 05/08/04 10:13 PM
Joined: Dec 2002
Posts: 349
S
Fjord artisan
Offline
Fjord artisan
S
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'?

#92418 06/08/04 12:05 AM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
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.
#92419 06/08/04 12:53 PM
Joined: Dec 2002
Posts: 349
S
Fjord artisan
Offline
Fjord artisan
S
Joined: Dec 2002
Posts: 349
That depends if they replace the current scheme or complement it.

#92420 06/08/04 01:37 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
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.
#92421 06/08/04 02:51 PM
Joined: Dec 2002
Posts: 349
S
Fjord artisan
Offline
Fjord artisan
S
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.

#92422 06/08/04 03:13 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
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.
#92423 06/08/04 11:00 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
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.

#92424 07/08/04 12:35 AM
Joined: Dec 2002
Posts: 349
S
Fjord artisan
Offline
Fjord artisan
S
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?

#92425 07/08/04 03:22 AM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Quote:
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.


Quote:
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.


Quote:
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.
#92426 07/08/04 03:59 AM
Joined: Dec 2002
Posts: 349
S
Fjord artisan
Offline
Fjord artisan
S
Joined: Dec 2002
Posts: 349
Quote:
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.

#92427 07/08/04 11:44 AM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Quote:
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.


Quote:
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'.


Quote:
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.
#92428 07/08/04 01:34 PM
Joined: Apr 2003
Posts: 701
K
Hoopy frood
Offline
Hoopy frood
K
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...

Page 1 of 2 1 2

Link Copied to Clipboard