Ideas from Ixokai/Color System

From Museon Softcode Package

The skin system can, at its most basic level, allow people to do things like override the header in one place and it goes everywhere else, and make various other settings. But in this basic level, we're basically having them hardcode color into the UI.

That's how things are normally done, but it's got some problems:

1. Some people like black text on white background, heathens that they are. Or green backgrounds.
2. Some people have visual difficulty reading certain colors; high black, dark blue, etc.
3. Some people just might not like as *much* color as the MU Admin does.

The only solution to these for people is to go !ANSI, but that sort of blows as a solution. It is an "all or nothing" that makes people who don't mind-- and even prefer-- ANSI go to neutral blandness because the MUSH admin made some decisions about certain colors that don't work. (Yes, some clients let you adjust this; but it is not all clients, and not always possible, so doesn't address the core problem of the project)

I wrote a colorcfg system elseMU to solve this. Basically, the softcode on this mush was forbidden from ever outputting ansi codes directly. Forbidden! :) Instead of calling [ansi(hr,My Header Here)], it would call [colorcfg(%#,header,My Header Here)].

The colorcfg() function took three arguments; the enactor, a text class, and the text.

The function then basically:

1. Check if the user has selected an override color for that text class, and use that if so.
2. Check if the user has selected a color scheme, and if so, use the default color for that text class in that scheme
3. Use the default color for that text class in the default scheme.

Code-wise, it was basically (from memory):

[ansi(default(%0/_c.%1,xget(#colordb,c.[default(%0/_color_scheme,default)].%1),%2)]

Now, on our ColorDB, we would define a number of schemes. I had one called "fire", one called "blue_beauty", one called "earthy", and so forth. THe MUSH would also have a "Default" one. The ColorDB looked like:

&c.fire.header colordb=hr
&c.fire.exit_name colordb=n
&c.fire.exit_frame colordb=hr
&c.fire.exit_link colordb=hy

Those are some examples of text classes; the exit_name, exit_Frame, and exit_link were used by the room parent to colorize each exit name as "North (N)", with North being name, ( and ) being the frame, and N being the link.

If the user didn't like the bright yellow link? They could +colorcfg exit link=high white (which would translate to hw). It would then &_c.exit_link %#=hw

This worked really well. The one downside is that it -is- slightly annoying to code for, we admit. Because the [colorcfg(...)] calls are more verbose then just throwing out ANSI codes.