The Campain Trail

[Richard Gaskin]

Derek Bump wrote:
>  > Elements already under complete control by Rev developers:
>  > - Window shapes using images
>  > - Button appearances using images
> 
> This is very true.  I would just like to create the button "look" only 
> once, and then have it apply to all buttons immediately.  I find this to 
> be a lot easier than create 3 different images for every button on my 
> stack.
> 
>  > - Fill and fore color and patterns for controls and the card
> 
> Yes, this works.  But it is a lot more difficult.  You have to create 
> the look and feel every single time you want to implement a control. 
> Imagine if you got your entire project done, and then you realized you 
> need to create 2 more buttons and 3 more menus.  Now you have to create 
> 6 more button images, and 3 complete menus (all to the design you want).
> 
> All in all, it would just be a whole lot easier if you could customize 
> lookAndFeel themes.

That sounds good, but what exactly does it mean?  As I read the skinning 
specs for most apps, only QuickTime's is easy while the rest are a lot 
of work for elements outside of what the QT skin spec supports.

We could break up the appearance of UI elements into two categories: 
static (such as icons and fill patterns) and dynamic (such a algorithmic 
gradient and fill procedures, like those used by Aqua).

The Mozilla spec is arguably one of the my dynamic around, yet still 
makes heavy use of static elements:
<http://www.xulplanet.com/references/elemref/ref_StyleProperties.html>

WinAmp takes a similar XML-based approach:
<http://www.winamp.com/nsdn/winamp/skinning/modern/>

Apple's QT spec takes the more technically simple option, comprised 
entirely of static elements:
<http://www.apple.com/quicktime/tools_tips/tutorials/mediaskins/>

The challenge with dynamic elements is that they require coding.  Rev 
has a good scripting language so one could do most things one would want 
for generating gradients, etc. dynamically at runtime using a 
frontscript which reads custom props in controls on preOpenCard and 
renders them according to whatever spec you like.

It may be possible for RunRev to help speed up the execution of some 
elements by supporting XUL, but much of any truly sophisticated 
rendering would still require a lot of custom code.  So while skinning 
could be made a bit more convenient, by its nature it will never be 
truly easy.  Coding custom fill algorithms is a bit of work in any 
language.

So while making truly dynamic skins means writing custom code in any 
skinning system, all of them provide ways to use images for quicker and 
simpler rendering wherever possible (fill patterns, fixed-size 
gradients, icons, etc.).

And many skins can be made using only static elements without custom 
coding at all, including all skins made for QuickTime Player.

Most of the stuff you'll need to define a skinning mechanism for your 
app can be done in Rev.  If you find elements that have you scratching 
your head post 'em here and we'll see what we can come up with.

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev