Skinning Engine

skinning_engine

   *
     Skinning Engine
         o
           Summary and Rationale
         o
           Current System
         o
           Requirements
         o
           Skinning Engine Proposals
         o
           How QT Quick and QML might be used in QT 4.7.x
         o
           Forum discussion
         o
           Ideas for Skinning Engines
         o
           Qt 4 based Skinning Engine

Skinning Engine Summary and Rationale

Status: This specification is in drafting. Please feel free to add comments.

Supported Widgets

   *
     Push-buttons
   *
     Multi-state push buttons
   *
     Sliders
         o
           horizontal or vertical
   *
     Text labels
   *
     Knobs
   *
     VU meter
   *
     Embed library widget
   *
     Status light

Requirements

Metadata/Manifest

   *
     Include the following metadata:
         o
           author
         o
           title
         o
           description
         o
           language
         o
           skin version
         o
           license
         o
           update-URL
         o
           suggested screen resolution
         o
           min screen resolution

Base Widget

   *
     Nameable
   *
     Position, Size
         o
           Potentially offer absolute positioning mode for legacy support, but in general deprecate absolute positioning.
         o
           Use size-hints (max-min size) instead of single size.
   *
     Tooltip
   *
     Connections
         o
           EmitOnDownPress and EmitOnRelease properties (to obviate need for double-connections)
         o
           Choose mouse button.
   *
     Tab ordering?

Widget Layout

   *
     Widget Grouping
         o
           Nameable
         o
           Have a size hint and optionally an absolute position.
         o
           Provide a hide/show-control. Uses the group's name.
   *
     Layouts
         o
           Allow a widget group to have a layout assigned to it.
   *
     Windows
         o
           Windows are the root of each hierarchy of widgets
   *
     Widget Templates
         o
           Ability to specify some template for a widget for saving time, sanity.

Widgets

   *
     Buttons
         o
           Allow multi-state button or push-button.
         o
           Support pixmaps for each button position
         o
           Allow non-pixmap buttons. Use QSS to styling.
   *
     Slider
         o
           Allow vertical or horizontal orientation
         o
           Separate image for slider and knob
         o
           Allow non-pixmap sliders. Use QSS for styling.
   *
     Drop-down Chooser
         o
           Allow styling via QSS.
         o
           No pixmap option, as it's text-only.
         o
           Requires Control 2.0, since if you connect it to a text control it must know what values it may take on.
   *
     Knobs
         o
           Single knob image that is rotated plus background image.
         o
           Allow specification of 'translation' function (i.e. log-potmeter or potmeter)
         o
           Allow non-pixmap knobs. Use QSS for styling.
   *
     Library Widget
         o
           Still a monolithic widget. Don't think it adds value to allow much customization here.
         o
           Use QSS for all appearance styling.
   *
     Text labels
         o
           Make use of Controls to display text instead of hard-coding text.
         o
           Potentially allow scripts to dynamically affect what is shown.
         o
           Allow Marquee effect so you can read text that goes out of the control.
   *
     VU Meter
         o
           Allow QSS styling (how???) or pixmaps.
   *
     Status light
         o
           Connects to a control and dynamically switches its pixmap or QSS property based on the control's value
   *
     Sampler Widget
         o
           Requirements unknown.
   *
     Effects Widget
         o
           Requirements unknown.
         o
           Potentially with a much better control system we can support neat things

Skinning Engine Proposals

Given the above requirements, list various proposals for skin formats here:

   *
     Qt4, Qt Style Sheet-based approach
   *
     Qt 4.7 QML/Kinetic-based approach
   *
     HTML/CSS Based Skins

The current ideas are: Qt 4 based Skinning Engine

Qt 4 is the cross-platform framework.

For the creation of a skinning system, Qt supports many things: layouts, style sheets, vector graphics, raster/OpenVG/OpenGL rendering, useful low-level painting system, XML, animation framework (since 4.6 or as official add-on), declarative UI technology (since 4.6)…

By combining some of these technologies it should be possible to create an advanced skinning engine for LMCE. To investigate

   *
     Explore the Declarative UI Technology in Qt 4.6 to see if it can help in creating a skinning engine.
         o
           It looks very promising: http://labs.trolltech.com/blogs/category/labs/graphics/kinetic/declarative_ui/
   *
     Explore QWidget versus QGraphicsView for layout.
         o
           How does the performance stack up?
         o
           QWidgets can be rendered in a QGV, but how does this affect performance?
               +
                 But when the visualization is rendered in OpenGL, we'll probably have to render the whole QGV in OpenGL
         o
           QGV will give us a really cool and flexible UI in combination with the Animation/DUI framework
         o
           QGV will give us fast software-based UI rendering, as well as support for rendering the UI through OpenGL and since Qt 4.6 also OpenVG
   *
     Explore if and how style sheets can help
         o
           Style sheets are very useful to skin stuff like scrollbars and other default widgets
         o
           The more important stuff like buttons should probably be skinned by reimplementing paintEvent, because this gives more possibilities
               +
                 Style sheets may be slower than reimplementing paintEvent - although it has to be investigated to be sure
               +
                 More advanced animations (besides simple hover/overroll effects) cannot be created with style sheets only

Pro

   *
     Support pixmap skins (porting of current skins will be easier this way, and performance will probably be higher than using SVG)
   *
     Support SVG skins (for those who want, SVG skins should be an option as well
         o
           Performance may be lower, but we could optionally render SVG as pixmaps to improve performance
   *
     Possibility to implement a layout system (because interface elements should not stretch)
   *
     The window itself should be themable/deformable too. Could be achieved by either composite or with a mask (or both)