[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  Allow custom colours in colour picker
Allow custom colours in colour picker

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Pages: 1 2  

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Sat 07 Apr 2007 11:13 PM (UTC)

Amended on Sat 07 Apr 2007 11:15 PM (UTC) by Shadowfyr

Message
Quote:
So when I use the hexadecimal codes or use AdjustColour for ColourNote, what exactly am I doing? Am I just wasting typing and not changing the colour displayed at all?


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?

Quote:
See: http://www.gammon.com.au/scripts/doc.php?function=AdjustColour


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
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #1 on Sat 07 Apr 2007 11:22 PM (UTC)

Amended on Sat 07 Apr 2007 11:24 PM (UTC) by Shadowfyr

Message
Quote:
I should point out also that, AFAIK, zMUD has MXP support for the exact same list of colours as MUSHclient, and I don't want to encourage a "client war" where multiple clients all support different colour names


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.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #2 on Sun 08 Apr 2007 12:10 AM (UTC)
Message
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?
[Go to top] top
Posted by Nick Gammon   Australia  (22,982 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Sun 08 Apr 2007 02:56 AM (UTC)
Message
Quote:

Heck, just adding the support isn't going to hurt anything anyway, since it just means people could name their own colors.


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).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #4 on Sun 08 Apr 2007 05:23 AM (UTC)
Message
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.
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #5 on Sun 08 Apr 2007 06:07 AM (UTC)
Message
Quote:
The difference is that having an import "only" effects the plugins, not MXP, should someone, including Zugg, decide to increase the number of colors

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
Quote:
The MUD eXtension Protocol (MXP) is an open specification for enhancing the communication between MUD servers and clients. To contribute to this specification, email zugg@zuggsoft.com or participate in the Developer's Forum on www.zuggsoft.com.


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.
It is much easier to fight for one's ideals than to live up to them.
[Go to top] top
Posted by Nick Gammon   Australia  (22,982 posts)  [Biography] bio   Forum Administrator
Date Reply #6 on Sun 08 Apr 2007 06:17 AM (UTC)
Message
This talk about colours and MXP entities is confusing me. Colour names aren't entities, they are arguments to an element attribute. For example:


<font color=cornsilk back=blue>


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #7 on Sun 08 Apr 2007 06:27 AM (UTC)

Amended on Sun 08 Apr 2007 06:30 AM (UTC) by Shaun Biggs

Message
<!ENTITY mygreen "#228B22">
can then be used in MXP to use that colour whenever I want.
<C FORE=&mygreen;>this would be green</C>
It is much easier to fight for one's ideals than to live up to them.
[Go to top] top
Posted by Nick Gammon   Australia  (22,982 posts)  [Biography] bio   Forum Administrator
Date Reply #8 on Sun 08 Apr 2007 06:47 AM (UTC)
Message
Well that makes sense. So basically you could use any names you like right now.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #9 on Sun 08 Apr 2007 07:06 AM (UTC)
Message
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.
It is much easier to fight for one's ideals than to live up to them.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #10 on Sun 08 Apr 2007 06:26 PM (UTC)
Message
Quote:
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).
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #11 on Sun 08 Apr 2007 06:51 PM (UTC)
Message
Are we still talking about xterm support? I'm having a fair amount of difficulty figuring out what exactly is being proposed/debated here...
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #12 on Sun 08 Apr 2007 08:43 PM (UTC)
Message
Quote:
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

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.

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

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.

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

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.
It is much easier to fight for one's ideals than to live up to them.
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #13 on Sun 08 Apr 2007 08:48 PM (UTC)
Message
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.
[Go to top] top
Posted by Nick Gammon   Australia  (22,982 posts)  [Biography] bio   Forum Administrator
Date Reply #14 on Sun 08 Apr 2007 09:25 PM (UTC)

Amended on Sun 08 Apr 2007 09:27 PM (UTC) by Nick Gammon

Message
Quote:

you can't "see" what the color actually is without hand copying the element definitions into the color picker


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

62,528 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]