Zugg Software :: View topic

Wizard Joined: 22 Mar 2007 Posts: 2320

And now for something completely different. Instead of asking about script problems or bugs, I'd like opinions on the direction I'm going in a package I'm developing.

This package by definition needs to store state values even when new versions of the package are loaded. I have pretty much decided the most effective way of doing this is to store the variables in the package for the main session. Now I am considering whether and how to allow users to customize the package. The case I am specifically considering is the colors for messages delivered by the package. Some of the messages, for instance, are error messages, which clearly should be highlighted. Since a user might want to be sure these message are easily distinguishable from messages from the mud, I created some simple variables containing string values for colors, which could be edited by the user. Now it occurs to me that these customized values, too, probably ought to be made safe from package upgrades. I can see a couple ways of doing this.

The variables would probably have to be stored in the main session package, like the other state values I don't want to lose. I can work up a fairly simple function to get values from it, and an alias to add or change name/color sets. But if I'm storing them there, I might as well try to use the same color set for all of my future packages. This would end up with multiple packages with similar or identical functions to access the centrally located color list. I don't know whether scoping issues might crop up with this.

A more rugged solution would be to have a separate package with a Custom Color module. The color list would still have to be kept in the main session package. To remove dependence on the Custom Color module, each package can use a function to apply the color from the Custom Color module if it is enabled, or provide a default if not. A Custom Color package might even be useful for other package developers and users. You could store and use an arbitrary number of color codes with user-defined names. Package writers could use, for example, @customColor(Error) to specify the color of error messages, and the user could customize the color for all compliant packages.

Now, after the excitement of working all this out, I sit back and wonder, is it worth it? In the first place, is it worth using customizable colors for package messages, when users could instead use triggers to alter their colors? And on the other hand, would a Custom Color package be of use to people? So--discuss. :)

Posted: Thu Nov 15, 2007 5:28 pm

I don't want to dampen any enthusiasm on this because I thought your post was well written. But I wanted to let you know that the Styles in CMUD aren't quite finished yet. I don't know if it will make it into the 2.x Public release or not, but I am planning to implement user-defined styles, which will be styles that are saved in your package and given a name. In fact, you can already see the placeholder in the Style Preferences for "User Styles".

These styles will be created and edited using a new #STYLE command. What your post made me think about is how to handle styles for custom packages. As you said, you'd want the actual value of the style stored with the user's session and not with the package itself. But you'd still want some way to initially create the style with a default value.

The name of the style will be able to be used anywhere that a current color value can be used. Also, there will be an MXP tag called STYLE that can be used to color text based upon a user-defined style (and actually, this STYLE tag is already partially implemented in the current 2.x beta).

I don't really want to hijack your thread to talk about how Styles should be handled, but I didn't want you to put in a lot of hours on something that might be handled within CMUD itself soon.

Wizard Joined: 22 Mar 2007 Posts: 2320

No need to apologize, Zugg! I remember now seeing the stub for user styles a long time ago, and thinking that might be useful someday. This is indeed the perfect solution for package display styles and user customization. The reason I started this thread was to help me figure out whether I should start putting any effort into it, and I have the answer.

I look forward to seeing user styles implemented, but I won't push to have it in 2.x. That kind of customization is icing, and the other new features of 2.x are big enough that I'd like to see people get it sooner.

Posted: Fri Nov 16, 2007 3:40 pm