Skinning Thought

I had this thought, which I think could make a big difference in how we all approach skinning in REBOL. I recently looked at Etienne's wonderful skins and noted that there were a couple aqua schemes which only differed in color. Creating the look of a skin is hard enough work, but to create it in more than one color multiplies the amount of work you have to do. Even if you have a smart image editing app that allows you to create the first one and then automate the colorization process somehow, you still have an ever increasing number of files to manage as you add color options. Since REBOL is kind enough to provide a colorize effect, why not make use of it? If we design our skins, and images, in grayscale then we have an infinite palette of colors to choose from at runtime with only one set of source files (per unique "look") to manage. Runtime colorization. This may not be a universally applicable approach but I think it could be *widely* applicable. Colorization of course is an obvious effect to apply but certainly not the only one which might be used. Imagine the possibilities if you could apply bump mapping from textures! Any thoughts? --Gregg

> Since REBOL is kind enough to provide a colorize effect, why not make use

> it? If we design our skins, and images, in grayscale then we have an > infinite palette of colors to choose from at runtime with only one set of > only one which might be used. Imagine the possibilities if you could apply > bump mapping from textures!

Hi, Gregg, Gregg Irwin wrote:

>I had this thought, which I think could make a big difference in how we all >approach skinning in REBOL. >colorization process somehow, you still have an ever increasing number of >files to manage as you add color options.

>Since REBOL is kind enough to provide a colorize effect, why not make use of >it? If we design our skins, and images, in grayscale then we have an >infinite palette of colors to choose from at runtime with only one set of >source files (per unique "look") to manage. Runtime colorization. >

>This may not be a universally applicable approach but I think it could be >*widely* applicable. > >Colorization of course is an obvious effect to apply but certainly not the >only one which might be used. Imagine the possibilities if you could apply >bump mapping from textures! >

Hi Etienne, << Images must be very well drawn. My little experience shows me that it is more difficult than I could think it to have the good images and to choose the good effects, to obtain the good result. >> Yes, creating the images is hard work. I'm not an artist, by any stretch of the imagination, so I'm always looking for ways to make things a little easier. I'll send you a little test I did using your aqua images. --Gregg

One worry I have with skins is what will happen if a script is written that uses most of View's default settings, but changes just a few of them. Now, if the user is using their own default skin, that script is going to over-ride a few of the skin's settings and the result will most likely look awful. We need to prevent this from happening in some way. On a related note, I'm having problems viewing Etienne's skins. They seem to download okay, but then nothing else happens. Looking at the do-skins-demo.r, I see the last line is... do %skins-demo/skin-select.r which seems to be the problem, as that directory and script hasn't been loaded into my Public directory and I can't access it on the site. Has it been moved or removed? Etienne? -- Carl Read

Hi Carl, << One worry I have with skins is what will happen if a script is written that uses most of View's default settings, but changes just a few of them. Now, if the user is using their own default skin, that script is going to over-ride a few of the skin's settings and the result will most likely look awful. We need to prevent this from happening in some way. >> Excellent point! Now, I have an opinion on this and I'd love to hear what others think as well. My view is this: You can't prevent it. (That's the short version. The looooong version follows.) People, especially software developers :), will munge things up in a million different ways, sometimes intentionally, sometimes accidentally. What I see as being valuable, if we can do it before REBOL explodes in a big way and UI splinter groups form, is to figure out how to make it easy to do things "the right way". Of course, we don't know what "the right way" is at this point, and there may be more than one path to Heaven (and surely many more paths to Hell). In my experience, software related and otherwise, I've come to the conclusion that most (but not all) people will do things in what they perceive to be the easiest way possible, even if they know it to be "the wrong way". The trick, then, is to make it easier to do things the right way and people will naturally follow suit. This applies to everything, not just skinning. You still won't get perfection, though, and you just have to live with that. Two polar views: 1) Be completely controlling so they have no choice. 2) Be infinitely flexible so they can do whatever they want. If you are in control, you have to provide everything they may ever want to implement. If you don't, they'll go around you to extend the system in ways you didn't intend. Being all things to all people just isn't feasible, and will make for a large, complex framework. It also stifles creativity. If you let them do anything they want, they have more work to do and you'll end up with a hodge-podge of UI idioms and styles, which is bad for users. People waste time reinventing many wheels. Moderation, it appears, is the key. Provide a clear path that covers most situations and make it easy to extend things in a way that is consistent with the core you provide. In the context of REBOL, we're not just talking about skinning static applications, which is hard enough, we're talking about skinning applications that may be highly dynamic. Not only from the perspective of configurability, but also the little things like displaying different images for a button on mouse-over or mouse-down events. For example, you could choose between three images (up, over, down) or you could choose between 1 and 3 combinations of effect facets applied to a single image. There is a distinction between style functionality and application functionality which must be addressed. Other things that require consideration are accessibility and limited/extended I/O device capabilities. Are we better off trying to define a set of guidelines about how people should implement skins, deal with global skin settings, override things locally, and that kind of thing (i.e. write a spec) or do we follow what RT has done and provide a "starting point", however extensive it may be? Etienne, Frank, and DocKimbel appear to have the most experience in this area. Maybe they could provide some advice for the rest of us. I wish I had some great answers for all these questions, but maybe we just have to struggle through some bad ideas before we find some good ones. Fortunately, we can look at the various OS approaches and learn from some of their mistakes as well as their successes. --Gregg

Hi, Carl, Carl Read wrote:

>On a related note, I'm having problems viewing Etienne's skins. They >seem to download okay, but then nothing else happens. Looking at the >been loaded into my Public directory and I can't access it on the >site. Has it been moved or removed? Etienne?

Hi Etienne, Thanks for the tips. I got it to run, and it's very nice work. The problem was I have my default REBOL words protected which tripped your script up since you modify 'layout. Hopefully the next version of Desktop will actually show error messages when they occur instead of just shutting things down. (: On 10-Oct-01, Etienne ALAURENT wrote:

> Hi, Carl, > Carl Read wrote: > and launch it manually. > Tell me if you encounter others mistakes.