Skinning Engine - Revision history

Mandingo at 18:54, 25 June 2011

2011-06-25T18:54:16Z

←Older revision		Revision as of 18:54, 25 June 2011
Line 5:		Line 5:
	o		o
	Summary and Rationale		Summary and Rationale
	o
	~~Current System~~
	o		o
	Requirements		Requirements
Line 13:		Line 11:
	o		o
	How QT Quick and QML might be used in QT 4.7.x		How QT Quick and QML might be used in QT 4.7.x
	o
	~~Forum discussion~~
	o		o
	Ideas for Skinning Engines		Ideas for Skinning Engines

Mandingo at 18:50, 25 June 2011

2011-06-25T18:50:33Z

←Older revision		Revision as of 18:50, 25 June 2011
Line 44:		Line 44:
	Embed library widget		Embed library widget
	*		*
	Status ~~light~~		Status
			*
			Datagrid widget
			*
			Video widget

	Requirements		Requirements
Line 166:		Line 170:
	Allow QSS styling (how???) or pixmaps.		Allow QSS styling (how???) or pixmaps.
	*		*
	Status ~~light~~		Status
	o		o
	Connects to a control and dynamically switches its pixmap or QSS property based on the control's value		Connects to a control and dynamically switches its pixmap or QSS property based on the control's value
Line 221:		Line 225:
	+		+
	More advanced animations (besides simple hover/overroll effects) cannot be created with style sheets only		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)~~

Mandingo at 18:22, 25 June 2011

2011-06-25T18:22:21Z

←Older revision		Revision as of 18:22, 25 June 2011
Line 139:		Line 139:
	o		o
	No pixmap option, as it's text-only.		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		Knobs
Line 172:		Line 170:
	Connects to a control and dynamically switches its pixmap or QSS property based on the control's value		Connects to a control and dynamically switches its pixmap or QSS property based on the control's value
	*		*
	~~Sampler~~ Widget		Datagrid Widget
	o		o
	Requirements unknown.		Requirements unknown.
	*		*
	~~Effects~~ Widget		Video Widget
	o		o
	Requirements unknown.		Requirements unknown.
	o
	~~Potentially with a much better control system we can support neat things~~

	Skinning Engine Proposals		Skinning Engine Proposals
Line 203:		Line 199:
	To investigate		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.		Explore QWidget versus QGraphicsView for layout.

Mandingo: Created page with "skinning_engine * Skinning Engine o Summary and Rationale o Current System o Requirements o..."

2011-06-25T17:58:18Z

Created page with "skinning_engine * Skinning Engine o Summary and Rationale o Current System o Requirements o..."

New page

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)