mIRC Home    About    Download    Register    News    Help

Print Thread
Color control code handling #80829 27/04/04 06:45 AM
Joined: Jan 2003
Posts: 52
L
lordares Offline OP
Babel fish
OP Offline
Babel fish
L
Joined: Jan 2003
Posts: 52
I'm trying to [K08]Yellow[K04]Red[KEND]Yellow
Using just a [K] will do the trick unless a Number follows the code, which is the problem I'm having, which cannot be worked around by means of scripts. (Im writing a C bot to show colors etc.. not important...)

Using [O] may end other control codes
Using [K99] will put the color back to the color of the line, but it does not RESUME the previous [K08] like it should.

I think I'm asking for nested control codes?




Re: Color control code handling #80830 27/04/04 06:53 AM
Joined: Aug 2003
Posts: 325
W
Wolfie Offline
Fjord artisan
Offline
Fjord artisan
W
Joined: Aug 2003
Posts: 325
So like...

[K0,1]Hello [K8,1]freak[P], how are you today?

Would produce a line that is white on black, with the name(word) freak being yellow on black?
(I used [P] as meaning [P]revious color assignment, in place of [K0,1])

If so, it sounds like a kewl idea, but what about the javas, other irc clients, etc, that don't recognize the concept?

Re: Color control code handling #80831 27/04/04 02:30 PM
Joined: Jan 2003
Posts: 52
L
lordares Offline OP
Babel fish
OP Offline
Babel fish
L
Joined: Jan 2003
Posts: 52
Precisely.

Good point..but being that they are mIRC color codes, who cares, it's not our problem imo.

Re: Color control code handling #80832 27/04/04 04:28 PM
Joined: Aug 2003
Posts: 325
W
Wolfie Offline
Fjord artisan
Offline
Fjord artisan
W
Joined: Aug 2003
Posts: 325
Other IRC clients support the color codes too, and would look rather bullyish to implement a new code that would make other clients incompatible, especially those clients that are still popular but no longer being updated. (I can think of one specifically but I won't mention it's name). Don't get me wrong, I'm in favor of the concept of 'backing up' to a previous text color, just like using [R] turns on reverse and then using [R] again turns it off, and the coloring before it was turned on is still in effect. (Actually is still in effect while in reversed text, you can highlight the text while it's on the screen and see what I mean).

Just why make complications like if mIRC is the only irc client available and like if no one will have problems if they prefer to use an older version of mIRC?

Re: Color control code handling #80833 27/04/04 04:51 PM
Joined: Jan 2003
Posts: 52
L
lordares Offline OP
Babel fish
OP Offline
Babel fish
L
Joined: Jan 2003
Posts: 52
K, then it is just a matter of Khaled making his code REMEMBER previous codes and to automatically go back to the previous codes..
This works in html and UBB code....
<font color=yellow>Yellow<font color=blue>Blue</font>Yellow</font>
Yellow[color:blue]BlueYellow[/color]

It seems that currently Khaled ignores old codes and does not nest them as they should be...

comments?


Re: Color control code handling #80834 27/04/04 05:19 PM
Joined: Aug 2003
Posts: 325
W
Wolfie Offline
Fjord artisan
Offline
Fjord artisan
W
Joined: Aug 2003
Posts: 325
Still incompatible with other clients.

Taking your example, all other clients would fall to their default colors.

examples: *and lets say you have it set up to use green as the default text color*
mIRC v6.2 (maybe?)
AutoGreeting: [color:blue]Welcome [color:red]LeDork to #Stupid[/color][/color]

Previous versions (or other clients):
AutoGreeting: Welcome LeDork to #Stupid

I guess a good compromise would be to design/setup a new standard, have it recognized for a few months to a year (ie, v6.2 would work properly with it) but not have it actively available for people to easily use (until say, v9.0 (okokok 6.3)), so that other clients have a chance to implement the updates and older clients might have someone develop a plugin to have it work properly.

This would also allow for a certain amount of backwards compatibility.


Re: Color control code handling #80835 27/04/04 05:31 PM
Joined: Jan 2003
Posts: 52
L
lordares Offline OP
Babel fish
OP Offline
Babel fish
L
Joined: Jan 2003
Posts: 52
You're not following.

Changing this would not affect other clients at all.
There is no 'RFC' for mIRC color codes.
I'm sure some other clients assumed that they were nested and made nesting support with the colors... thats not our problem...
I'm just asking that Khaled makes color codes nested internally.. it would not affect any other clients, because there isn't *any* standard as there is..

Re: Color control code handling #80836 27/04/04 05:33 PM
Joined: Aug 2003
Posts: 325
W
Wolfie Offline
Fjord artisan
Offline
Fjord artisan
W
Joined: Aug 2003
Posts: 325
I am following.

You're missing my point on what I just posted.

Trust me on this.

First, consider this.. There are many scripts and clients out there that recognize [O] as being to turn all color codes, reverse, bold and underline OFF (I think I covered all of them) - to make it simply revert to the last text setup BEFORE the [O] would cause those scripts to look wrong, and those who use it for the feature of backing up one text change wouldn't show up right on older mirc's, other clients.

What's the point of sending out the color codes for others to see if it's not going to show up properly? Therefore, another method would have to be used, and putting that new method out there, for java developers, other IRC clients, et al, would let others have the chance to adapt first before truly encountering it.

If you stop looking at it from your perspective of how it would look for you, and instead how your 'wonderfully colored schemed text' would appear to others, you would see how a gradual (albeit rapid) adaption would be a benefit to everyone involved.

Look at it from the point of view of HTML. If you create a website and develop/include codes that only work with one web browser, without advance notification of what it does, then what you would have would be a limited number of site visitors who could properly view your site. It's been my experience that new HTML standards are put out there and then web browsers are updated to include support for those new versions. (Exception being MSIE, as they tend to make features specifically for IE, then about of the internet community can't see those pages correctly, which only goes to prove my point).

Now, calm down some and stop thinking that I'm not getting your point. I think the idea itself, as a whole, is great, because there have been times when I would have loved to use it, as it would make coding way easier. Just you have to consider other people too who may not upgrade the same instant you do when you start using the code and people think you have an awful concept for colors.
grin

Re: Color control code handling #80837 28/04/04 03:29 AM
Joined: Dec 2002
Posts: 1,527
L
landonsandor Offline
Hoopy frood
Offline
Hoopy frood
L
Joined: Dec 2002
Posts: 1,527
Other IRC clients support the color codes too, and would look rather bullyish to implement a new code that would make other clients incompatible, especially those clients that are still popular but no longer being updated.

See, but there's an arguement for this. Pirch has used italics and script font (basically a symbol font that can be (de)activated via CTRL + S) but not reverse (IIRC) and has for YEARS now and mirc's not compatible with either of those two. When the script font is used mirc translates it into ASCII equivalents from your current font (at least it did). Italics (IIRC) showed a CTRL block (you know the [] looking square) instead of italicising them. Pirch ahs had these for eyars now (granted has not been unpdated in just as long).

According to your arguement (ok, your statement if you prefer that word smile that I quoted above), they never should have been implemented because of imcompatibility issues. They were added anyhow and I believe is aprt of the reason why italics are soo wanted..... because an outdated very old client has it and has for ages. We cant hold back an option JUST because it is NOT supported by other clients. Mirc should remain its own client and not be influenced by what another client may or may not support. After all, correct me if Im wrong, but Pirch also had a different fast send for the DCC than mirc did and using the same statement above, never should have done it because of incompatibility issues.

Before people start saying use Pirch, I have and like mirc better hence it being my client of choice BUT it does have things mirc doesnt and therefor the compatibility issue doesnt hold water (nearly as much)


Those who fail history are doomed to repeat it
Re: Color control code handling #80838 28/04/04 03:41 AM
Joined: Aug 2003
Posts: 325
W
Wolfie Offline
Fjord artisan
Offline
Fjord artisan
W
Joined: Aug 2003
Posts: 325
Using your POV of the matter, then why doesn't mIRC just create it's own entire life in the IRC world, where if you aren't using mIRC, then half of what you see from mIRC users is pure crap and unreadable because mIRC has all these wonderful features that no one else supports.

It's been my experience that [R] on mIRC is [I] on the other client you mentioned. Yeah I wouldn't mind having an [I]nverse, to be honest, just so long as others can see it as I meant for it to be seen. I think that other client simply made a mistake in what the code was meant to be used for (ie, maybe was said as being [I]nverse, and seeing the I made the idea of it being Italicized, only to be mistaken). Given the choice, I prefer [R]everse over [I]talics. But would be nice to have both. Just I think a friendly cooperative creation of new codes would create better support for the features and possibly even more features.
grin

And I wouldn't call this an arguement.. Because great discussions sometimes yield great ideas - maybe Khaled will try to make use of this thread to set up new standards for the future and they might become widely used and supported, making IRC chats even more text oriented and text-playful smile

Re: Color control code handling #80839 28/04/04 03:50 AM
Joined: Dec 2002
Posts: 1,527
L
landonsandor Offline
Hoopy frood
Offline
Hoopy frood
L
Joined: Dec 2002
Posts: 1,527
ok, I understand that mirc needs to remain compatible, but it seems to me that mirc is being held back becuse of other clients yet they're moving forward in ways mirc isnt. While I cant give you a program or feature, if you go over all the posts comparing mirc to other programs, you'll see mirc doesnt have things that others do (and people want) and things it has that others dont (which is why SOME users remain with mirc over their client of choice). Honestly, some of the problem is that programs (like IRCDs) cant agree on what should be implemented across the board and thus there will never be an standard for programs to use (as a base). Im in no way suggesting limiting options, Im simply suggesting that if developers tried to work together (as a whole) maybe some of the features we all want would be implemented quicker because there would be some agreement over implementation of ideas


Those who fail history are doomed to repeat it
Re: Color control code handling #80840 28/04/04 05:08 AM
Joined: Aug 2003
Posts: 325
W
Wolfie Offline
Fjord artisan
Offline
Fjord artisan
W
Joined: Aug 2003
Posts: 325
Which is a point that I made.. And said that a good way to 'implement' the feature is to make it a receivable feature first, and then implement it as a usuable feature seconds. Because then as future releases of mIRC are made, the ones after 6.14 but before the one that allows you to actively/purposely use the new features, they would be compatible with the new format/function/feature/code, and other IRC clients would be able to adapt to include it in their client base too, so that everyone enjoys it at once or about the same time, instead of being told that what you are doing looks like trash, and so you stop trying to use it because you don't want people to not understand what you are saying/doing.

I think it'd be nice if the new features were simply DLL's that got added and would add the new features (ie, color codes, etc)...

grin

Re: Color control code handling #80841 28/04/04 05:28 AM
Joined: Dec 2002
Posts: 1,527
L
landonsandor Offline
Hoopy frood
Offline
Hoopy frood
L
Joined: Dec 2002
Posts: 1,527
You're right you did. Musta missed that the first time around. Sound reasonable to me and would also allow for other clients to choose to support it or not tho after a time we'd be back in the same boat cause then mirc would have things other clients couldnt even understand and we'd have the compatibility issue all over again after a while. Would actually look the same way IRCds are right now; some use feature "X" and other IRCDs dont and we (the mirc userbase) want mirc to support many different ones (which mirc I feel does a good job of right now) and not all of them can be implemented easily (not knowing a thing about coding) or could cuase confusing in mirc or whatever (thought not quite flushed out the way I had imagined it would lol)


Those who fail history are doomed to repeat it
Re: Color control code handling #80842 28/04/04 07:31 AM
Joined: Aug 2003
Posts: 325
W
Wolfie Offline
Fjord artisan
Offline
Fjord artisan
W
Joined: Aug 2003
Posts: 325
Well if the other clients decide to not support the feature, then that's their fault. Giving reasonable notice of a feature that will be included, and trying to work on a joint/unified solution so that all can benefit from it is a good approach, and if the other clients refuse to support it, then if it's something that becomes overly popular, they will start losing popularity while mIRC simply increases in it. To be honest, with the exception of javas (which are iffy, at beast), pirch (eh, ok I guess) and obviously mIRC, I don't know of any other clients. It's to my knowledge that mIRC is by far the most used non-java client. (But add in javas on the net, and the comparison changes greatly). I know there are others out there, and probably some very competitive to mIRC, but I haven't really looked, because mIRC keeps me happy.
grin

Re: Color control code handling #80843 28/04/04 07:42 AM
Joined: Dec 2002
Posts: 1,527
L
landonsandor Offline
Hoopy frood
Offline
Hoopy frood
L
Joined: Dec 2002
Posts: 1,527
(non insulting rant to follow)

yes but it gets back to compatibility tho. If mirc has something they're not compatible with, the conversation/arguments becomes circular in that it never ends. We give them a chance, they dont add said option, mirc is no longer "in par" with the rest of them and thus not compatible with them. The arguement of mirc should stay compatible locks mirc into getting only that which OTHER clients would get and thus playing second fiddle (on SOEME things) to other programs who ahve said options but possible developed differently. Personally I honestly think of it like this ............. saying mirc should 1) set the example 2) be as compatable as it can with others when they arent compatible with mirc is rediculous............. since we KNOW a joint venture will most likely NEVER happen (I illustrate the vast differences in IRCds and their functions and which modes should be added into the channel central) then mirc is stuck. It needs to be original not a copycat of all the others. Ive seen arguments for mirc to have one thing or another that said other program has and a lot of the arguements have been "no because others cant support it". So ok, a good feature doesnt get added because smoe other program out there doesnt support it. Isnt that kind of insane?? This type of argument/debate will continue tho until the IRC clients of the world at least talk to each other more than the IRCd coders of the world have and decide on some things. I know people dont agree with me and will point out why and that's fine, I just dont think mirc should worried about other client's when they're OBVIOUSLY not worried about mirc based off of features both external (meaning others see it) and internal


Those who fail history are doomed to repeat it
Re: Color control code handling #80844 28/04/04 07:56 AM
Joined: Aug 2003
Posts: 325
W
Wolfie Offline
Fjord artisan
Offline
Fjord artisan
W
Joined: Aug 2003
Posts: 325
*makes mental note to actually READ that entire ranting later, after getting some sleep*

Glancing at the first part of what you said... It's only playing second fiddle if you say, "Hey, I'm going to implement this, here's how you can support it.. Oh, not going to support it? Ok then I won't implement it.."

Being a pioneer is, "I'm going to implement this, here's how you can support it if you want to, but if not, that's your choice" and then to add it in anyway.

I suppose an alternative would be to have an option to 'enable/disable' the extended features. Turn it on and you get to make use of it. Turn it off, and then you see things as everyone else would.

*makes mental reminder to read the respectful ranting later*

Re: Color control code handling #80845 28/04/04 12:23 PM
Joined: Jun 2003
Posts: 384
D
DekuHaze Offline
Fjord artisan
Offline
Fjord artisan
D
Joined: Jun 2003
Posts: 384
I think you're both right. However, my view is this:

I think Khaled should make available his methods when implementing new "pioneering" features. Now, I'm not saying he should open source mIRC (although that would be nice) or the new implementations, but I think compatibility issues would be lessoned if a technical overview detailing how the features worked were made available. Sadly, I realise this would probably never happen. But I think it should.

Re: Color control code handling #80846 28/04/04 06:46 PM
Joined: Aug 2003
Posts: 325
W
Wolfie Offline
Fjord artisan
Offline
Fjord artisan
W
Joined: Aug 2003
Posts: 325
So your view is basically the same as ours.
grin

Personally I think that a lot of clients could be better developed if they were to have a multi-level development. Namely, an oper source IRC integration where-as new commands/features/communications with the various IRC's would be coded and then from there, programs, such as mIRC, attach onto it to add additional features and making use of the "gateway" in how it displays the received data, etc. That way, if a client wishes to add a new feature, they submit the request to the "gateway" coders who send back a code (equiv to the [K] or [O] controls) where it would be an indication that it's a named feature/function (but by a reference number, perhaps), similar to ANSI codes. And the client programs would automatically be backwards compatible in that there could be a design that would allow the client to know how much of the data to ignore if it's not compatible.

Of course, it is probably more complex than that, I'm sure. But hey, wouldn't it be nice if there were codes (1 byte each): [esc][len-of-feature(0-Z)][feature#/type][data][ack]
Mind you, this would be only for client designed features, whereas [i][feature][code x4] would always be fixed so if the feature isn't supported in that version, it skips 5 additional characters, but the [i]'s would be new implementations by those who develop the gateway, thus new color schemes, etc, could be added to [i], where with a limited number of features that could be added, it would be reviewed more and therefore incorporate a higher rate of acceptance and compatibility. the [esc] method would be more loosely controlled, where the "feature name" may include a 3 digit code that backreferences the client that came up with the function, and then that client could always make a new function at anytime and know that other clients will simply ignore their function if they don't support it.

Ok I'm done dreaming in a semi-perfect world now.