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. * 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 * Datagrid Widget o Requirements unknown. * Video Widget o Requirements unknown.
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 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)