Quote: The whole idea of allowing the server to specify actual colours is a bit wrong-headed, IMHO.
Of course, the 256-colour protocol suffers from the same problem. What happens if you want a different 256 colours?
Hmm. No reason why you couldn't allow someone to edit it. I assumed that the '.vim' files where mappings. Looks like they are actually used to set the clients colors, based off the default palette. Presumably, you would normally want to leave the grey scale part and the normal ANSI part at defaults (something Mushclient already violates. lol) This is likely a standard palette. I.e., application that export/import 256 color palettes (.pal files) would use the same format for storing their versions.
Note: There seem to be several versions of .pal, though I assume they differ only in what additional things they added, which may not be recognized in other applications. The two most common are probably the IBM spec (search for "Palette File Format"):
http://www.saettler.com/RIFFMCI/riffmci.html
and the one currently in use with Paintshop Pro, the older versions used the same '.pal' type, but now it uses a '.psppalette' file. No idea what the specs on that are.
Its probably not necessary to add support of something like a % of color scale, since while some high def image files do store colors with scales *significantly* higher than 24-bit, but there isn't a display in existence that actually reproduces that level of granularity (yet anyway). The decision to use % in some things like POVRay came from the fact that they where making it possible to generate data "for" those systems that can print or analyze stuff with like 64-bit color or something. lol Scaling an RGB color which has only half the accuracy to something like that causes you to end up with incorrect colors. This is even more true if you try to scale "down" to 8-bit, then back up to some absurd 64-bit standard or something. It just didn't work real well. It was better to provide the original script source and an accurate color table (to within 6 decimal places). Somehow I don't thing we quite need that. lol
Though, it would be nice if we could have an import capability to add additional colors to the color picker list. At least one Linux/Unix based list of web colors I found included about 4-5 times as many, since it allowed for things like "Light Rose 2", "Light Rose", "Dark Rose 2" and "Dark Rose", instead of just "Rose", or even Light and Dark versions only. I.e., there was a scale of at least 4-5 versions of each color, so you could pick a lighter or darker version of them. Its just a thought.
As for IMP. Noticed after posting that they lacked some clear information on some things (even less clear than MXP), so tried to go on their forums. They are all locked, which is when I realized it was entirely a dead system. Forgot to post that here. But I tend to agree with some people discussing it on TMS when talking about client design. There are seriously screwy things in MXP.
Now, with ANSI.. The most common way to handle bad data, in everything I have ever used that had ANSI support, is to just throw out any codes that are invalid. And, I have *never* seen any instance of anyone using multiple codes in each sequence. Most of the books I ever read on the subject, while never explicit about it, seemed to imply that you have to set foreground and background *independently*. I have no idea if that is in fact the case or not, but I would be surprised if someplace there wasn't something saying so. |