Suggested Addition to Skinning

[KingArgyle]

I'm tossing this out for comments from Sub, PlugIn Developers and Skin Designers. I've tried to address some of the issues I've seen between the various plugins and also designers for skinning control and layout.

Below is a suggested future edition for the Skinning files. One of the problems from a skin designer aspect I can see is that the Layout and positioning is still pretty much tied to the Plugin code. An easy way to visualize what the placement looks like is not given, as no representation of the actual screen to be displayed is defined.

The following tries to represent this from a skinning design perspective instead of a coding perspective, but also give the plugin designer some functionality extensibility. There are two points of view for skins, the coders point of view and the layout design point of view.

These are the areas that this tries to address:
1. Standardization across plugins and skin files.
2. Make the skin files, more friendly for future GUI skinning tool. If somebody wants to write one using JasonF's Widget Library.
3. Represent what the actual screens look like.
4. Provide a Schema that will make sure that a Skin.xml is valid before a plugin tries to use it. If it doesn't pass Validation, then the plugin doesn't start. Some of this will relieve the plugin from having to do it's own validation checking, but not all.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
<Widgets>
<Buttons>
<Button> </Button>
<Button> </Button>
</Buttons>
<SpecialElements>
<SpecialElement></SpecialElement>
</SpecialElements>
<CompositeImages>
<CompositeImage></CompositeImage>
<CompositeImage></CompositeImage>
<CompositeImage></CompositeImage>
</CompositeImages>
<Panels>
<Panel></Panel>
</Panel>
<Menus>
<Menu type="Navigation"></Menu>
<Menu type="Standard"></Menu>
</Menus>
<Widgets>

<Screens>
<Screen identifier='ScreenId'>
<ScreenWidgets>
</ScreenWidgets>
<LayOut background="Blah">
<Widget type="Button" name="View" xpos="1" ypos="22"/>
<Widget type="SpecialElement" name="Name" xpos="44" ypos="33"/>
<Widget type="CompositeImage" name="NormalButtonImage" xpos="4" ypos="5"/>
<Pannel xpos="40" ypos="90">Screen2</Pannel>
</LayOut>
</Screen>
<Screen identifier='ScreenId2'>
<ScreenWidgets>
</ScreenWidgets>
<LayOut background="Blah">
<Widget type="Button" name="View" xpos="1" ypos="22"/>
<Widget type="SpecialElement" name="Name" xpos="44" ypos="33"/>
<Widget type="CompositeImage" name="NormalButtonImage" xpos="4" ypos="5"/>
<Pannel xpos="40" ypos="90">Screen2</Pannel>
</LayOut>
</Screen>
</Screens>
[/QUOTE]

loc - is now represented by xpos and ypos
size - is now width and height

This was done for several XML design reasons. Mainly because it requires less parsing code to be written to interpret or extract out a position.

If a plugin had more than one screen, it would have multiple screen elements under the Screens group. One for each screen that it defined. Screens would include PopUps and OverLay Screens as well as standard Screens.

Each Screen has a LayOut group, which contains Widgets. Widgets are the various Objects that make up that screen. They can include Buttons, Menus, CompositeImages, or Pannels.

The default skin for a Plugin would have all the Screens defined that it expects. Plus all the Widgets that it will use. Designers could then make layout changes as appropriate for their skin, but in a format that hopefully actually represents the screen they are working.

If this is adopted by Sub for a future version of GBPVR an XSLT could be created that would convert the existing skin.xml files to the new format, to make migration simpler for the plugin developer, and easier on designers when converting existing skins.

[jasonf]

I had thought about this while working on the Widget Library (you remember, that vaporware project that I keep throwing my spare time at).

My thought was that it should be possible to use a ASP.NET-type architecture, where the UI is mostly separated from the logic. The skin would define the UI, and would use markup much like HTML to set up the UI. A UI reader would parse this file, and instantiate objects, setting their properties in the process. The plugin itself would be like ASP.NET's codebehind, and would retrieve it's objects from the UI reader.

My current work in progress has already converted everything over to use a Style class contained within each control in order to store settings. If an object is a container, then it's style is inherited by the children (think Cascading Stylesheets in HTML).

With the CSS analogy, a skinner can define a &quot;global style&quot; at the root of the skin. Everything would inherit from this global style automatically, and only exceptions and overrides would need to be handled per plugin element.

It's a radical departure from the existing skinning functionality, but I think it carries a lot of reward. A point of contention will be that existing plugins would need to be retrofitted in order to take advantage of this functionality, but there's nothing that will stop the use of the existing skinning method from working alongside a new method.

[KingArgyle]

Jason I agree that the skinning needs to be seperated from the logic. Gives much more flexibility in the design. The plugin then only has to worry about reacting to the correct events, and processing those events. The skin designers get a much more represantive look on how the screens look.

I'd like to avoid the use of CSS or any attributes or methods that require some sort of parsing code to be created to extact information from an Attribute or Element. It breaks one of the Best Practice principals in XML design.

Best Practice:
http://www.cafeconleche.org/books/effect...rs/11.html

For example, currently, the skin.xml files have a loc attribute to specify where on the screen these elements should be placed. It looks like the following:

loc=&quot;123,45&quot;

Meaning that you have to write additional parsing code to pull out the x and y cordinates. This could easily be represented with two seperate attributes: xpos=&quot;123&quot; and ypos=&quot;45&quot;. Giving you the ability with XPath to easily extract each of the values. The same thing goes for the size attribute in the current represenation:
size=&quot;720,480&quot;

Could be:
width=&quot;720&quot;
height=&quot;480&quot;

It may be more wordy XML file, but in the long run, it lends itself to a design aspect better. There are already several UI and layout XML standards that could be used as a basis for the skins: XSLFO and XUL come to mind.

XSLFO supports all the formatting that CSS supports, but breaks each item out to an attribute. No special parsing code needs to be created to pull out the necessary information. If ultimately a skinning application is developed, it could easily write the appropriate XML.

A series of best practice articles discuss this:

http://www-106.ibm.com/developerworks/xm...leatt.html
http://www.cafeconleche.org/books/effect...rs/12.html
http://www.cafeconleche.org/books/effect...rs/11.html

Incorporating the best practices in the XML design, also makes it much easier to write an XML Schema that can be used to Validate a skin before a plugin even tries to process it, thus making sure that the Skin is valid, and the plugin can process it without dying halfway through because something wasn't included that should have been. If a Schema is used, and even though I'm not a big fan of XML Binding, you could create the necessary classes to process a skin, by running it through .NETs xsd application to generate the necessary class files.

[jasonf]

My original XML serialization of the widgets was very wordy, as you put it.  I did a lot with type conversions instead of relying on known schemas and then interpreting the elements individually.  Even though it was flexible as ####, I felt that this was too difficult for a skinner to work with because it felt very much like coding.  (This wouldn't necessarily be the case in what you suggested, though).

I also saw that it was lacking the type of cascading that I would like to see employed in order to simplify skinning (i.e., if some things apply across all plugins, then they should only be defined once at a root level.  Likewise, container controls should automatically pass their styles to child controls to be used as a baseline until overridden).

Here's an actual serialization of a form from my old code:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
<WidgetForm>
<widget name="Checkbox1" type="GBPVR.Widgets.Controls.Checkbox">
<!-- Base Widget Control Props -->
  <prop name="BackgroundColor" type="System.Drawing.Color" converter="System.Drawing.ColorConverter" value="Transparent" />
  <prop name="ScreenArea" type="System.Drawing.RectangleF">
     <set name="X" value="175" />
     <set name="Y" value="145" />
     <set name="Width" value="100" />
     <set name="Height" value="25" />
  </prop>
  <prop name="ZOrder" value="0" />
<!-- Checkbox Props -->
  <prop name="Caption" value="Checkbox" />
  <prop name="Checked" value="False" />
  <prop name="Font" type="System.Drawing.Font" converter="System.Drawing.FontConverter" value="Tahoma, 14pt, style=Bold" />
  <prop name="FontColor" type="System.Drawing.Color" converter="System.Drawing.ColorConverter" value="Blue" />
<!-- Additional Props -->

</widget>

<widget name="HScrollBar1" type="GBPVR.Widgets.Controls.HScrollBar">
<!-- Base Widget Control Props -->
  <prop name="BackgroundColor" type="System.Drawing.Color" converter="System.Drawing.ColorConverter" value="Transparent" />
  <prop name="ScreenArea" type="System.Drawing.RectangleF">
     <set name="X" value="66" />
     <set name="Y" value="171" />
     <set name="Width" value="200" />
     <set name="Height" value="15" />
  </prop>
  <prop name="ZOrder" value="0" />
<!-- HScrollBar Props -->
  <prop name="BorderWidth" value="2" />
  <prop name="BorderColor" type="System.Drawing.Color" converter="System.Drawing.ColorConverter" value="White" />
  <prop name="FontColor" type="System.Drawing.Color" converter="System.Drawing.ColorConverter" value="Blue" />
<!-- Additional Props -->

</widget>

</WidgetForm>
[/QUOTE]

I would rather see a model be used that is already familiar to HTML authors.  Any free-format parsing would use error trapping, so that if something doesn't work, then the control doesn't blow up--it just uses a default setting instead (like your web browser does today).  

Data elements, like a Caption property, would be attributes of the control's element.  Positioning and display elements would be part of the control's style, either as part of a stylesheet (which is inherited by each control), or set inline using the style attribute (which is then applied to the inherited style).  

Having said that, certain style attributes do not propogate to children, such as absolute positioning settings.  These may have corresponding attributes associated with them (i.e., the height and width can be set either by an attribute or within the style).

Something like the following can already be parsed by my current work-in-progress.  It accomplishes the same as above, but in much less space.  Aside from the contents of the styles themselves, it still lends itself to XSD validation:


<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
<widgetform style="background-color:Transparent; font-family:Tahoma; font-size:14; font-bold:true; color: Blue;">

    <checkbox   name="Checkbox1"
         caption="Checkbox"
         checked="False"
         style="left:175; top:145; width:100; height:25; z-index:0;" />

    <hscrollbar   name="HScrollBar1"
         style="left:66; top:171; width:200; height:15; z-index:0; border-width:2; border-color:White;" />

</widgetform>
[/QUOTE]

This is an interesting discussion, and an important one for steering the future direction of GBPVR.  I don't totally disagree with your standards-based, best practices approach.  I just feel that skinners would be more at home with something that is closer to XHTML/CSS.

[KingArgyle]

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"><widgetform style="background-color:Transparent; font-family:Tahoma; font-size:14; font-bold:true; color: Blue;">

<checkbox name="Checkbox1"
caption="Checkbox"
checked="False"
style="left:175; top:145; width:100; height:25; z-index:0;" />

<hscrollbar name="HScrollBar1"
style="left:66; top:171; width:200; height:15; z-index:0; border-width:2; border-color:White;" />

</widgetform>
[/QUOTE]

I'd suggestion a slight restructuring like:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">
<widgetform background-color="Transparent" font-family="Tahoma" font-size="14pt" font-bold="true" color="Blue">
<checkbox name="Checkbox1"
checked="False"
left="175px" top="145px" width="100px" height="25px" z-index="0">Checkbox</checkbox>

<hscrollbar name="HScrollBar1" left="66px" top="171px" width="200px" height="15px" z-index="0" border-width="2px" border-color="White"/>
</widgetform>
[/QUOTE]

You still keep all the familiar CSS notation, except written in an XML format, which you can now specify with a schema whether an element has to have any of these attributes. The value ranges can also be set, and valdiation rules against each attribute can be created to make sure the data is valid.

I do agree we need a simple to use format, that is easy to use whether editing by hand or using a Skin Editor program. I also think we need something that actually represents the various screens that a plugin uses. XHTML or HTML I think would almost be too wordy. XUL is too much and not really designed for what we would need. XAML is also to much.

I'm willing to work on creating the Schema for the new format. Even willing to provide an XSLT to translate existing skins over into the new formt when ready. If we can come up with a merge of the global naming convention that the current skins implement, and a screen layout using the WidgetForm method you have. I think we would have an enhanced solution that would more clearly represent a skin for a plugin.

[PartialGestalt]

KingArgyle, was a schema ever produced for this (or for what has since become the Skin2 bits)?