Allow custom colours in colour picker

Sorry? You lost me. But, I will try to parse this. Using the Hex code is **not** the same as being able to remember that "ForestGreen3" is three shades darker/lighter (don't remember which at the moment) than "ForestGreen". Maybe you can remember what a dozen codes you are using, most of them really similar *actually* look like, I can't. Names help. And I forgot about "AdjustColour", but that, as I mention above, only works if you "directly" derive the color from an existing one. There are gaps, even without the extra colors, in the default codes, which means some colors don't have analogs in the list of names, even for a specific one. Remember, those names and colors are from a list of "web safe" colors, not a comprehensive list of **actual** colors people use for every day things. Some colors are not included in the safe set, even if they have names that can be associated with them, because, back when the "web safe" versions where developed, browsers couldn't be guarantied to display ones that are not in the "safe" list properly. Are you suggesting that Mushclient has to conform to that silly standard?



Yeah, I forgot about the color adjustment function. Its still "not" as nice as being able to give a color a logical name and permanently add that into the main set I use. It still means that if you want "MyBrown", you have to remember/find the bloody definition for that in your code, and not everyone is going to place that in a variable at the start of their scripts, any more than I tend to. I should have, but I didn't/don't. Its not a major issue, just a mild annoyance when trying to create a sort of "theme" for a set of functions, like where my druid potion plugin used all soft greens. Those colors I used are "not" in the existing list, some are not even derivable from the list and all of them would have required extra code anyway, no matter if I derived them from the existing colors or not. I just like having a name to go with the color I am using, it makes things less confusing when you go back a month later and try to add something, but can't remember "why" you used a particular color some place. lol

Hmm. Ok, that is a point. Once more clients are subject the goofiness of past technologies. lol One solution is to store the extended color set seperately, and marked with an Asterix or something in the list, to indicate that its not currently supported in MXP, but is available to scripters. Kind of goofy, but it solves the problem of creating a client war (though imho, we need to shake things up some I think, if the current slump of, "Well, mine does everything yours does, except it goes boop, instead of beep.") But yeah, for convenience sake to someone trying to use color, more names would be nice, for MXP, leave it as is. That just means that the check box becomes, "Display only MXP supported colors.", instead of, "Display only main set." Its not like, if you allowed naming of user customized colors, that those would be supported in MXP either, it just makes it easier to use the name given to them, rather than trying to remember the hex codes.

Yes. And setting them up that way works fine, if a) you are not using a code block in which those entities won't be translated and b) you are changing something in a new plugin, instead of coding a completely different one. The later is less of an issue of course, since you can just look at the original, if you remember which one they are used in. The former... Just because you can do something that way doesn't mean its as convenient as having it available more directly.

Lets put it another way. Lets say someone did want to extend MXP and extra names where supported. Which makes more sense, trying to code a plugin to handle all the new colors? Making a plugin that does something like:

World.AssignColour "&hblah", "MudColor1"
...
World.SaveColorSet
World.UnloadPlugin "_self_"

Mind you, I don't think Mushclient can currently let a plugin unload itself, but that is more of an issue of setting a flag on the plugin, waiting until it exits its script, then unloading the plugin *after*. Same fix could have been employed to solve the issue with triggers, timers, etc. deleting themselves too. Point is, a mud that wanted to use the extra names could supply a run-once type plugin to set the extended colors for that world. Right now, if someone made a new mud and extended the set, you would either have the hardcode more into the application or make a plugin to intercept all the new names and replace them with the hex codes. Sure, the mud could convert the names internally, but that takes up room (and) time on the server end, which I wouldn't want to do myself, if the client could handle it directly.

Lets just say its a thought. Something we might consider as an advantage to people that wanted to use it, if we wanted to add support at some point to handle it. Heck, just adding the support isn't going to hurt anything anyway, since it just means people could name their own colors. Servers wouldn't know the difference, until/unless someone using MXP decided to add more colors to their end, based on the existence of the support for it. But, it does have an immediate benefit to scripting, which element definitions don't. Its global to the world, including its master script, not local to the plugin. Sometimes that may be useful to have right?

I don't see a huge difference between making some sort of "import more names into the colour picker", and simply having an include file that you, as a plugin writer, could use that lists extra colours.

In fact, as a plugin author you are better off with a standard include file, rather than relying upon your plugin users importing your extra names.

As for allowing plugins to delete themselves, I suppose you could add code to do that. But sometimes I think that when you have to put huge amounts of effort into solving a problem (like a plugin or trigger not being able to delete itself), then you just need to rethink how you are doing things.

A case in point, pardon the pun, is the thread about Lua "case" statements. Whilst you can simulate them, you don't really need them anyway, because the language provides ways of doing similar things, built in (like tables).

The difference is that having an import "only" effects the plugins, not MXP, should someone, including Zugg, decide to increase the number of colors. Just because there are ways to do things doesn't mean that using those ways don't come with unintended costs in the long term. I am merely suggesting that a more direct method can provide more future options. Using the existing system.. Not so much. Its just another case of, "How do you see/edit triggers in plugins?", to which the only answer is, "You can't." Why not? Well, in that case because its quite complex to support it. In this case, its not so complicated, so why not support it? If no one uses it, so be it, but at least its there. That is the best argument I can give for it at this point. Its just a possible idea that would imho, work better "in" the client, rather as some non-flexible include that only works for plugins, isn't accessable to anyone through the client itself, can create naming conflicts within plugins dealing with elements, and any number of other possible issues. I just don't personally think using indirect methods to support it makes sense in this case. But that is just my opinion.

That would be much like when mccp went from version 1 to version 2. A change in a protocol is fixed within the next update. Adding something on top of MXP is not going with a specification, it's an attempt to make a new specification. To do that, there is a nice page for that


Also, Entities are usable in MXP, which would help to add extra colours for a particular mud, or to allow older browsers to keep up with any advances in MXP. Also, keep in mind that it's been four years since MXP specifications have changed at all, and the forums link on the MXP page is down. This may change, however, now that Zugg has a new client out.

This talk about colours and MXP entities is confusing me. Colour names aren't entities, they are arguments to an element attribute. For example:



The colour name "cornsilk" is an argument to the color attribute of the font tag. I don't see where entity names come into it.

In fact, if I was writing an MXP-enabled server today, I would not use colour names, but stick to colour codes (eg. #EFABDC) because at least I know that the code will definitely be supported.

Even if I add extra names into MUSHclient right now, 99% of people will have an older version, so MUD developers can't assume they can use the new fancy names.

<!ENTITY mygreen "#228B22">
can then be used in MXP to use that colour whenever I want.
<C FORE=&mygreen;>this would be green</C>

Well that makes sense. So basically you could use any names you like right now.

Yep. Just need to define it once at connection, and you're set for the whole session. Same as when you use entities in the .XML files for plugins. You can also make sure that the colours are what you expect that way instead of wondering if someone has set that word to a colour you hadn't expected.

Only if someone uses a descriptive name. I don't know about you, but I can't visualize what every color looks like from the hex code. lol

And now, we have an argument of, "Well, lets just use one kind of element for MXP, one kind for plugins, not have support for the extended colors in the client for setting anything else..." I think you are missing the point I am trying to make slightly. You are right, its possible to do it other ways. But those don't provide colors universal to "every" place you use them, even if you wanted them to, and you can't "see" what the color actually is without hand copying the element definitions into the color picker anyway, where you can't store them for future use, because it doesn't support doing that. Its not about *if* methods exist to do it, its about how user friendly those methods are to someone who just wants to use a color, but doesn't understand how MXP, plugins, etc. store them. I just think its silly to not have user definable colors, for ones they use so often in their own work that they need to have them handy all the time, without having 3 different ways to deal with them. After all, if you created an entity in a main world file, then the moment you save it again its going to save the "actual" value from the internals, not the entity, so you lose the information that an include would have given you in that case anyway. So, 3 different ways, 4 if you consider that the main script may also need to use them, and that has access to neither the plugins include or any entity you attempted to add to the main world file.

Lets just leave MXP out of this entirely and simply state that there is, right now, no single shared source for storing information about custom colors, which is easily accessible to "every" part of the client that might want to use them. Only plugins can take advantage of the use of XML elements in this case, the client itself, and its main script can't, nor, as I said, is there any "simple" way to visually see what the heck the colors actually are, without going into the color picker anyway (or using some other indirect method, like sending a colournote to the output with that color in it).

Are we still talking about xterm support? I'm having a fair amount of difficulty figuring out what exactly is being proposed/debated here...

Well, one version of entities is client side, which will work on anything you chose to do with the client. The other is server side, so if you run a mud, you can control that however you want from the server. I fail to see how these could possibly interfere with one another, since unless you are playing on a mud that you code for, you don't control everything. So there is already a way to use the a particular colour universal to "every" place that you use them.


Press alt-8. Click on a colour. Click on "Other colour", click anywhere in the colour selector on the right. See the colour you want. Click "ok". Rename colour. If that's too difficult for most people to do, then I must be as smart as Stephen Hawking.


The custom colours can be used by scripts, ColourNote, they are easily accessable from the trigger menu, and can be put into plugins. I personally would rather convert the colours into hex using the colour picker (and you can just click on the values for MXP, VB, Jscript, and Lua) and copying the value into plugins I distribute so that I am not relying on any colours.

Umm. No actually. The issue at hand came up in the discussion though. Basically, to summerize, right now if you want to define a custom color, with a name, you need to do:

1. Assign it to a variable.
2. Assign it to an entity.
3. Just use the colors hex code.

#1 and #2 work for inclusion in plugins, but not in the main world, dialogs, etc..

#1 works with script, even the main one, but only in context of the script that loads it (mind you, you could set one up for Lua as an includable Lua file, but..)

#3 works in all four contexts, but is ambiguous.

None of them give you a clear visual reference for the color if you want to see what it actually is.

My proposal is to change the color picker, so that once you have a color you like, you can "name" it, along with a check box to hide the user defined ones, if you wanted to see only the standard MXP colors. This also could mean that you could export a list of them, which could be imported to another world.

The new color is accessible as a named color when using *any* feature that uses colors. Instead of having to remember the code, you just use the name for it, whether you are creating a new trigger or using colournote, and regardless of which of the four places you might use those, (those being, again, the world's own triggers, the main script, a plugin's triggers "or" a plugin's script). Current methods only work in specific contexts, so cannot be applied to all cases, and they do not provide a way to "see" what the color actually is, without displaying something in the output window that uses it.

First I just want to point out that if you have a valid colour definition on the clipboard (eg. #40E0D0) then the "paste" button in the colour picker is active, and clicking it pastes that colour in, so you can see it.

---

OK - let's work this one through. As I read it, the basic proposal is to allow extra "custom" (named) colours to be added to the colour picker? Is that right?

Now, the current implementation of the colour names in MUSHclient is that they are a fixed client-wide table, which is populated from constants at client start-up.

This exact same table (ie. the only table) is used for the following things:

• The colour picker list of colours
  
• Script functions: ColourNameToRGB, ColourNote, ColourTell, PickColour, NoteColourName, RGBColourToName, NotepadColour, InfoColour
  
• It is shown with the script function: Debug ("colours")
  
• It is used when parsing MXP text and background colours

Now is the proposal:

• To import extra names into the colour picker only? In which case the table would need to split into two tables. One for the colour picker, and one for the other functions.
  
• To import extra names into the world colour name space? In which case the table would need to split into two tables. One for the this world, and one for the other worlds.
  
• To modify the global colour table, in which case it would modify the behaviour of all open worlds.
  
• To affect the colour picker but not the other script functions? Or the colour picker and the script functions, but not MXP?

How would the extra names/colour codes be imported?

• Manually by entering into the colour picker? (one by one by clicking on a button)?
  
• From a list (eg. on the clipboard)?
  
• From a file?
  
• From a script command (eg. AddCustomColour (name, RGB))?

How would the extra colours be remembered, if at all?

• Would they be saved as part of the world file?
  
• Would they be saved in global configuration?
  
• Would they be saved to another file somewhere?

I can see a whole heap of problems here. If you simply modify the global colour space, then what I warned about before is likely to happen. You would develop (say) plugins using one of your new colours, and then distribute it, forgetting that "lightpalegreen" was one of your colours, and not a standard one, and the script wouldn't work properly.

If the colours aren't saved they will work today but not tomorrow.

If they are saved in a world file, but modify the global colour picker, its behaviour will change depending on whether that world is open or not.

Two possibilities would be in the world, or in global. And it should effect everything, except maybe MXP. But you have a valid point about plugins. Its not like we parse the script looking to things like the colournote command and see if the color is one that is in the list. We could look for ones in triggers and add XML for them, warn if they are missing, but script use of them.. becomes a problem, since the only realistic way to do it would be to check the code to see "if" all colors used are valid and export the non-standard ones either as an addon to the script code or as XML, so they auto-import when loaded some place else. Neither of those is likely to happen. :( The only other option is to do what we have done in 1-2 cases and, "leave it to the plugin developer to make sure X is done right." Just as the plugin developer needs to make sure they "export" all triggers needed for the plugin and copy all script related to its operation into the final result, they would have to make sure to export the correct "colors" to the plugin for it to work right.

I really hadn't thought about that issue.

You haven't said how the colours get imported in the first place, nor where they get saved.

Ok. Imported - through a function for assigning a name to a color, or as an option in the color dialog where you put in a name and click, "save this color". As for other import/export issues, same as with exporting triggers, timers, etc. from a world file, or importing them. And, like those, some people might want to include a "global" set for all worlds. Not that I see a lot of people doing that now with the current global options.

Although I'd be quite happy about being able to import a custom colour list, I see one main problem aside from trying to figure out where they are stored. What happens if I call a colour that does not exist in my list? Let's say, for example, I have loaded one of Shadowfyr's scripts which has ColourNote( "cornsilk", "black", "Plugin loaded" ) and I don't have "cornsilk" in my custom colours? Does it just go to the default script colours like it does now?

Actually, after a bit of testing, I notice that you can't even call the custom colours by name in ColourNote. It just fails out to the default colour for whichever part you have wrong.


I don't see how the hex code is ambiguous. It leaves the least amount of room for error, since it is directly declaring the colour, rather than relying on anything that can be affected by the end user.

Its ambiguous from the standpoint of someone trying to remember what the color looks like. Like I said, I don't know about you, but I don't generally go into paint stores and tell them, "I want a can of &h55FE23." In some places, even knowing the convention "they" use for defining colors by code will get you blank stares too. I have no idea what that color looks like, except in the most vague sense. If it had a name, I could visualize the color based on the name I gave it.

I used to work in a paint store... names don't help often. Dutch Boy had a colour called "Outer Space" which was a dark greyish brown instead of black like everyone expected.

As for the colour #55FE23, it's obviously a green of some sort. Probably bright since it has some red in it, which brings it closer to yellow. Aside from that, I would love to have a way to paste a colour directly into the colour picker. Instead, I have to slide the bars back and forth. I tried double checking.

Going through the colour picker list, it's not always obvious what a colour is from the name either. I'd expect "papayawhip" to be more orange. And I have no clue what a "burlywood" is. "Darkgray" is also lighter than "gray" for some odd reason, and "dimgray" is darker than both of them.

Yes you can, how are you going about it?





As I said before, if you have a colour name or code on the clipboard, the "paste" button becomes active. Clicking that pastes that colour into the picker, and it becomes the current colour. These work:


brown
#A52A2A
&h2A2AA5
0x2A2AA5
2763429


All are variations on the way "brown" can be represented, and if (alone) on the clipboard, all will cause the Paste button to activate, and allow the direct pasting of the colour in.

Or do you mean the custom colours, as in the 16 colours in the custom colour dialog?

Those are world-specific, so the same argument applies to those, if you started adding them to the MXP colour name space.

Also, there is nothing stopping you giving them the same names (eg. colour1, colour1, colour1).

You know you can copy the colour codes from any active colour swatch (eg. in the custom colour dialog) by right-clicking on it and selecting Copy.

If you wanted to use one of the 16 custom colours in the custom colour world configuration, in a colournote, you could do it like this:

I first tried with ColourNote( "Custom1". "Custom2", "blah" ) and it didn't work, obviously. As I said, I couldn't call them by name.

Sorry about the pasting bit. I had the numbers without the pound sign in front. That doesn't activate paste.

"Use the source, Luke!".

The function GetClipboardColour handles doing that inside MUSHclient. It checks for:

• A match on the MXP colour-table lookup.
• The first 2 bytes being "&H" or "0X"
• The first 1 byte being "#"
• Whether it is a straight decimal number

For the cases of &Hxxx, 0Xxxx and #xxx it then checks for at least one hex digit following, and then does the hex to decimal conversion. After that the colour has to be in the range 0 to 0xFFFFFF.

There didn't seem to be an easy way of finding the custom colour names, short of parsing the world file, so I have added a couple of new functions to version 4.03, which lets you get and set the custom names. These are GetCustomColourName and SetCustomColourName.