> 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 _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
