MeeGo wiki - User contributions [en]

Components Migration

2011-05-27T05:30:20Z

Btdrucke: /* Component Migration Phase III */

==Migration of Components from MeeGo.Labs.Components to MeeGo.Components==
''PAGE UNDER CONSTRUCTION''

Currently some UX components exists in multiple repositories (repo meego-ux-components / namespace MeeGo.Components, repo meegolabs-ux-components / namespace MeeGo.Labs.Components and repo meego-media-components / namespace MeeGo.Media). It is confusing and difficult to maintain various forked versions of code. The solution is to deprecate duplicate versions so that we have only a single copy of each component.

In many cases, this mean applications need to replace components from MeeGo.Labs.Components and MeeGo.Media with their counterparts from MeeGo.Components, making API changes as necessary. In some cases, code has been copied to MeeGo.Components prematurely and will be deprecated in favor of the MeeGo.Labs version.

Component migration will occur in three phases:

==Component Migration Phase I==
[DONE]

* Deprecated MeeGo.Media pickers (image/video/music)
* Deprecated MeeGo.Labs.Components Date and Time pickers
* NB: Contacts picker will remain in MeeGo.Labs for the time being

==Components Migration Phase II==
[DONE]
* Most duplicated QML components from MeeGo.Labs have been deprecated (see [[#Components Affected by Phase II]])
* Duplicated C++ components from MeeGo.Labs are not yet depreciated.
* Window and AppPage/ApplicationPage will not be migrated in this phase (see [[#Components Migration Phase III]] for information regarding these components)

Since most of the meego-ux-components depend on signals from the new meego-ux-components Window.qml, some of them will have issues when being used with the meegolabs Window.qml. The ModalContextMenu is our main problem child here.
We have added a Window2.qml to the meegolabs repo which is basically the meegolabs Window.qml, but with the orientation behaviour of the new meego-ux-components Window.qml. Just add the '2' behind Window to use it, no further API changes are necessary.
The ModalContextmenu called in the content area will now stay on screen. Of course Window2.qml does not have the full functionality of the meego-ux-components Window.qml, so there will still be a few bugs until you switch to the meego-ux-components Window.qml.
Bugs we found after a quick testing:
* the book and action menu context menus will still leave the screen/ appear in the wrong position when the orientation changes while they are visible.
* Some apps create their own status bar and tool bar:
** the panels view has two status bars.
** the photo apps detail page always shows its search bar.
These bugs should not be filed and will not be fixed since Window2.qml is only a preliminary solution for testing only!

===Components Affected by Phase II===
{|
|MeeGo Labs ||MeeGo-Ux-Components ||Changes
|-
|ActionMenu ||ActionMenu ||API changed
|-
|Button ||Button ||API and Design
|-
|CheckBox ||CheckBox ||API and Design
|-
|ContextMenu ||ModalContextMenu ||derived from ModalFog, API change
|-
|DropDown ||DropDown ||API and Design
|-
|EditPane ||TextField ||replace by TextField
|-
|ExpandingBox ||ExpandingBox ||API and Design
|-
|Fog ||ModalFog ||whole concept changed
|-
|IconButton ||IconButton ||API and Design
|-
|MessageBox ||ModalMesseageBox ||derived from ModalFog, API change
|-
|ModalDialog ||ModalDialog ||API and Design
|-
|ModalSurface ||ModalFog ||API and Design
|-
|PickerDialog ||ModalDialog ||-
|-
|PopupList ||PopupList ||API and Design
|-
|RadioButton ||RadioButton ||Design
|-
|RadioGroup.js ||RadioGroup.js ||Design
|-
|RadioGroup.qml ||RadioGroup.qml ||API and Design
|-
|Slider ||Slider ||API and Design
|-
|Spinner ||<same> ||ModalSpinner can be used for the full-screen use case
|-
|StatusBar ||StatusBar ||No changes
|-
|TextEntry ||TextEntry ||API and Design
|-
|ToggleButton ||ToggleButton ||API and Design
|-
|TopItem ||TopItem ||API
|-
|VerticalSlider ||VerticalSlider ||API and Design
|}

==Component Migration Phase III==
[DONE]

A general change in the meego-ux-components is the concept of how to use Window
and AppPage in order to create a navigation path in your application. You
can find the examples and the tutorial in the devel package to help you understand
the concept.

'''IMPORTANT:''' When using the meego-ux-components Window.qml: the id of your Window.qml main page item must always be 'window'. This is necessary for the AppPages to set values (like title) in the Window.

Nonetheless some examples:

====Example for a Page.qml====
The AppPage is the content that's shown inside an apps window. Statusbar and toolbar are provided by the Window.qml as well as a default action menu. The pageTitle will appear in the Windows toolbar.
AppPage {
id: mainPage

pageTitle: "My first page"

actionMenuModel: [ "First choice", "Second choice" ]
actionMenuPayload: [ 1, 2 ]

onActionMenuTriggered: {
// an action menu entry was clicked, action menu hidden
// and '1' or '2' returned in selectedItem
}
}
You can call addPage(<nextPageName>) to switch to the next page.
AppPage {
(...)
Component { id: nextPage; SubPage{} }

onClicked: { addPage( nextPage ) }
(...)
}
The Window.qml provides a back button in the toolbar to get back to the previous page.

====Example for a MainWindow.qml====
The Window is the applications main item. It has a book menu to switch between main pages.
Window {
id: window

bookMenuModel: [ qsTr("Page 1") , qsTr("Page 2") ]
bookMenuPayload: [ book1Component, book2Component ]

Component.onCompleted: {
console.log("load MainPage")
switchBook( book1Component )
}

Component { id: book1Component; Page {} }
Component { id: book2Component; Page2 {} }
}
===Phase III major API changes for AppPage===
{|
! Meegolabs ApplicationPage
! meego-ux-components AppPage
|-
| variant windowModel || -
|-
| variant windowFilterPayload || -
|-
| string title || string pageTitle
|-
| item content || -
|-
| bool fullContent || bool fullContent
|-
| bool fullscreen || bool fullScreen
|-
| bool showSearch || -
|-
| bool disableSearch || -
|-
| bool showToolbar || -
|-
| bool hasBack || -
|-
| int toolbarHeight || -
|-
| bool moving || -
|-
| variant applicationData || -
|-
| int type || -
|-
| alias menuContent || variant actionMenuModel
|-
| alias menuItem || variant actionMenuPayload
|-
| - || string actionMenuTitle
|-
| alias menuWidth || -
|-
| alias menuHeight || -
|-
| function closeMenu() || -
|-
| signal close() || -
|-
| signal filterTriggered(int index, variant payload) || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| signal addApplicationPage(variant component) || -
|-
| signal search(string needle) || -
|}

===Phase III major API changes for Window:===
{|
! meegolabs Window
! meego-ux Window
|-
| bool foreground || bool isActiveWindow
|-
| bool transparent || -
|-
| string title || string toolBarTitle
|-
| string[] filterModel || string[] bookMenuModel
|-
| string[] filterPayload || string[] bookMenuPayload
|-
| - || string bookMenuTitle
|-
| - || bool bookMenuHighlightSelection
|-
| - || string[] actionMenuModel
|-
| - || string[] actionMenuPayload
|-
| - || string actionMenuTitle
|-
| - || bool actionMenuHighlightSelection
|-
| int filterMenuWidth || -
|-
| signal filterTriggered(int index, variant payload) || -
|-
| - || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| Component applicationPage || -
|-
| alias currentApplication || -
|-
| variant applicationData || -
|-
| item content: innerContent || -
|-
| item container: outerContent || -
|-
| int orientation || int orientation
|-
| bool orientationLocked || bool isOrientationLocked
|-
| bool orientationTransitionEnabled || -
|-
| - || string lockOrientationIn
|-
| bool fullScreen || bool fullScreen
|-
| bool fullContent || bool fullContent
|-
| bool showtoolbar || -
|-
| bool showsearch || bool showToolBarSearch
|-
| signal search(string needle) || signal search(string needle)
|-
| alias statusBar || -
|-
| color backgroundColor || -
|-
| color sidepanelBackgroundColor || -
|-
| bool showStartupAnimation || -
|}

=== Migration from MouseArea to GestureMouseArea ===
{|
Most components and Apps are using MouseAreas instead of GestureAreas right now. In order to help on the first step of migration one can use the new GestureMouseArea from the MeeGo.Labs.Components. This Component simulated (nearly) the API of a MouseArea, but using the GestureArea internally for recognition of gestures, with the advantage to have a certain fuzziness in the opposite to the MouseArea.

This component will be deprecated once, because the goal is to use the GestureArea everywhere as standard for Gestures.

==== Differences in the API ====

There is basically one big difference in the API of GestureMouseArea: Instead of an MouseEvent object, all signals are pushing 3 paramter: int mouseX and int mouseY for the position and a bool wasHeld for regocnition of a TapAndHold Gesture

==== Migration Example ====

using the MouseArea:
<pre>
import Qt 4.7

MouseArea {
id: mouseArea
anchors.fill: parent

onClicked: {
aProperty = true
aObject.x = mouse.x
aObject.x = mouse.y
}

onPressAndHold: {
aProperty = false
aObject.x = mouse.x
aObject.y = mouse.y
}

}
</pre>

using the GestureMouseArea:
<pre>
import Qt 4.7
import MeeGo.Labs.Components 0.1

GestureMouseArea {
id: mouseArea
anchors.fill: parent

onClicked: {
aProperty = true
aObject.x = mouseX
aObject.y = mouseY
}

onPressAndHold: {
aProperty = false
aObject.x = mouseX
aObject.y = mouseY
}
}
</pre>

Components Migration

2011-05-27T05:29:57Z

Btdrucke: /* Component Migration Phase I */

==Migration of Components from MeeGo.Labs.Components to MeeGo.Components==
''PAGE UNDER CONSTRUCTION''

Currently some UX components exists in multiple repositories (repo meego-ux-components / namespace MeeGo.Components, repo meegolabs-ux-components / namespace MeeGo.Labs.Components and repo meego-media-components / namespace MeeGo.Media). It is confusing and difficult to maintain various forked versions of code. The solution is to deprecate duplicate versions so that we have only a single copy of each component.

In many cases, this mean applications need to replace components from MeeGo.Labs.Components and MeeGo.Media with their counterparts from MeeGo.Components, making API changes as necessary. In some cases, code has been copied to MeeGo.Components prematurely and will be deprecated in favor of the MeeGo.Labs version.

Component migration will occur in three phases:

==Component Migration Phase I==
[DONE]

* Deprecated MeeGo.Media pickers (image/video/music)
* Deprecated MeeGo.Labs.Components Date and Time pickers
* NB: Contacts picker will remain in MeeGo.Labs for the time being

==Components Migration Phase II==
[DONE]
* Most duplicated QML components from MeeGo.Labs have been deprecated (see [[#Components Affected by Phase II]])
* Duplicated C++ components from MeeGo.Labs are not yet depreciated.
* Window and AppPage/ApplicationPage will not be migrated in this phase (see [[#Components Migration Phase III]] for information regarding these components)

Since most of the meego-ux-components depend on signals from the new meego-ux-components Window.qml, some of them will have issues when being used with the meegolabs Window.qml. The ModalContextMenu is our main problem child here.
We have added a Window2.qml to the meegolabs repo which is basically the meegolabs Window.qml, but with the orientation behaviour of the new meego-ux-components Window.qml. Just add the '2' behind Window to use it, no further API changes are necessary.
The ModalContextmenu called in the content area will now stay on screen. Of course Window2.qml does not have the full functionality of the meego-ux-components Window.qml, so there will still be a few bugs until you switch to the meego-ux-components Window.qml.
Bugs we found after a quick testing:
* the book and action menu context menus will still leave the screen/ appear in the wrong position when the orientation changes while they are visible.
* Some apps create their own status bar and tool bar:
** the panels view has two status bars.
** the photo apps detail page always shows its search bar.
These bugs should not be filed and will not be fixed since Window2.qml is only a preliminary solution for testing only!

===Components Affected by Phase II===
{|
|MeeGo Labs ||MeeGo-Ux-Components ||Changes
|-
|ActionMenu ||ActionMenu ||API changed
|-
|Button ||Button ||API and Design
|-
|CheckBox ||CheckBox ||API and Design
|-
|ContextMenu ||ModalContextMenu ||derived from ModalFog, API change
|-
|DropDown ||DropDown ||API and Design
|-
|EditPane ||TextField ||replace by TextField
|-
|ExpandingBox ||ExpandingBox ||API and Design
|-
|Fog ||ModalFog ||whole concept changed
|-
|IconButton ||IconButton ||API and Design
|-
|MessageBox ||ModalMesseageBox ||derived from ModalFog, API change
|-
|ModalDialog ||ModalDialog ||API and Design
|-
|ModalSurface ||ModalFog ||API and Design
|-
|PickerDialog ||ModalDialog ||-
|-
|PopupList ||PopupList ||API and Design
|-
|RadioButton ||RadioButton ||Design
|-
|RadioGroup.js ||RadioGroup.js ||Design
|-
|RadioGroup.qml ||RadioGroup.qml ||API and Design
|-
|Slider ||Slider ||API and Design
|-
|Spinner ||<same> ||ModalSpinner can be used for the full-screen use case
|-
|StatusBar ||StatusBar ||No changes
|-
|TextEntry ||TextEntry ||API and Design
|-
|ToggleButton ||ToggleButton ||API and Design
|-
|TopItem ||TopItem ||API
|-
|VerticalSlider ||VerticalSlider ||API and Design
|}

==Component Migration Phase III==
Was scheduled to end April 29, now May 6th. In this phase we deprecate MeeGo.Labs Window and ApplicationPage components to be replace by MeeGo.Components Window and AppPage.

A general change in the meego-ux-components is the concept of how to use Window
and AppPage in order to create a navigation path in your application. You
can find the examples and the tutorial in the devel package to help you understand
the concept.

'''IMPORTANT:''' When using the meego-ux-components Window.qml: the id of your Window.qml main page item must always be 'window'. This is necessary for the AppPages to set values (like title) in the Window.

Nonetheless some examples:

====Example for a Page.qml====
The AppPage is the content that's shown inside an apps window. Statusbar and toolbar are provided by the Window.qml as well as a default action menu. The pageTitle will appear in the Windows toolbar.
AppPage {
id: mainPage

pageTitle: "My first page"

actionMenuModel: [ "First choice", "Second choice" ]
actionMenuPayload: [ 1, 2 ]

onActionMenuTriggered: {
// an action menu entry was clicked, action menu hidden
// and '1' or '2' returned in selectedItem
}
}
You can call addPage(<nextPageName>) to switch to the next page.
AppPage {
(...)
Component { id: nextPage; SubPage{} }

onClicked: { addPage( nextPage ) }
(...)
}
The Window.qml provides a back button in the toolbar to get back to the previous page.

====Example for a MainWindow.qml====
The Window is the applications main item. It has a book menu to switch between main pages.
Window {
id: window

bookMenuModel: [ qsTr("Page 1") , qsTr("Page 2") ]
bookMenuPayload: [ book1Component, book2Component ]

Component.onCompleted: {
console.log("load MainPage")
switchBook( book1Component )
}

Component { id: book1Component; Page {} }
Component { id: book2Component; Page2 {} }
}
===Phase III major API changes for AppPage===
{|
! Meegolabs ApplicationPage
! meego-ux-components AppPage
|-
| variant windowModel || -
|-
| variant windowFilterPayload || -
|-
| string title || string pageTitle
|-
| item content || -
|-
| bool fullContent || bool fullContent
|-
| bool fullscreen || bool fullScreen
|-
| bool showSearch || -
|-
| bool disableSearch || -
|-
| bool showToolbar || -
|-
| bool hasBack || -
|-
| int toolbarHeight || -
|-
| bool moving || -
|-
| variant applicationData || -
|-
| int type || -
|-
| alias menuContent || variant actionMenuModel
|-
| alias menuItem || variant actionMenuPayload
|-
| - || string actionMenuTitle
|-
| alias menuWidth || -
|-
| alias menuHeight || -
|-
| function closeMenu() || -
|-
| signal close() || -
|-
| signal filterTriggered(int index, variant payload) || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| signal addApplicationPage(variant component) || -
|-
| signal search(string needle) || -
|}

===Phase III major API changes for Window:===
{|
! meegolabs Window
! meego-ux Window
|-
| bool foreground || bool isActiveWindow
|-
| bool transparent || -
|-
| string title || string toolBarTitle
|-
| string[] filterModel || string[] bookMenuModel
|-
| string[] filterPayload || string[] bookMenuPayload
|-
| - || string bookMenuTitle
|-
| - || bool bookMenuHighlightSelection
|-
| - || string[] actionMenuModel
|-
| - || string[] actionMenuPayload
|-
| - || string actionMenuTitle
|-
| - || bool actionMenuHighlightSelection
|-
| int filterMenuWidth || -
|-
| signal filterTriggered(int index, variant payload) || -
|-
| - || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| Component applicationPage || -
|-
| alias currentApplication || -
|-
| variant applicationData || -
|-
| item content: innerContent || -
|-
| item container: outerContent || -
|-
| int orientation || int orientation
|-
| bool orientationLocked || bool isOrientationLocked
|-
| bool orientationTransitionEnabled || -
|-
| - || string lockOrientationIn
|-
| bool fullScreen || bool fullScreen
|-
| bool fullContent || bool fullContent
|-
| bool showtoolbar || -
|-
| bool showsearch || bool showToolBarSearch
|-
| signal search(string needle) || signal search(string needle)
|-
| alias statusBar || -
|-
| color backgroundColor || -
|-
| color sidepanelBackgroundColor || -
|-
| bool showStartupAnimation || -
|}

=== Migration from MouseArea to GestureMouseArea ===
{|
Most components and Apps are using MouseAreas instead of GestureAreas right now. In order to help on the first step of migration one can use the new GestureMouseArea from the MeeGo.Labs.Components. This Component simulated (nearly) the API of a MouseArea, but using the GestureArea internally for recognition of gestures, with the advantage to have a certain fuzziness in the opposite to the MouseArea.

This component will be deprecated once, because the goal is to use the GestureArea everywhere as standard for Gestures.

==== Differences in the API ====

There is basically one big difference in the API of GestureMouseArea: Instead of an MouseEvent object, all signals are pushing 3 paramter: int mouseX and int mouseY for the position and a bool wasHeld for regocnition of a TapAndHold Gesture

==== Migration Example ====

using the MouseArea:
<pre>
import Qt 4.7

MouseArea {
id: mouseArea
anchors.fill: parent

onClicked: {
aProperty = true
aObject.x = mouse.x
aObject.x = mouse.y
}

onPressAndHold: {
aProperty = false
aObject.x = mouse.x
aObject.y = mouse.y
}

}
</pre>

using the GestureMouseArea:
<pre>
import Qt 4.7
import MeeGo.Labs.Components 0.1

GestureMouseArea {
id: mouseArea
anchors.fill: parent

onClicked: {
aProperty = true
aObject.x = mouseX
aObject.y = mouseY
}

onPressAndHold: {
aProperty = false
aObject.x = mouseX
aObject.y = mouseY
}
}
</pre>

Components Migration

2011-05-27T05:29:42Z

Btdrucke: /* Components Migration Phase II */

==Migration of Components from MeeGo.Labs.Components to MeeGo.Components==
''PAGE UNDER CONSTRUCTION''

Currently some UX components exists in multiple repositories (repo meego-ux-components / namespace MeeGo.Components, repo meegolabs-ux-components / namespace MeeGo.Labs.Components and repo meego-media-components / namespace MeeGo.Media). It is confusing and difficult to maintain various forked versions of code. The solution is to deprecate duplicate versions so that we have only a single copy of each component.

In many cases, this mean applications need to replace components from MeeGo.Labs.Components and MeeGo.Media with their counterparts from MeeGo.Components, making API changes as necessary. In some cases, code has been copied to MeeGo.Components prematurely and will be deprecated in favor of the MeeGo.Labs version.

Component migration will occur in three phases:

==Component Migration Phase I==
Done as of April 9th.

* Deprecated MeeGo.Media pickers (image/video/music)
* Deprecated MeeGo.Labs.Components Date and Time pickers
* NB: Contacts picker will remain in MeeGo.Labs for the time being

==Components Migration Phase II==
[DONE]
* Most duplicated QML components from MeeGo.Labs have been deprecated (see [[#Components Affected by Phase II]])
* Duplicated C++ components from MeeGo.Labs are not yet depreciated.
* Window and AppPage/ApplicationPage will not be migrated in this phase (see [[#Components Migration Phase III]] for information regarding these components)

Since most of the meego-ux-components depend on signals from the new meego-ux-components Window.qml, some of them will have issues when being used with the meegolabs Window.qml. The ModalContextMenu is our main problem child here.
We have added a Window2.qml to the meegolabs repo which is basically the meegolabs Window.qml, but with the orientation behaviour of the new meego-ux-components Window.qml. Just add the '2' behind Window to use it, no further API changes are necessary.
The ModalContextmenu called in the content area will now stay on screen. Of course Window2.qml does not have the full functionality of the meego-ux-components Window.qml, so there will still be a few bugs until you switch to the meego-ux-components Window.qml.
Bugs we found after a quick testing:
* the book and action menu context menus will still leave the screen/ appear in the wrong position when the orientation changes while they are visible.
* Some apps create their own status bar and tool bar:
** the panels view has two status bars.
** the photo apps detail page always shows its search bar.
These bugs should not be filed and will not be fixed since Window2.qml is only a preliminary solution for testing only!

===Components Affected by Phase II===
{|
|MeeGo Labs ||MeeGo-Ux-Components ||Changes
|-
|ActionMenu ||ActionMenu ||API changed
|-
|Button ||Button ||API and Design
|-
|CheckBox ||CheckBox ||API and Design
|-
|ContextMenu ||ModalContextMenu ||derived from ModalFog, API change
|-
|DropDown ||DropDown ||API and Design
|-
|EditPane ||TextField ||replace by TextField
|-
|ExpandingBox ||ExpandingBox ||API and Design
|-
|Fog ||ModalFog ||whole concept changed
|-
|IconButton ||IconButton ||API and Design
|-
|MessageBox ||ModalMesseageBox ||derived from ModalFog, API change
|-
|ModalDialog ||ModalDialog ||API and Design
|-
|ModalSurface ||ModalFog ||API and Design
|-
|PickerDialog ||ModalDialog ||-
|-
|PopupList ||PopupList ||API and Design
|-
|RadioButton ||RadioButton ||Design
|-
|RadioGroup.js ||RadioGroup.js ||Design
|-
|RadioGroup.qml ||RadioGroup.qml ||API and Design
|-
|Slider ||Slider ||API and Design
|-
|Spinner ||<same> ||ModalSpinner can be used for the full-screen use case
|-
|StatusBar ||StatusBar ||No changes
|-
|TextEntry ||TextEntry ||API and Design
|-
|ToggleButton ||ToggleButton ||API and Design
|-
|TopItem ||TopItem ||API
|-
|VerticalSlider ||VerticalSlider ||API and Design
|}

==Component Migration Phase III==
Was scheduled to end April 29, now May 6th. In this phase we deprecate MeeGo.Labs Window and ApplicationPage components to be replace by MeeGo.Components Window and AppPage.

A general change in the meego-ux-components is the concept of how to use Window
and AppPage in order to create a navigation path in your application. You
can find the examples and the tutorial in the devel package to help you understand
the concept.

'''IMPORTANT:''' When using the meego-ux-components Window.qml: the id of your Window.qml main page item must always be 'window'. This is necessary for the AppPages to set values (like title) in the Window.

Nonetheless some examples:

====Example for a Page.qml====
The AppPage is the content that's shown inside an apps window. Statusbar and toolbar are provided by the Window.qml as well as a default action menu. The pageTitle will appear in the Windows toolbar.
AppPage {
id: mainPage

pageTitle: "My first page"

actionMenuModel: [ "First choice", "Second choice" ]
actionMenuPayload: [ 1, 2 ]

onActionMenuTriggered: {
// an action menu entry was clicked, action menu hidden
// and '1' or '2' returned in selectedItem
}
}
You can call addPage(<nextPageName>) to switch to the next page.
AppPage {
(...)
Component { id: nextPage; SubPage{} }

onClicked: { addPage( nextPage ) }
(...)
}
The Window.qml provides a back button in the toolbar to get back to the previous page.

====Example for a MainWindow.qml====
The Window is the applications main item. It has a book menu to switch between main pages.
Window {
id: window

bookMenuModel: [ qsTr("Page 1") , qsTr("Page 2") ]
bookMenuPayload: [ book1Component, book2Component ]

Component.onCompleted: {
console.log("load MainPage")
switchBook( book1Component )
}

Component { id: book1Component; Page {} }
Component { id: book2Component; Page2 {} }
}
===Phase III major API changes for AppPage===
{|
! Meegolabs ApplicationPage
! meego-ux-components AppPage
|-
| variant windowModel || -
|-
| variant windowFilterPayload || -
|-
| string title || string pageTitle
|-
| item content || -
|-
| bool fullContent || bool fullContent
|-
| bool fullscreen || bool fullScreen
|-
| bool showSearch || -
|-
| bool disableSearch || -
|-
| bool showToolbar || -
|-
| bool hasBack || -
|-
| int toolbarHeight || -
|-
| bool moving || -
|-
| variant applicationData || -
|-
| int type || -
|-
| alias menuContent || variant actionMenuModel
|-
| alias menuItem || variant actionMenuPayload
|-
| - || string actionMenuTitle
|-
| alias menuWidth || -
|-
| alias menuHeight || -
|-
| function closeMenu() || -
|-
| signal close() || -
|-
| signal filterTriggered(int index, variant payload) || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| signal addApplicationPage(variant component) || -
|-
| signal search(string needle) || -
|}

===Phase III major API changes for Window:===
{|
! meegolabs Window
! meego-ux Window
|-
| bool foreground || bool isActiveWindow
|-
| bool transparent || -
|-
| string title || string toolBarTitle
|-
| string[] filterModel || string[] bookMenuModel
|-
| string[] filterPayload || string[] bookMenuPayload
|-
| - || string bookMenuTitle
|-
| - || bool bookMenuHighlightSelection
|-
| - || string[] actionMenuModel
|-
| - || string[] actionMenuPayload
|-
| - || string actionMenuTitle
|-
| - || bool actionMenuHighlightSelection
|-
| int filterMenuWidth || -
|-
| signal filterTriggered(int index, variant payload) || -
|-
| - || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| Component applicationPage || -
|-
| alias currentApplication || -
|-
| variant applicationData || -
|-
| item content: innerContent || -
|-
| item container: outerContent || -
|-
| int orientation || int orientation
|-
| bool orientationLocked || bool isOrientationLocked
|-
| bool orientationTransitionEnabled || -
|-
| - || string lockOrientationIn
|-
| bool fullScreen || bool fullScreen
|-
| bool fullContent || bool fullContent
|-
| bool showtoolbar || -
|-
| bool showsearch || bool showToolBarSearch
|-
| signal search(string needle) || signal search(string needle)
|-
| alias statusBar || -
|-
| color backgroundColor || -
|-
| color sidepanelBackgroundColor || -
|-
| bool showStartupAnimation || -
|}

=== Migration from MouseArea to GestureMouseArea ===
{|
Most components and Apps are using MouseAreas instead of GestureAreas right now. In order to help on the first step of migration one can use the new GestureMouseArea from the MeeGo.Labs.Components. This Component simulated (nearly) the API of a MouseArea, but using the GestureArea internally for recognition of gestures, with the advantage to have a certain fuzziness in the opposite to the MouseArea.

This component will be deprecated once, because the goal is to use the GestureArea everywhere as standard for Gestures.

==== Differences in the API ====

There is basically one big difference in the API of GestureMouseArea: Instead of an MouseEvent object, all signals are pushing 3 paramter: int mouseX and int mouseY for the position and a bool wasHeld for regocnition of a TapAndHold Gesture

==== Migration Example ====

using the MouseArea:
<pre>
import Qt 4.7

MouseArea {
id: mouseArea
anchors.fill: parent

onClicked: {
aProperty = true
aObject.x = mouse.x
aObject.x = mouse.y
}

onPressAndHold: {
aProperty = false
aObject.x = mouse.x
aObject.y = mouse.y
}

}
</pre>

using the GestureMouseArea:
<pre>
import Qt 4.7
import MeeGo.Labs.Components 0.1

GestureMouseArea {
id: mouseArea
anchors.fill: parent

onClicked: {
aProperty = true
aObject.x = mouseX
aObject.y = mouseY
}

onPressAndHold: {
aProperty = false
aObject.x = mouseX
aObject.y = mouseY
}
}
</pre>

MeeGo UX Components

2011-05-27T05:22:31Z

Btdrucke: /* Adding MeeGo UX Components */

==Overview==
The '''meego-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meego-ux-components&project=Trunk OBS]] provides visual components for third-party developers to use to quickly create applications adhering to the MeeGo UX look-and-feel. These components are supported and are an official part of the MeeGo API for developers.

Many components in this package first appeared in the '''meegolabs-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meegolabs-ux-components&project=Trunk OBS]]. Code in this package includes experimental code and early versions with unstable APIs. There is no guarantee of support for these components nor will they necessarily maintain consistent software interfaces.

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components (See [[Components Migration]]).

==API Documentation==
API docs are generated automatically from the tip of the git repository at http://apidocs.meego.com.

==Basic Tutorials==
There are [[MeeGo UX Tutorials|basic tutorials for the MeeGo UX components]].

==Installing MeeGo UX Components==
You can install the MeeGo UX components either from the zypper (recommended) or directly form the latest version of the source code. This code assumes you are working either on a MeeGo system [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Windows|(Windows]] | [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux|Linux)]], within the [[SDK/Qemu|MeeGo SDK QEMU environment]], or within a [[Developing_in_a_Meego_Environment#Step_1:_Chrooting_into_the_development_image|MeeGo chroot configuration]].

===Using Zypper===
To use MeeGo UX components for your project, you will need to install the development version of the package. Using zypper:
zypper install meego-ux-components-devel

===From a Source Package===
First ensure that you have an enabled Trunk source zypper repo. Bring in a source archive and all the needed build-time dependencies with:
zypper source-install meego-ux-components

===From a Git Repo===
We'll first clone the source from the upstream repository location on Gitorious:
git clone git://meego.gitorious.org/meego-ux/meego-ux-components

The easiest way to prepare your development environment with all the build-time dependencies is to install the source package as described above.
If you don't want to do that, read the README file for instructions on installing dependent packages manually. Finally, make and install:

cd meego-ux-components
qmake
make
sudo make install

==Examples of Using Components==

To see the components in action and to verify correct installation, we can use the three example programs provided:

* meego-ux-components-widgetgallery - A gallery of components which demonstrate each components and interactively lets you change component properties. See [[MeeGo_UX_Components_WidgetGallery|screen shots]].
* meego-ux-components-app-photos - An example application that uses MeeGo UX components
* meego-ux-components-tutorial - An on-line tutorial on how to use MeeGo UX Components

To run on a development system, use meego-qml-launcher. Your application should have a file at ''/usr/share/<application-name>/main.qml''. This tool exports theme information to QML applications (font sizes, colors, dimensions, etc) and also ensures that your application is treated as a system-wide singleton. That is, if the app is already running, meego-qml-launcher will send a "raise" dbus signal instead of launching a second instance.

$ meego-qml-launcher --fullscreen --app meego-ux-components-widgetgallery

When running on target hardware, you can add the --opengl option to use hardware graphics acceleration.

$ meego-qml-launcher --opengl --fullscreen --app meego-ux-components-widgetgallery

==Using Components in a New Application==
Now that the MeeGo UX Components are installed on your system, you can begin developing a new application using the components.

# Launch Qt Creator.
# Select 'Create Project'
# Under Projects select 'Qt Quick Project'
# 'QML Application' will be selected for the template type.
# Click 'Choose...'
# Give the project a name, for example "thatwaseasy". Click 'Next'
# Click 'Finish' Qt Creator will now create the project and provide an initial QML file

Let's run it to see what it does. Click the green arrow in the lower left corner of Qt Creator. This will run the application. After a few moments a new window will appear with the text 'Hello world' Now let's add a MeeGo UX button and when it is pressed, we will change the text to say "That was easy!"

Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

==Adding MeeGo UX Components==
Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

==Migration to Components==
[[Components_Migration|Guides and roadmap]] for migrating from MeeGo.Labs.Components to MeeGo.Components

[[Category:Qml]]
[[Category:Qt]]

Main Page

2011-05-27T05:20:05Z

Btdrucke: /* MeeGo Components */

== MeeGo Project Functions ==
* [[Community Office]]
* [[Localization team|Localization]]
* [http://meego.com/about/governance/program-office Program Office]
* [[Core_OS_Program | Core OS Program]]
* [[Handset_Program | Handset UX Program]]
* [[In-vehicle | In Vehicle Infotainment - IVI]]
* [[Product Management]]
* [[Quality]]
** [[Error Management]]
* [[Release_Engineering|Release Engineering]]
* [http://meego.com/about/governance/ui-design User Interface Design]
* [[SDK]]
* [[Architecture]]
* [[Meego IT]]

= User =

* [[MeeGo Netbook FAQ]]
* [http://meego.com/devices/netbook/installing-meego-your-netbook Install MeeGo on your netbook]
* [[Devices|Supported devices]]
* [[Install MeeGo from Hard Disk]]

= Developer =
== Developer Guide ==

* [[SDK/Docs/1.1|Developer Guide for MeeGo 1.1]]
* [[SDK/Docs/1.0|Developer Guide for MeeGo 1.0]]
* [[Build_Infrastructure | Build Infrastructure]]
* [[MeeGo Porting Guide]]
* [[QML tutorials]] - Some tutorials to help get started with QML, the Qt Modelling Language.
* [http://mxr.meego.com/ MeeGo cross reference] - Index of MeeGo source code

Other documents:
{| border="1"
! Document
! Variety (Version)
! Architectures
|-
|Instructions for [[ARM|ARM based devices (N900, BeagleBoard, PandaBoard, Snowball)]]
|All
|ARM
|-
|Instructions for [[MeeGo_1.0_Netbook_VirtualBox|VirtualBox]]
|Netbook (1.0)
|Intel
|-
|Instructions for [[MeeGo SDK on Windows with VirtualBox]]
|All
|All
|-
|Tips for [[Developing With The Aava]]
|Handset/Aava
|Intel
|}

== Release Process ==
The MeeGo Release Process includes:
* [[Release_Engineering/Process|Release process and work flow]]
* [[Release_Engineering/Release_Timeline|MeeGo releases every 6 months]]
* [[Release_Engineering/Process|Nightly builds for developers and weekly releases will be available]]

== MeeGo Components ==
* [[MeeGo_UX_Components|MeeGo Components]] - Supported common QML components

= Community =

== Contributing to MeeGo ==
* Read our [[Community guidelines]]: [[Wiki contribution guidelines|Wiki]], [[Mailing list guidelines|mailing list]], [[Forum/Guidelines|forum]], and [[Community guidelines|more]].
* [[Community communication|Participate in our forums, mailing lists, and more]].
* [http://meego.com/about/contribution-guidelines Contribute to MeeGo].
* [[Build_Infrastructure/Community_Builder|Building applications]] for MeeGo

See also [[Who's who]].

== Meetings ==

[[MeeGo-Meeting IRC Schedule]]

The following groups have regular meetings, see their respective pages for details.

* [[Technical Steering Group meetings]]
* [[Community Office/Meetings|Community Office meetings]]
* [[Localization team]]

Regional Activities.
* [[Local MeeGo Networks]]

== Bi-Annual MeeGo Conference ==

'''Upcoming Conferences'''
* [[MeeGo Conference Spring 2011|Spring 2011: May 23 - 25 at the Hyatt Regency, San Francisco]]
* [[MeeGo Conference Fall 2011|Fall 2011: November Date TBD in Europe]]

'''Past Conference Wrap-Up Information'''
* [[MeeGo_Conference_2010|Fall 2010: November 15 - 17 in Dublin]]

== Structure and Governance ==

MeeGo is an open source project led by the MeeGo Technical Steering Group (TSG). The governance model is based on meritocracy and the best practices and values of the Open Source culture. The MeeGo project lives under the auspices of the Linux Foundation.

* [http://meego.com/about/governance MeeGo Project Structure and Governance Overview]
* Bi-weekly [[Technical Steering Group meetings]]
* [[Working Group Process]]

== Resources ==
* [[MeeGo FAQ]]
* [[Glossary|Glossary and Acronyms]]
* [[Community guidelines]]
* [[Special:PopularPages|Popular Wiki Pages]]
* [[Special:MostLinkedPages|Most Linked-to Pages]]

[[Category:Top level]]

MeeGo UX Components

2011-05-27T05:04:21Z

Btdrucke: /* API Documentation */

Components Migration

2011-05-02T17:33:54Z

Btdrucke:

==Migration of Components from MeeGo.Labs.Components to MeeGo.Components==
''PAGE UNDER CONSTRUCTION''

Currently some UX components exists in multiple repositories (repo meego-ux-components / namespace MeeGo.Components, repo meegolabs-ux-components / namespace MeeGo.Labs.Components and repo meego-media-components / namespace MeeGo.Media). It is confusing and difficult to maintain various forked versions of code. The solution is to deprecate duplicate versions so that we have only a single copy of each component.

In many cases, this mean applications need to replace components from MeeGo.Labs.Components and MeeGo.Media with their counterparts from MeeGo.Components, making API changes as necessary. In some cases, code has been copied to MeeGo.Components prematurely and will be deprecated in favor of the MeeGo.Labs version.

Component migration will occur in three phases:

==Component Migration Phase I==
Done as of April 9th.

* Deprecated MeeGo.Media pickers (image/video/music)
* Deprecated MeeGo.Labs.Components Date and Time pickers
* NB: Contacts picker will remain in MeeGo.Labs for the time being

==Components Migration Phase II==
This was originally scheduled to end April 22 but has been delayed to May 3rd
* Most duplicated components from MeeGo.Labs will be deprecated (see [[#Components Affected by Phase II]])
* Window and AppPage/ApplicationPage will not be migrated in this phase (see [[#Components Migration Phase III]] for information regarding these components)

Since most of the meego-ux-components depend on signals from the new meego-ux-components Window.qml, some of them will have issues when being used with the meegolabs Window.qml. The ModalContextMenu is our main problem child here.
We have added a Window2.qml to the meegolabs repo which is basically the meegolabs Window.qml, but with the orientation behaviour of the new meego-ux-components Window.qml. Just add the '2' behind Window to use it, no further API changes are necessary.
The ModalContextmenu called in the content area will now stay on screen. Of course Window2.qml does not have the full functionality of the meego-ux-components Window.qml, so there will still be a few bugs until you switch to the meego-ux-components Window.qml.
Bugs we found after a quick testing:
* the book and action menu context menus will still leave the screen/ appear in the wrong position when the orientation changes while they are visible.
* Some apps create their own status bar and tool bar:
** the panels view has two status bars.
** the photo apps detail page always shows its search bar.
These bugs should not be filed and will not be fixed since Window2.qml is only a preliminary solution for testing only!

===Components Affected by Phase II===
{|
|MeeGo Labs ||MeeGo-Ux-Components ||Changes
|-
|ActionMenu ||ActionMenu ||API changed
|-
|Button ||Button ||API and Design
|-
|CheckBox ||CheckBox ||API and Design
|-
|ContextMenu ||ModalContextMenu ||derived from ModalFog, API change
|-
|DropDown ||DropDown ||API and Design
|-
|EditPane ||TextField ||replace by TextField
|-
|ExpandingBox ||ExpandingBox ||API and Design
|-
|Fog ||ModalFog ||whole concept changed
|-
|IconButton ||IconButton ||API and Design
|-
|MessageBox ||ModalMesseageBox ||derived from ModalFog, API change
|-
|ModalDialog ||ModalDialog ||API and Design
|-
|ModalSurface ||ModalFog ||API and Design
|-
|PickerDialog ||ModalDialog ||-
|-
|PopupList ||PopupList ||API and Design
|-
|RadioButton ||RadioButton ||Design
|-
|RadioGroup.js ||RadioGroup.js ||Design
|-
|RadioGroup.qml ||RadioGroup.qml ||API and Design
|-
|Slider ||Slider ||API and Design
|-
|Spinner ||<same> ||ModalSpinner can be used for the full-screen use case
|-
|StatusBar ||StatusBar ||No changes
|-
|TextEntry ||TextEntry ||API and Design
|-
|ToggleButton ||ToggleButton ||API and Design
|-
|TopItem ||TopItem ||API
|-
|VerticalSlider ||VerticalSlider ||API and Design
|}

==Component Migration Phase III==
Was scheduled to end April 29, now May 6th. In this phase we deprecate MeeGo.Labs Window and ApplicationPage components to be replace by MeeGo.Components Window and AppPage.

A general change in the meego-ux-components is the concept of how to use Window
and AppPage in order to create a navigation path in your application. You
can find the examples and the tutorial in the devel package to help you understand
the concept.

Nonetheless some examples:

====Example for a Page.qml====
The AppPage is the content that's shown inside an apps window. Statusbar and toolbar are provided by the Window.qml as well as a default action menu. The pageTitle will appear in the Windows toolbar.
AppPage {
id: mainPage

pageTitle: "My first page"

actionMenuModel: [ "First choice", "Second choice" ]
actionMenuPayload: [ 1, 2 ]

onActionMenuTriggered: {
// an action menu entry was clicked, action menu hidden
// and '1' or '2' returned in selectedItem
}
}
You can call addPage(<nextPageName>) to switch to the next page.
AppPage {
(...)
Component { id: nextPage; SubPage{} }

onClicked: { addPage( nextPage ) }
(...)
}
The Window.qml provides a back button in the toolbar to get back to the previous page.

====Example for a MainWindow.qml====
The Window is the applications main item. It has a book menu to switch between main pages.
Window {
id: window

bookMenuModel: [ qsTr("Page 1") , qsTr("Page 2") ]
bookMenuPayload: [ book1Component, book2Component ]

Component.onCompleted: {
console.log("load MainPage")
switchBook( book1Component )
}

Component { id: book1Component; Page {} }
Component { id: book2Component; Page2 {} }
}
===Phase III major API changes for AppPage===
{|
! Meegolabs ApplicationPage
! meego-ux-components AppPage
|-
| variant windowModel || -
|-
| variant windowFilterPayload || -
|-
| string title || string pageTitle
|-
| item content || -
|-
| bool fullContent || bool fullContent
|-
| bool fullscreen || bool fullScreen
|-
| bool showSearch || -
|-
| bool disableSearch || -
|-
| bool showToolbar || -
|-
| bool hasBack || -
|-
| int toolbarHeight || -
|-
| bool moving || -
|-
| variant applicationData || -
|-
| int type || -
|-
| alias menuContent || variant actionMenuModel
|-
| alias menuItem || variant actionMenuPayload
|-
| - || string actionMenuTitle
|-
| alias menuWidth || -
|-
| alias menuHeight || -
|-
| function closeMenu() || -
|-
| signal close() || -
|-
| signal filterTriggered(int index, variant payload) || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| signal addApplicationPage(variant component) || -
|-
| signal search(string needle) || -
|}

===Phase III major API changes for Window:===
{|
! meegolabs Window
! meego-ux Window
|-
| bool foreground || bool isActiveWindow
|-
| bool transparent || -
|-
| string title || string toolBarTitle
|-
| string[] filterModel || string[] bookMenuModel
|-
| string[] filterPayload || string[] bookMenuPayload
|-
| - || string bookMenuTitle
|-
| - || bool bookMenuHighlightSelection
|-
| - || string[] actionMenuModel
|-
| - || string[] actionMenuPayload
|-
| - || string actionMenuTitle
|-
| - || bool actionMenuHighlightSelection
|-
| int filterMenuWidth || -
|-
| signal filterTriggered(int index, variant payload) || -
|-
| - || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| Component applicationPage || -
|-
| alias currentApplication || -
|-
| variant applicationData || -
|-
| item content: innerContent || -
|-
| item container: outerContent || -
|-
| int orientation || int orientation
|-
| bool orientationLocked || bool isOrientationLocked
|-
| bool orientationTransitionEnabled || -
|-
| - || string lockOrientationIn
|-
| bool fullScreen || bool fullScreen
|-
| bool fullContent || bool fullContent
|-
| bool showtoolbar || -
|-
| bool showsearch || -
|-
| signal search(string needle) || signal search(string needle)
|-
| alias statusBar || -
|-
| color backgroundColor || -
|-
| color sidepanelBackgroundColor || -
|-
| bool showStartupAnimation || -
|}

Components Migration

2011-05-02T16:56:30Z

Btdrucke: /* Phase II (schedule to end April 22) */

==Migration of Components from MeeGo.Labs.Components to MeeGo.Components==
''PAGE UNDER CONSTRUCTION''

Currently some UX components exists in multiple repositories (repo meego-ux-components / namespace MeeGo.Components, repo meegolabs-ux-components / namespace MeeGo.Labs.Components and repo meego-media-components / namespace MeeGo.Media). It is confusing and difficult to maintain various forked versions of code. The solution is to deprecate duplicate versions so that we have only a single copy of each component.

In many cases, this mean applications need to replace components from MeeGo.Labs.Components and MeeGo.Media with their counterparts from MeeGo.Components, making API changes as necessary. In some cases, code has been copied to MeeGo.Components prematurely and will be deprecated in favor of the MeeGo.Labs version.

Component migration will occur in three phases:

==Component Migration Phase I==
Done as of April 9th.

* Deprecated MeeGo.Media pickers (image/video/music)
* Deprecated MeeGo.Labs.Components Date and Time pickers
* NB: Contacts picker will remain in MeeGo.Labs for the time being

==Components Migration Phase II==
This was originally scheduled to end April 22 but has been delayed to May 3rd
* Most duplicated components from MeeGo.Labs will be deprecated (see [[#Components Affected by Phase II]])
* Window and AppPage/ApplicationPage will not be migrated in this phase (see [[#Components Migration Phase III]] for information regarding these components)

Since most of the meego-ux-components depend on signals from the new meego-ux-components Window.qml, some of them will have issues when being used with the meegolabs Window.qml. The ModalContextMenu is our main problem child here.
We have added a Window2.qml to the meegolabs repo which is basically the meegolabs Window.qml, but with the orientation behaviour of the new meego-ux-components Window.qml. Just add the '2' behind Window to use it, no further API changes are necessary.
The ModalContextmenu called in the content area will now stay on screen. Of course Window2.qml does not have the full functionality of the meego-ux-components Window.qml, so there will still be a few bugs until you switch to the meego-ux-components Window.qml.
Bugs we found after a quick testing:
* the book and action menu context menus will still leave the screen/ appear in the wrong position when the orientation changes while they are visible.
* Some apps create their own status bar and tool bar:
** the panels view has two status bars.
** the photo apps detail page always shows its search bar.
These bugs should not be filed and will not be fixed since Window2.qml is only a preliminary solution for testing only!

===Components Affected by Phase II===

{|
|MeeGo Labs ||MeeGo-Ux-Components ||Changes
|-
|ActionMenu ||ActionMenu ||API changed
|-
|Button ||Button ||API and Design
|-
|CheckBox ||CheckBox ||API and Design
|-
|ContextMenu ||ModalContextMenu ||derived from ModalFog, API change
|-
|DropDown ||DropDown ||API and Design
|-
|EditPane ||TextField ||replace by TextField
|-
|ExpandingBox ||ExpandingBox ||API and Design
|-
|Fog ||ModalFog ||whole concept changed
|-
|IconButton ||IconButton ||API and Design
|-
|MessageBox ||ModalMesseageBox ||derived from ModalFog, API change
|-
|ModalDialog ||ModalDialog ||API and Design
|-
|ModalSurface ||ModalFog ||API and Design
|-
|PickerDialog ||ModalDialog ||-
|-
|PopupList ||PopupList ||API and Design
|-
|RadioButton ||RadioButton ||Design
|-
|RadioGroup.js ||RadioGroup.js ||Design
|-
|RadioGroup.qml ||RadioGroup.qml ||API and Design
|-
|Slider ||Slider ||API and Design
|-
|Spinner ||<same> ||ModalSpinner can be used for the full-screen use case
|-
|StatusBar ||StatusBar ||No changes
|-
|TextEntry ||TextEntry ||API and Design
|-
|ToggleButton ||ToggleButton ||API and Design
|-
|TopItem ||TopItem ||API
|-
|VerticalSlider ||VerticalSlider ||API and Design
|}

==Phase III (scheduled to end April 29)==
* Window and AppPage components

===Window, Book and Page===

A general change in the meego-ux-components is the concept of how to use Window
and AppPage in order to create a navigation path in your application. You
can find the examples and the tutorial in the devel package to help you understand
the concept.

Nonetheless some examples:

====Example for a Page.qml====
The AppPage is the content that's shown inside an apps window. Statusbar and toolbar are provided by the Window.qml as well as a default action menu. The pageTitle will appear in the Windows toolbar.
AppPage {
id: mainPage

pageTitle: "My first page"

actionMenuModel: [ "First choice", "Second choice" ]
actionMenuPayload: [ 1, 2 ]

onActionMenuTriggered: {
// an action menu entry was clicked, action menu hidden
// and '1' or '2' returned in selectedItem
}
}
You can call addPage(<nextPageName>) to switch to the next page.
AppPage {
(...)
Component { id: nextPage; SubPage{} }

onClicked: { addPage( nextPage ) }
(...)
}
The Window.qml provides a back button in the toolbar to get back to the previous page.

====Example for a MainWindow.qml:====
The Window is the applications main item. It has a book menu to switch between main pages.
Window {
id: window

bookMenuModel: [ qsTr("Page 1") , qsTr("Page 2") ]
bookMenuPayload: [ book1Component, book2Component ]

Component.onCompleted: {
console.log("load MainPage")
switchBook( book1Component )
}

Component { id: book1Component; Page {} }
Component { id: book2Component; Page2 {} }
}
===Phase III major API changes for AppPage===
{|
! Meegolabs ApplicationPage
! meego-ux-components AppPage
|-
| variant windowModel || -
|-
| variant windowFilterPayload || -
|-
| string title || string pageTitle
|-
| item content || -
|-
| bool fullContent || bool fullContent
|-
| bool fullscreen || bool fullScreen
|-
| bool showSearch || -
|-
| bool disableSearch || -
|-
| bool showToolbar || -
|-
| bool hasBack || -
|-
| int toolbarHeight || -
|-
| bool moving || -
|-
| variant applicationData || -
|-
| int type || -
|-
| alias menuContent || variant actionMenuModel
|-
| alias menuItem || variant actionMenuPayload
|-
| - || string actionMenuTitle
|-
| alias menuWidth || -
|-
| alias menuHeight || -
|-
| function closeMenu() || -
|-
| signal close() || -
|-
| signal filterTriggered(int index, variant payload) || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| signal addApplicationPage(variant component) || -
|-
| signal search(string needle) || -
|}

===Phase III major API changes for Window:===
{|
! meegolabs Window
! meego-ux Window
|-
| bool foreground || bool isActiveWindow
|-
| bool transparent || -
|-
| string title || string toolBarTitle
|-
| string[] filterModel || string[] bookMenuModel
|-
| string[] filterPayload || string[] bookMenuPayload
|-
| - || string bookMenuTitle
|-
| - || bool bookMenuHighlightSelection
|-
| - || string[] actionMenuModel
|-
| - || string[] actionMenuPayload
|-
| - || string actionMenuTitle
|-
| - || bool actionMenuHighlightSelection
|-
| int filterMenuWidth || -
|-
| signal filterTriggered(int index, variant payload) || -
|-
| - || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| Component applicationPage || -
|-
| alias currentApplication || -
|-
| variant applicationData || -
|-
| item content: innerContent || -
|-
| item container: outerContent || -
|-
| int orientation || int orientation
|-
| bool orientationLocked || bool isOrientationLocked
|-
| bool orientationTransitionEnabled || -
|-
| - || string lockOrientationIn
|-
| bool fullScreen || bool fullScreen
|-
| bool fullContent || bool fullContent
|-
| bool showtoolbar || -
|-
| bool showsearch || -
|-
| signal search(string needle) || signal search(string needle)
|-
| alias statusBar || -
|-
| color backgroundColor || -
|-
| color sidepanelBackgroundColor || -
|-
| bool showStartupAnimation || -
|}

Components Migration

2011-05-02T16:49:30Z

Btdrucke: /* Phase I (done April 8th) */

==Migration of Components from MeeGo.Labs.Components to MeeGo.Components==
''PAGE UNDER CONSTRUCTION''

Currently some UX components exists in multiple repositories (repo meego-ux-components / namespace MeeGo.Components, repo meegolabs-ux-components / namespace MeeGo.Labs.Components and repo meego-media-components / namespace MeeGo.Media). It is confusing and difficult to maintain various forked versions of code. The solution is to deprecate duplicate versions so that we have only a single copy of each component.

In many cases, this mean applications need to replace components from MeeGo.Labs.Components and MeeGo.Media with their counterparts from MeeGo.Components, making API changes as necessary. In some cases, code has been copied to MeeGo.Components prematurely and will be deprecated in favor of the MeeGo.Labs version.

Component migration will occur in three phases:

==Component Migration Phase I==
Done as of April 9th.

* Deprecated MeeGo.Media pickers (image/video/music)
* Deprecated MeeGo.Labs.Components Date and Time pickers
* NB: Contacts picker will remain in MeeGo.Labs for the time being

==Phase II (schedule to end April 22)==
* all other duplicated components (see table below)
* Window and AppPage/ApplicationPage will not be migrated in this phase
* a Window2.qml is provided to test the new orientation behaviour

Since most of the meego-ux-components depend on signals from the new meego-ux-components Window.qml, some of them will have issues when being used with the meegolabs Window.qml. The ModalContextMenu is our main problem child here.
We have added a Window2.qml to the meegolabs repo which is basically the meegolabs Window.qml, but with the orientation behaviour of the new meego-ux-components Window.qml. Just add the '2' behind Window to use it, no further API changes are necessary.
The ModalContextmenu called in the content area will now stay on screen. Of course Window2.qml does not have the full functionality of the meego-ux-components Window.qml, so there will still be a few bugs until you switch to the meego-ux-components Window.qml.
Bugs we found after a quick testing:
* the book and action menu context menus will still leave the screen/ appear in the wrong position when the orientation changes while they are visible.
* Some apps create their own status bar and tool bar:
** the panels view has two status bars.
** the photo apps detail page always shows its search bar.
These bugs should not be filed and will not be fixed since Window2.qml is only a preliminary solution for testing only!

ATTENTION: The old components (see table below) from meegolabs will be removed on Tuesday(April 20) morning around 8:00 pacific time!

===Phase II Components Migration:===

{|
|MeeGo Labs ||MeeGo-Ux-Components ||Changes
|-
|ActionMenu ||ActionMenu ||API changed
|-
|Button ||Button ||API and Design
|-
|CheckBox ||CheckBox ||API and Design
|-
|ContextMenu ||ModalContextMenu ||derived from ModalFog, API change
|-
|DropDown ||DropDown ||API and Design
|-
|EditPane ||TextField ||replace by TextField
|-
|ExpandingBox ||ExpandingBox ||API and Design
|-
|Fog ||ModalFog ||whole concept changed
|-
|IconButton ||IconButton ||API and Design
|-
|MessageBox ||ModalMesseageBox ||derived from ModalFog, API change
|-
|ModalDialog ||ModalDialog ||API and Design
|-
|ModalSurface ||ModalFog ||API and Design
|-
|PickerDialog ||ModalDialog ||-
|-
|PopupList ||PopupList ||API and Design
|-
|RadioButton ||RadioButton ||Design
|-
|RadioGroup.js ||RadioGroup.js ||Design
|-
|RadioGroup.qml ||RadioGroup.qml ||API and Design
|-
|Slider ||Slider ||API and Design
|-
|Spinner ||Spinner ||No API changes
|-
|StatusBar ||StatusBar ||No changes
|-
|TextEntry ||TextEntry ||API and Design
|-
|ToggleButton ||ToggleButton ||API and Design
|-
|TopItem ||TopItem ||API
|-
|VerticalSlider ||VerticalSlider ||API and Design
|}

==Phase III (scheduled to end April 29)==
* Window and AppPage components

===Window, Book and Page===

A general change in the meego-ux-components is the concept of how to use Window
and AppPage in order to create a navigation path in your application. You
can find the examples and the tutorial in the devel package to help you understand
the concept.

Nonetheless some examples:

====Example for a Page.qml====
The AppPage is the content that's shown inside an apps window. Statusbar and toolbar are provided by the Window.qml as well as a default action menu. The pageTitle will appear in the Windows toolbar.
AppPage {
id: mainPage

pageTitle: "My first page"

actionMenuModel: [ "First choice", "Second choice" ]
actionMenuPayload: [ 1, 2 ]

onActionMenuTriggered: {
// an action menu entry was clicked, action menu hidden
// and '1' or '2' returned in selectedItem
}
}
You can call addPage(<nextPageName>) to switch to the next page.
AppPage {
(...)
Component { id: nextPage; SubPage{} }

onClicked: { addPage( nextPage ) }
(...)
}
The Window.qml provides a back button in the toolbar to get back to the previous page.

====Example for a MainWindow.qml:====
The Window is the applications main item. It has a book menu to switch between main pages.
Window {
id: window

bookMenuModel: [ qsTr("Page 1") , qsTr("Page 2") ]
bookMenuPayload: [ book1Component, book2Component ]

Component.onCompleted: {
console.log("load MainPage")
switchBook( book1Component )
}

Component { id: book1Component; Page {} }
Component { id: book2Component; Page2 {} }
}
===Phase III major API changes for AppPage===
{|
! Meegolabs ApplicationPage
! meego-ux-components AppPage
|-
| variant windowModel || -
|-
| variant windowFilterPayload || -
|-
| string title || string pageTitle
|-
| item content || -
|-
| bool fullContent || bool fullContent
|-
| bool fullscreen || bool fullScreen
|-
| bool showSearch || -
|-
| bool disableSearch || -
|-
| bool showToolbar || -
|-
| bool hasBack || -
|-
| int toolbarHeight || -
|-
| bool moving || -
|-
| variant applicationData || -
|-
| int type || -
|-
| alias menuContent || variant actionMenuModel
|-
| alias menuItem || variant actionMenuPayload
|-
| - || string actionMenuTitle
|-
| alias menuWidth || -
|-
| alias menuHeight || -
|-
| function closeMenu() || -
|-
| signal close() || -
|-
| signal filterTriggered(int index, variant payload) || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| signal addApplicationPage(variant component) || -
|-
| signal search(string needle) || -
|}

===Phase III major API changes for Window:===
{|
! meegolabs Window
! meego-ux Window
|-
| bool foreground || bool isActiveWindow
|-
| bool transparent || -
|-
| string title || string toolBarTitle
|-
| string[] filterModel || string[] bookMenuModel
|-
| string[] filterPayload || string[] bookMenuPayload
|-
| - || string bookMenuTitle
|-
| - || bool bookMenuHighlightSelection
|-
| - || string[] actionMenuModel
|-
| - || string[] actionMenuPayload
|-
| - || string actionMenuTitle
|-
| - || bool actionMenuHighlightSelection
|-
| int filterMenuWidth || -
|-
| signal filterTriggered(int index, variant payload) || -
|-
| - || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| Component applicationPage || -
|-
| alias currentApplication || -
|-
| variant applicationData || -
|-
| item content: innerContent || -
|-
| item container: outerContent || -
|-
| int orientation || int orientation
|-
| bool orientationLocked || bool isOrientationLocked
|-
| bool orientationTransitionEnabled || -
|-
| - || string lockOrientationIn
|-
| bool fullScreen || bool fullScreen
|-
| bool fullContent || bool fullContent
|-
| bool showtoolbar || -
|-
| bool showsearch || -
|-
| signal search(string needle) || signal search(string needle)
|-
| alias statusBar || -
|-
| color backgroundColor || -
|-
| color sidepanelBackgroundColor || -
|-
| bool showStartupAnimation || -
|}

Components Migration

2011-05-02T16:48:03Z

Btdrucke: /* Migration of Components from MeeGo.Labs.Components to MeeGo.Components */

==Migration of Components from MeeGo.Labs.Components to MeeGo.Components==
''PAGE UNDER CONSTRUCTION''

Currently some UX components exists in multiple repositories (repo meego-ux-components / namespace MeeGo.Components, repo meegolabs-ux-components / namespace MeeGo.Labs.Components and repo meego-media-components / namespace MeeGo.Media). It is confusing and difficult to maintain various forked versions of code. The solution is to deprecate duplicate versions so that we have only a single copy of each component.

In many cases, this mean applications need to replace components from MeeGo.Labs.Components and MeeGo.Media with their counterparts from MeeGo.Components, making API changes as necessary. In some cases, code has been copied to MeeGo.Components prematurely and will be deprecated in favor of the MeeGo.Labs version.

Component migration will occur in three phases:

==Phase I (done April 8th)==
* deprecate Media pickers (image/video/music)
* deprecate Date and Time pickers
* Contacts picker will remain in meegolabs-ux-components for the time being

==Phase II (schedule to end April 22)==
* all other duplicated components (see table below)
* Window and AppPage/ApplicationPage will not be migrated in this phase
* a Window2.qml is provided to test the new orientation behaviour

Since most of the meego-ux-components depend on signals from the new meego-ux-components Window.qml, some of them will have issues when being used with the meegolabs Window.qml. The ModalContextMenu is our main problem child here.
We have added a Window2.qml to the meegolabs repo which is basically the meegolabs Window.qml, but with the orientation behaviour of the new meego-ux-components Window.qml. Just add the '2' behind Window to use it, no further API changes are necessary.
The ModalContextmenu called in the content area will now stay on screen. Of course Window2.qml does not have the full functionality of the meego-ux-components Window.qml, so there will still be a few bugs until you switch to the meego-ux-components Window.qml.
Bugs we found after a quick testing:
* the book and action menu context menus will still leave the screen/ appear in the wrong position when the orientation changes while they are visible.
* Some apps create their own status bar and tool bar:
** the panels view has two status bars.
** the photo apps detail page always shows its search bar.
These bugs should not be filed and will not be fixed since Window2.qml is only a preliminary solution for testing only!

ATTENTION: The old components (see table below) from meegolabs will be removed on Tuesday(April 20) morning around 8:00 pacific time!

===Phase II Components Migration:===

{|
|MeeGo Labs ||MeeGo-Ux-Components ||Changes
|-
|ActionMenu ||ActionMenu ||API changed
|-
|Button ||Button ||API and Design
|-
|CheckBox ||CheckBox ||API and Design
|-
|ContextMenu ||ModalContextMenu ||derived from ModalFog, API change
|-
|DropDown ||DropDown ||API and Design
|-
|EditPane ||TextField ||replace by TextField
|-
|ExpandingBox ||ExpandingBox ||API and Design
|-
|Fog ||ModalFog ||whole concept changed
|-
|IconButton ||IconButton ||API and Design
|-
|MessageBox ||ModalMesseageBox ||derived from ModalFog, API change
|-
|ModalDialog ||ModalDialog ||API and Design
|-
|ModalSurface ||ModalFog ||API and Design
|-
|PickerDialog ||ModalDialog ||-
|-
|PopupList ||PopupList ||API and Design
|-
|RadioButton ||RadioButton ||Design
|-
|RadioGroup.js ||RadioGroup.js ||Design
|-
|RadioGroup.qml ||RadioGroup.qml ||API and Design
|-
|Slider ||Slider ||API and Design
|-
|Spinner ||Spinner ||No API changes
|-
|StatusBar ||StatusBar ||No changes
|-
|TextEntry ||TextEntry ||API and Design
|-
|ToggleButton ||ToggleButton ||API and Design
|-
|TopItem ||TopItem ||API
|-
|VerticalSlider ||VerticalSlider ||API and Design
|}

==Phase III (scheduled to end April 29)==
* Window and AppPage components

===Window, Book and Page===

A general change in the meego-ux-components is the concept of how to use Window
and AppPage in order to create a navigation path in your application. You
can find the examples and the tutorial in the devel package to help you understand
the concept.

Nonetheless some examples:

====Example for a Page.qml====
The AppPage is the content that's shown inside an apps window. Statusbar and toolbar are provided by the Window.qml as well as a default action menu. The pageTitle will appear in the Windows toolbar.
AppPage {
id: mainPage

pageTitle: "My first page"

actionMenuModel: [ "First choice", "Second choice" ]
actionMenuPayload: [ 1, 2 ]

onActionMenuTriggered: {
// an action menu entry was clicked, action menu hidden
// and '1' or '2' returned in selectedItem
}
}
You can call addPage(<nextPageName>) to switch to the next page.
AppPage {
(...)
Component { id: nextPage; SubPage{} }

onClicked: { addPage( nextPage ) }
(...)
}
The Window.qml provides a back button in the toolbar to get back to the previous page.

====Example for a MainWindow.qml:====
The Window is the applications main item. It has a book menu to switch between main pages.
Window {
id: window

bookMenuModel: [ qsTr("Page 1") , qsTr("Page 2") ]
bookMenuPayload: [ book1Component, book2Component ]

Component.onCompleted: {
console.log("load MainPage")
switchBook( book1Component )
}

Component { id: book1Component; Page {} }
Component { id: book2Component; Page2 {} }
}
===Phase III major API changes for AppPage===
{|
! Meegolabs ApplicationPage
! meego-ux-components AppPage
|-
| variant windowModel || -
|-
| variant windowFilterPayload || -
|-
| string title || string pageTitle
|-
| item content || -
|-
| bool fullContent || bool fullContent
|-
| bool fullscreen || bool fullScreen
|-
| bool showSearch || -
|-
| bool disableSearch || -
|-
| bool showToolbar || -
|-
| bool hasBack || -
|-
| int toolbarHeight || -
|-
| bool moving || -
|-
| variant applicationData || -
|-
| int type || -
|-
| alias menuContent || variant actionMenuModel
|-
| alias menuItem || variant actionMenuPayload
|-
| - || string actionMenuTitle
|-
| alias menuWidth || -
|-
| alias menuHeight || -
|-
| function closeMenu() || -
|-
| signal close() || -
|-
| signal filterTriggered(int index, variant payload) || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| signal addApplicationPage(variant component) || -
|-
| signal search(string needle) || -
|}

===Phase III major API changes for Window:===
{|
! meegolabs Window
! meego-ux Window
|-
| bool foreground || bool isActiveWindow
|-
| bool transparent || -
|-
| string title || string toolBarTitle
|-
| string[] filterModel || string[] bookMenuModel
|-
| string[] filterPayload || string[] bookMenuPayload
|-
| - || string bookMenuTitle
|-
| - || bool bookMenuHighlightSelection
|-
| - || string[] actionMenuModel
|-
| - || string[] actionMenuPayload
|-
| - || string actionMenuTitle
|-
| - || bool actionMenuHighlightSelection
|-
| int filterMenuWidth || -
|-
| signal filterTriggered(int index, variant payload) || -
|-
| - || signal actionMenuTriggered( variant selectedItem )
|-
| - || signal actionMenuIconClicked( int mouseX, int mouseY )
|-
| Component applicationPage || -
|-
| alias currentApplication || -
|-
| variant applicationData || -
|-
| item content: innerContent || -
|-
| item container: outerContent || -
|-
| int orientation || int orientation
|-
| bool orientationLocked || bool isOrientationLocked
|-
| bool orientationTransitionEnabled || -
|-
| - || string lockOrientationIn
|-
| bool fullScreen || bool fullScreen
|-
| bool fullContent || bool fullContent
|-
| bool showtoolbar || -
|-
| bool showsearch || -
|-
| signal search(string needle) || signal search(string needle)
|-
| alias statusBar || -
|-
| color backgroundColor || -
|-
| color sidepanelBackgroundColor || -
|-
| bool showStartupAnimation || -
|}

User:Jketreno/scaling

2011-04-26T08:25:16Z

Btdrucke: /* thoughts on asset theme scaling */

'''THIS PAGE IS A WORK IN PROGRESS AND DOES NOT NECESSARILY CORRESPOND TO CURRENT REALITY'''

=Introduction=
This document provides an overview of how applications can be written to support the broadest range of physical screen characteristics with the least amount of work by the application authors and graphic designers.

The intent is to provide a means of allowing applications to be written in a density independent manner, where the physical size of UI elements is consistent across a wide spectrum of devices. As automatic software scaling and conversion can not know the internal meaning of a graphics element (which pixels are important), pixel based assets must be designed for the lowest targeted pixels-per-inch (PPI). In this manner, system software can scale up to the actual device pixel density.

By following the guidelines in this document, application creators can create a single application package which will work across all devices, varying both in pixel density and physical screen sizes.

'''Lower priority:''' In addition to the varying densities targeted by MeeGo, the system should support various "distance-from-eye" scenarios as well as varying "input device resolution". An example of the former is a status bar on a tablet that is held 6-8" farther from the eyes than a handset--this may require that the status bar and fonts are slightly larger to maintain legibility. This may be achieved by providing a readability scaling factor used elements not intended to be manipulated via touch. An example of the later (varying input device resolution) is a scaling factor applied to the specified physical size of an element to accommodate higher precision devices (mice and stylus) as well as lower precision devices (gyro/accelerometer remotes, thumb-stick remotes, etc.)

==Target Resolutions and PPI==
The following image illustrates a small application running across the full range of screen sizes and densities currently supported by MeeGo. These images have been scaled to provide consistent relative sizing in the image. This was done by converting 1:1 pixel images to a virtual pixel density of 160ppi. Click the image to go to the higher resolution version.
[[Image:meego-units-example.png|center|thumb|400px|Density Independent Rendered Sample]]

A small 1:1 pixel crop from the highest density display (269ppi) and the lowest density (113ppi) can be seen here. When placed on the actual devices, the toolbar, buttons, and fonts would be physically the same size.
[[Image:meego-units-example-1to1.png|center|thumb|400px|1:1 Pixel Comparison]]

As can be seen in the table below, touch enabled MeeGo user experiences target two major physical screen size classifications; tablet (>7") and handset (~4"). In addition to the varying physical dimensions of the screens, the devices have various PPIs [dots-per-inch -- also referred to as PPI or pixels-per-inch]. Based on the expected frequency of deployment, we are focusing our "pixel perfect" UIs for only a select set of DPIs and screen resolutions.

==Current Device Resolutions==
The following provides examples of potential screen profiles which should be supported by MeeGo:
<table cellpadding="5px">
<tr><td colspan="5"><b>Handset</b></td><tr>
<tr style="font-style: italic;"><td>Diagonal</td><td>Resolution</td><td>PPI</td><td>Aspect Ratio</td></tr>
<tr><td>4"</td><td>800x480</td><td>233</td><td>15:9</td></tr>
<tr><td>4.3"</td><td>960x540</td><td>256</td><td>16:9</td></tr>
<tr><td>3.67"</td><td>864x480</td><td>269</td><td>16.2:9</td></tr>
<tr><td colspan="5"><b>Tablet</b></td><tr>
<tr style="font-style: italic;"><td>Diagonal</td><td>Resolution</td><td>PPI</td><td>Aspect Ratio</td></tr>
<tr><td>10"</td><td>1024x600</td><td>119</td><td>15.4:9</td></tr>
<tr><td>10"</td><td>1024x600</td><td>119</td><td>15.4:9</td></tr>
<tr><td>11.6"</td><td>1360x768</td><td>135</td><td>16:9</td></tr>
<tr><td>10"</td><td>1280x800</td><td>151</td><td>16:10</td></tr>
<tr><td>7"</td><td>1280x800</td><td>216</td><td>16:10</td></tr>
</table>
[http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density Industry list of display densities]

=Implementation Details=
==Getting the code==
git clone '''todo -- where is the code repository???'''
cd meego-units
qmake
make && sudo make install
==accessing the units==
To start, you need to import the MeeGo Units plug-in:
import Qt 4.7
import MeeGo.units 1.0
This loads the libmeegounitsplugin adds a new QML type called 'MeeGoUnits' Since plug-ins do not have direct access to the global object namespace, the plug-in can't automatically populate a top level namespace with a 'Units' element--so you must instantiate it within your top level widget:
Rectangle {
MeeGoUnits {
id: units
}
}
At this point, you can now reference the unit conversion properties via '''units'''. The properties exposed are '''mm''', '''inch''', '''vp''', and '''density'''. All three are implemented as properties with notification signals, so if the underlying device PPI changes, all UI elements can be re-laid out. This is useful when moving (at run-time) an application from a small handset screen to a larger display (for example via an attached HDMI)

Extending the above example to set the rectangle size to be 10cm x 5cm:
Rectangle {
MeeGoUnits {
id: units
}
width: units.mm2px(100.0)
height: units.mm2px(50.0)
}
Using the conversion properties is pretty straight forward and works as you would expect. The following instantiates a 1cm x 1cm rectangle, offset from the top left of its parent by 1cm:
Rectangle {
x: units.mm2px(10.0)
y: units.mm2px(10.0)
width: units.mm2px(10.0)
height: units.mm2px(10.0)
}

==a note on rounding==
Since the value of the properties returned by MeeGoUnits are non-integer (for example, units.mm might be '3.66667'), the result of most operations with the units will result in non-integer numbers as well. Due to the cast of real to int, you may encounter rounding problems which typically manifest themselves as QML Items not always lining up. This can be remedied by using the mm2px() conversion method exposed by the units object vs. using units.mm directly.

The following shows a simplified example which can lead to rounding problems:
Rectangle {
width: 20.0 * units.mm
height: 10.0 * units.mm
...
}
Better code:
Rectangle {
width: units.mm2px(20.0)
height: units.mm2px(10.0)
...
}

==text==
Text {
font.pixelSize: units.mm2px(2.5) // create text that is 2.5mm tall
text: "2.5mm font"
}

==images==
Image {
source: "text-bg.jpg"
width: units.mm2px(9.5)
height: units.mm2px(6.0)
sourceSize.width: units.mm2px(9.5)
sourceSize.height: units.mm2px(6.0)
}

==vector vs. raster==
==naming conventions==
==resource sharing==
==scaling==

User:Jketreno/theme-assets

2011-04-26T08:24:08Z

Btdrucke: /* thoughts on asset theme scaling */

'''THIS PAGE IS A WORK IN PROGRESS AND DOES NOT NECESSARILY CORRESPOND TO CURRENT REALITY'''

=Introduction=
The assets used in the visual design of our applications can be broken down into categories:

* Icons assets
* Non-Icon assets

Icons are typically fixed size and connote a contextual meaning. Non-icon assets are used as graphical filler; they provide the backgrounds, borders, and color but do not add any specific meaning.

This document covers the methodology and work-flow used by MeeGo to order to provide the highest quality visual experience on a broad spectrum of devices while developing icons and non-icon assets.

It is assumed that the reader is familiar with Density Independence. For a general overview of that topic, see [[~jketreno/scaling|Density Independence]].

=Graphical Theme Assets Details=
==Pixel vs. Vector==
There are two formats in which graphical assets can be provided for MeeGo: '''pixel''' and '''vector'''.

'''Pixel''' (sometimes referred to as raster) assets specify the ARGB color values of each individual pixel. The quality of what the user sees on their display is heavily dependent on the display density for which the graphical asset was designed. When designed for a 300DPI screen, an icon intended to be one 1/2" x 1/2" will need to be 150x150 pixels. When viewed on a 150DPI screen, in order to maintain the same physical size, the asset will need to be scaled down by 50%. The MeeGo theming image provider will perform this scaling for applications, using a smooth scaling algorithm to reduce artifacts. Designing for a high DPI and scaling down is the recommended technique for pixel based graphics.

'''Vector''' (sometimes referred to as scalable) assets are specified by paths defined by mathematical equations and are effectively resolution independent which means they can be rasterized at varying densities and sizes without introducing scaling artifacts.

===Virtual Pixel===
As vector graphics are density independent, there needs to be a way to map the units used within the vector graphic to physical pixels during rasterization. MeeGo accomplishes this by using a default virtual density of 330 pixels per inch for vector graphics. This allows the vector graphic to use any real world unit of measure desired while allowing [[~jketreno/theme-assets#Border_Images|Border Images]] (which may be relative to the rasterized vector graphic) to be specified in a density independent manner.

==Recommended usages for pixel and vector assets==
Icons, which are typically only scaled to maintain a consistent physical size on the display (for example a button icon which should always be 8mm x 8mm, regardless of the device DPI) should be provided as a pixel asset. If the asset is designed for a high density display, there will be minimal artifacts when scaled down to lower density displays. MeeGo will automatically scale pixel assets to new sizes as needed. See the section on [[~jketreno/theme-assets#dynamic asset scaling|Dynamic Asset Scaling]] for details on how this is accomplished.

Non-icon assets, which may be arbitrarily scaled in X and Y dimension, are best provided as a vector graphic. This is to reduce banding and aliasing artifacts which would typically occur in gradients, drop shadows, and other effects.

MeeGo provides a caching mechanism to alleviate the cost of rasterizing a vector asset.

===Downscaling Example===
The following example illustrates a possible pitfall if fine line details are used when drawing pixel graphics at higher DPI screens

[[File:downscaling-example.png|border|center|148px|Downscaling from 330DPI to 165DPI]]
Above illustrates scaling of a pixel asset from 330DPI to various DPIs.

[[File:scalable-example.png|frame|center|446px|Downscaling a 9mm x 9mm asset from 330DPI to 110DPI]]

===Upscaling Example===
The effect of upscaling a pixel vs. vector asset is shown here:

[[File:scalable-vs-pixel.png|border|center|512px|Pixel vs. Scalable]]

In the above example the 32x32 red circle, with a one pixel border, was scaled to be four times larger. Applying a cubic filter helps to reduce aliasing but muddies the result.

The vector asset is very clean at the new target size.

There are a few reasons why vector graphics are not used everywhere:

# Time -- Some artistic techniques are difficult to express in terms of paths, fills, and filters. Requiring all assets to always be provided in a scalable form places undo restrictions on the graphic designer.
# Compatibility -- some paths, fills, and filters do not produce the same results in the tools building them and the software used in MeeGo to rasterize the asset.

===Dynamic Asset Scaling===

'''todo''' Describe the logic flow for pixel asset priority, vector priority, scaling, interleaving, etc.

==Icon Assets==
===Editing and naming conventions===
Icons for MeeGo have two states:
* normal
* active
Providing a separate for each state is error prone and inefficient. For designers, it requires that multiple files be opened and managed visually which makes quick changes and uniformity more difficult. For loading efficiency, the more files that have to be opened and read, the slower the system behaves.

To improve on this, MeeGo icons provide both states in a single graphical asset. QML elements which use the Icons for button states rely on other means (background colors, alpha overlays, etc.) to provide additional state visualizations (mainly selected and disabled.)

Eventually MeeGo will provide an icon tile management layer to preload all rasterized assets into a large texture set which can be loaded once and then sliced at run-time.
====Pixel based assets====
For pixel based icon assets the following naming convention is used:
icon-NAME-multistate.EXTENSION
Where:
* '''NAME''' is the icon name, for example "close"
* '''EXTENSION''' is one of the recognized image extensions. While the system supports both PNG and JPG, it is recommended that only PNG be used.

In terms of a regular expression, the above maps to:
<nowiki>icon-[[:alnum:]]+multistate.(png|jpg)</nowiki>

The graphical asset is laid out internally such that the pixel width of the individual icon is the width of the total asset divided by two.. For example:

[[File:icon-close-multistate.png|border|120px|center|icon-close-multistate.png]]

The above file ('''icon-close-multistate.png''') provides a 120x50 pixel icon asset. Each icon is then 60x50 pixels.

====Scalable assets====
For scalable icon assets, the naming convention is much simpler:
icon-NAME-multistate.svg
Where:
* '''NAME''' is the icon name, for example "back"
MeeGo will parse the SVG looking for three top level groups with the following names:
* normal
* active

==Non-Icon Assets==
Non-Icon assets (such as button backgrounds, borders, drop shadows)

===Border Images===
When a non-icon asset is used as an element background image, it is scaled to fill the entire element. The scaling is applied uniformly across the entire asset. For assets that contain a border, this uniform scaling is not what is typically desired. MeeGo provides a mechanism for the asset designer to specify the region of the graphical element that should be stretched and the region which should not be scaled. These types of graphic assets are referred to as a "Border Image"

[[File:border-slicing.png|frame|center|Border Image]]

In the above image, a 4 pixel border is provided on all sides. When scaled to arbitrary sizes, scaling is only applied to non-border portions:

[[File:border-streched.png|frame|center|Border Image -- Scaled to 200x32]]

====Border Image Specification====
Two approaches:
* Per-asset .sci file provided which contains the border widths. For example:
$ cat background.sci
border.left: 5
border.right: 5
border.top: 5
border.bottom: 5
source:background.png
* Per-directory .sci file. For example:
$ cat index.sci
# Format:
# image-source top right bottom left
background.png 5 5 5 5
foreground.png 10 2 10 2

To refrence '''background.png''' with the border image properties, QML would refer to the virtual asset '''background.png.sci'''.

If both an index.sci and a separate asset .sci file are provided, the separate file will override the index.sci.

====Border Image: Pixel vs. Vector====
Image slicing for pixel assets are specified in pixels which means the border element is not scaled relative to the screen pixel density. The measurable size of a border on a high density display will be smaller than a display with a lower density.

With vector assets, the border size is specified in a virtual pixel representing 330 pixels per inch. This allows MeeGo to scale the border region proportional with the display density, ensuring a uniform look across multiple display profiles.

=thoughts on asset theme scaling=
/* Not done yet -- auto scaling and caching from an asset daemon with target size scaling:
*
* source: "image://" + unit + "/" + w + "x" + h "/text-bg"
*

// Every image used could be a BorderImage
BorderImage {
width: 1024
height: 768
source: "image://super[/dimensions[/units]]/resource[.ext]" <-- Optional extension to override the default priority ordering
source: "image://super/100x75/resource" <-- width is 100 pixels, height 75 pixels
source: "image://super/2.5x2.0/mm/resource" <-- width is 2.5 millimeters, height is 2.0 millimeters
source: theme.avatar.source <-- width and height is specified by the theme
}

theme.avatar contains:
{
width <--- In pixels
height <--- In pixels
source <--- Uses the uber theme image provider
}

width: 20 <--- hard coded, non density independent
width: mm2px(5) <---hard coded, density independent
width: theme.avatar.width <--- theme over-ridable, density independent

--------------

supporting the scaled size of the border in a border image via the theme; probably requires creating a new "borderimage" replacement that supports a set of target border size properties. Usage example is to take a 1px border from a pixel asset and have the border actually scaled to 2mm on the display

*
* So, instead, set the source width and height to the scaled dimensions : */

=MeeGo Theming Specifics=
==Directory structure==
==Naming conventions==
==Installation process==
==Tile cache==

=MeeGo Theming in Applications=
==MeeGo.Components==
==Density Independence==
==Fonts==
==MeeGo Image Providers==
'''todo''' describe how and where assets are placed into the distribution, how they are rasterized, where cached assets are stored, how tile caches are built, and how the image loaders tie it all together...

=Tool compatibility=
Graphic designers use a variety of tools, depending on personal preference and the task at hand. Not all features exposed by some tools are compatible with other tools, or with the infrastructure used on MeeGo for extracting and managing visual assets. This section is intended to call out known compatibility issues and work arounds.
==Photoshop==
==Gimp==
==Illustrator==
==Inkscape==

User:Jketreno/theme-assets

2011-04-26T08:23:32Z

Btdrucke: /* Border Image: Pixel vs. Vector */

'''THIS PAGE IS A WORK IN PROGRESS AND DOES NOT NECESSARILY CORRESPOND TO CURRENT REALITY'''

=Introduction=
The assets used in the visual design of our applications can be broken down into categories:

* Icons assets
* Non-Icon assets

Icons are typically fixed size and connote a contextual meaning. Non-icon assets are used as graphical filler; they provide the backgrounds, borders, and color but do not add any specific meaning.

This document covers the methodology and work-flow used by MeeGo to order to provide the highest quality visual experience on a broad spectrum of devices while developing icons and non-icon assets.

It is assumed that the reader is familiar with Density Independence. For a general overview of that topic, see [[~jketreno/scaling|Density Independence]].

=Graphical Theme Assets Details=
==Pixel vs. Vector==
There are two formats in which graphical assets can be provided for MeeGo: '''pixel''' and '''vector'''.

'''Pixel''' (sometimes referred to as raster) assets specify the ARGB color values of each individual pixel. The quality of what the user sees on their display is heavily dependent on the display density for which the graphical asset was designed. When designed for a 300DPI screen, an icon intended to be one 1/2" x 1/2" will need to be 150x150 pixels. When viewed on a 150DPI screen, in order to maintain the same physical size, the asset will need to be scaled down by 50%. The MeeGo theming image provider will perform this scaling for applications, using a smooth scaling algorithm to reduce artifacts. Designing for a high DPI and scaling down is the recommended technique for pixel based graphics.

'''Vector''' (sometimes referred to as scalable) assets are specified by paths defined by mathematical equations and are effectively resolution independent which means they can be rasterized at varying densities and sizes without introducing scaling artifacts.

===Virtual Pixel===
As vector graphics are density independent, there needs to be a way to map the units used within the vector graphic to physical pixels during rasterization. MeeGo accomplishes this by using a default virtual density of 330 pixels per inch for vector graphics. This allows the vector graphic to use any real world unit of measure desired while allowing [[~jketreno/theme-assets#Border_Images|Border Images]] (which may be relative to the rasterized vector graphic) to be specified in a density independent manner.

==Recommended usages for pixel and vector assets==
Icons, which are typically only scaled to maintain a consistent physical size on the display (for example a button icon which should always be 8mm x 8mm, regardless of the device DPI) should be provided as a pixel asset. If the asset is designed for a high density display, there will be minimal artifacts when scaled down to lower density displays. MeeGo will automatically scale pixel assets to new sizes as needed. See the section on [[~jketreno/theme-assets#dynamic asset scaling|Dynamic Asset Scaling]] for details on how this is accomplished.

Non-icon assets, which may be arbitrarily scaled in X and Y dimension, are best provided as a vector graphic. This is to reduce banding and aliasing artifacts which would typically occur in gradients, drop shadows, and other effects.

MeeGo provides a caching mechanism to alleviate the cost of rasterizing a vector asset.

===Downscaling Example===
The following example illustrates a possible pitfall if fine line details are used when drawing pixel graphics at higher DPI screens

[[File:downscaling-example.png|border|center|148px|Downscaling from 330DPI to 165DPI]]
Above illustrates scaling of a pixel asset from 330DPI to various DPIs.

[[File:scalable-example.png|frame|center|446px|Downscaling a 9mm x 9mm asset from 330DPI to 110DPI]]

===Upscaling Example===
The effect of upscaling a pixel vs. vector asset is shown here:

[[File:scalable-vs-pixel.png|border|center|512px|Pixel vs. Scalable]]

In the above example the 32x32 red circle, with a one pixel border, was scaled to be four times larger. Applying a cubic filter helps to reduce aliasing but muddies the result.

The vector asset is very clean at the new target size.

There are a few reasons why vector graphics are not used everywhere:

# Time -- Some artistic techniques are difficult to express in terms of paths, fills, and filters. Requiring all assets to always be provided in a scalable form places undo restrictions on the graphic designer.
# Compatibility -- some paths, fills, and filters do not produce the same results in the tools building them and the software used in MeeGo to rasterize the asset.

===Dynamic Asset Scaling===

'''todo''' Describe the logic flow for pixel asset priority, vector priority, scaling, interleaving, etc.

==Icon Assets==
===Editing and naming conventions===
Icons for MeeGo have two states:
* normal
* active
Providing a separate for each state is error prone and inefficient. For designers, it requires that multiple files be opened and managed visually which makes quick changes and uniformity more difficult. For loading efficiency, the more files that have to be opened and read, the slower the system behaves.

To improve on this, MeeGo icons provide both states in a single graphical asset. QML elements which use the Icons for button states rely on other means (background colors, alpha overlays, etc.) to provide additional state visualizations (mainly selected and disabled.)

Eventually MeeGo will provide an icon tile management layer to preload all rasterized assets into a large texture set which can be loaded once and then sliced at run-time.
====Pixel based assets====
For pixel based icon assets the following naming convention is used:
icon-NAME-multistate.EXTENSION
Where:
* '''NAME''' is the icon name, for example "close"
* '''EXTENSION''' is one of the recognized image extensions. While the system supports both PNG and JPG, it is recommended that only PNG be used.

In terms of a regular expression, the above maps to:
<nowiki>icon-[[:alnum:]]+multistate.(png|jpg)</nowiki>

The graphical asset is laid out internally such that the pixel width of the individual icon is the width of the total asset divided by two.. For example:

[[File:icon-close-multistate.png|border|120px|center|icon-close-multistate.png]]

The above file ('''icon-close-multistate.png''') provides a 120x50 pixel icon asset. Each icon is then 60x50 pixels.

====Scalable assets====
For scalable icon assets, the naming convention is much simpler:
icon-NAME-multistate.svg
Where:
* '''NAME''' is the icon name, for example "back"
MeeGo will parse the SVG looking for three top level groups with the following names:
* normal
* active

==Non-Icon Assets==
Non-Icon assets (such as button backgrounds, borders, drop shadows)

===Border Images===
When a non-icon asset is used as an element background image, it is scaled to fill the entire element. The scaling is applied uniformly across the entire asset. For assets that contain a border, this uniform scaling is not what is typically desired. MeeGo provides a mechanism for the asset designer to specify the region of the graphical element that should be stretched and the region which should not be scaled. These types of graphic assets are referred to as a "Border Image"

[[File:border-slicing.png|frame|center|Border Image]]

In the above image, a 4 pixel border is provided on all sides. When scaled to arbitrary sizes, scaling is only applied to non-border portions:

[[File:border-streched.png|frame|center|Border Image -- Scaled to 200x32]]

====Border Image Specification====
Two approaches:
* Per-asset .sci file provided which contains the border widths. For example:
$ cat background.sci
border.left: 5
border.right: 5
border.top: 5
border.bottom: 5
source:background.png
* Per-directory .sci file. For example:
$ cat index.sci
# Format:
# image-source top right bottom left
background.png 5 5 5 5
foreground.png 10 2 10 2

To refrence '''background.png''' with the border image properties, QML would refer to the virtual asset '''background.png.sci'''.

If both an index.sci and a separate asset .sci file are provided, the separate file will override the index.sci.

====Border Image: Pixel vs. Vector====
Image slicing for pixel assets are specified in pixels which means the border element is not scaled relative to the screen pixel density. The measurable size of a border on a high density display will be smaller than a display with a lower density.

With vector assets, the border size is specified in a virtual pixel representing 330 pixels per inch. This allows MeeGo to scale the border region proportional with the display density, ensuring a uniform look across multiple display profiles.

===thoughts on asset theme scaling===
/* Not done yet -- auto scaling and caching from an asset daemon with target size scaling:
*
* source: "image://" + unit + "/" + w + "x" + h "/text-bg"
*

// Every image used could be a BorderImage
BorderImage {
width: 1024
height: 768
source: "image://super[/dimensions[/units]]/resource[.ext]" <-- Optional extension to override the default priority ordering
source: "image://super/100x75/resource" <-- width is 100 pixels, height 75 pixels
source: "image://super/2.5x2.0/mm/resource" <-- width is 2.5 millimeters, height is 2.0 millimeters
source: theme.avatar.source <-- width and height is specified by the theme
}

theme.avatar contains:
{
width <--- In pixels
height <--- In pixels
source <--- Uses the uber theme image provider
}

width: 20 <--- hard coded, non density independent
width: mm2px(5) <---hard coded, density independent
width: theme.avatar.width <--- theme over-ridable, density independent

--------------

supporting the scaled size of the border in a border image via the theme; probably requires creating a new "borderimage" replacement that supports a set of target border size properties. Usage example is to take a 1px border from a pixel asset and have the border actually scaled to 2mm on the display

*
* So, instead, set the source width and height to the scaled dimensions : */

=MeeGo Theming Specifics=
==Directory structure==
==Naming conventions==
==Installation process==
==Tile cache==

=MeeGo Theming in Applications=
==MeeGo.Components==
==Density Independence==
==Fonts==
==MeeGo Image Providers==
'''todo''' describe how and where assets are placed into the distribution, how they are rasterized, where cached assets are stored, how tile caches are built, and how the image loaders tie it all together...

=Tool compatibility=
Graphic designers use a variety of tools, depending on personal preference and the task at hand. Not all features exposed by some tools are compatible with other tools, or with the infrastructure used on MeeGo for extracting and managing visual assets. This section is intended to call out known compatibility issues and work arounds.
==Photoshop==
==Gimp==
==Illustrator==
==Inkscape==

User:Jketreno/scaling

2011-04-26T08:21:15Z

Btdrucke: /* thoughts on asset theme scaling */

'''THIS PAGE IS A WORK IN PROGRESS AND DOES NOT NECESSARILY CORRESPOND TO CURRENT REALITY'''

=Introduction=
This document provides an overview of how applications can be written to support the broadest range of physical screen characteristics with the least amount of work by the application authors and graphic designers.

The intent is to provide a means of allowing applications to be written in a density independent manner, where the physical size of UI elements is consistent across a wide spectrum of devices. As automatic software scaling and conversion can not know the internal meaning of a graphics element (which pixels are important), pixel based assets must be designed for the lowest targeted pixels-per-inch (PPI). In this manner, system software can scale up to the actual device pixel density.

By following the guidelines in this document, application creators can create a single application package which will work across all devices, varying both in pixel density and physical screen sizes.

'''Lower priority:''' In addition to the varying densities targeted by MeeGo, the system should support various "distance-from-eye" scenarios as well as varying "input device resolution". An example of the former is a status bar on a tablet that is held 6-8" farther from the eyes than a handset--this may require that the status bar and fonts are slightly larger to maintain legibility. This may be achieved by providing a readability scaling factor used elements not intended to be manipulated via touch. An example of the later (varying input device resolution) is a scaling factor applied to the specified physical size of an element to accommodate higher precision devices (mice and stylus) as well as lower precision devices (gyro/accelerometer remotes, thumb-stick remotes, etc.)

==Target Resolutions and PPI==
The following image illustrates a small application running across the full range of screen sizes and densities currently supported by MeeGo. These images have been scaled to provide consistent relative sizing in the image. This was done by converting 1:1 pixel images to a virtual pixel density of 160ppi. Click the image to go to the higher resolution version.
[[Image:meego-units-example.png|center|thumb|400px|Density Independent Rendered Sample]]

A small 1:1 pixel crop from the highest density display (269ppi) and the lowest density (113ppi) can be seen here. When placed on the actual devices, the toolbar, buttons, and fonts would be physically the same size.
[[Image:meego-units-example-1to1.png|center|thumb|400px|1:1 Pixel Comparison]]

As can be seen in the table below, touch enabled MeeGo user experiences target two major physical screen size classifications; tablet (>7") and handset (~4"). In addition to the varying physical dimensions of the screens, the devices have various PPIs [dots-per-inch -- also referred to as PPI or pixels-per-inch]. Based on the expected frequency of deployment, we are focusing our "pixel perfect" UIs for only a select set of DPIs and screen resolutions.

==Current Device Resolutions==
The following provides examples of potential screen profiles which should be supported by MeeGo:
<table cellpadding="5px">
<tr><td colspan="5"><b>Handset</b></td><tr>
<tr style="font-style: italic;"><td>Diagonal</td><td>Resolution</td><td>PPI</td><td>Aspect Ratio</td></tr>
<tr><td>4"</td><td>800x480</td><td>233</td><td>15:9</td></tr>
<tr><td>4.3"</td><td>960x540</td><td>256</td><td>16:9</td></tr>
<tr><td>3.67"</td><td>864x480</td><td>269</td><td>16.2:9</td></tr>
<tr><td colspan="5"><b>Tablet</b></td><tr>
<tr style="font-style: italic;"><td>Diagonal</td><td>Resolution</td><td>PPI</td><td>Aspect Ratio</td></tr>
<tr><td>10"</td><td>1024x600</td><td>119</td><td>15.4:9</td></tr>
<tr><td>10"</td><td>1024x600</td><td>119</td><td>15.4:9</td></tr>
<tr><td>11.6"</td><td>1360x768</td><td>135</td><td>16:9</td></tr>
<tr><td>10"</td><td>1280x800</td><td>151</td><td>16:10</td></tr>
<tr><td>7"</td><td>1280x800</td><td>216</td><td>16:10</td></tr>
</table>
[http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density Industry list of display densities]

=Implementation Details=
==Getting the code==
git clone '''todo -- where is the code repository???'''
cd meego-units
qmake
make && sudo make install
==accessing the units==
To start, you need to import the MeeGo Units plug-in:
import Qt 4.7
import MeeGo.units 1.0
This loads the libmeegounitsplugin adds a new QML type called 'MeeGoUnits' Since plug-ins do not have direct access to the global object namespace, the plug-in can't automatically populate a top level namespace with a 'Units' element--so you must instantiate it within your top level widget:
Rectangle {
MeeGoUnits {
id: units
}
}
At this point, you can now reference the unit conversion properties via '''units'''. The properties exposed are '''mm''', '''inch''', '''vp''', and '''density'''. All three are implemented as properties with notification signals, so if the underlying device PPI changes, all UI elements can be re-laid out. This is useful when moving (at run-time) an application from a small handset screen to a larger display (for example via an attached HDMI)

Extending the above example to set the rectangle size to be 10cm x 5cm:
Rectangle {
MeeGoUnits {
id: units
}
width: units.mm2px(100.0)
height: units.mm2px(50.0)
}
Using the conversion properties is pretty straight forward and works as you would expect. The following instantiates a 1cm x 1cm rectangle, offset from the top left of its parent by 1cm:
Rectangle {
x: units.mm2px(10.0)
y: units.mm2px(10.0)
width: units.mm2px(10.0)
height: units.mm2px(10.0)
}

==a note on rounding==
Since the value of the properties returned by MeeGoUnits are non-integer (for example, units.mm might be '3.66667'), the result of most operations with the units will result in non-integer numbers as well. Due to the cast of real to int, you may encounter rounding problems which typically manifest themselves as QML Items not always lining up. This can be remedied by using the mm2px() conversion method exposed by the units object vs. using units.mm directly.

The following shows a simplified example which can lead to rounding problems:
Rectangle {
width: 20.0 * units.mm
height: 10.0 * units.mm
...
}
Better code:
Rectangle {
width: units.mm2px(20.0)
height: units.mm2px(10.0)
...
}

==text==
Text {
font.pixelSize: units.mm2px(2.5) // create text that is 2.5mm tall
text: "2.5mm font"
}

==images==
Image {
source: "text-bg.jpg"
width: units.mm2px(9.5)
height: units.mm2px(6.0)
sourceSize.width: units.mm2px(9.5)
sourceSize.height: units.mm2px(6.0)
}

===thoughts on asset theme scaling===
/* Not done yet -- auto scaling and caching from an asset daemon with target size scaling:
*
* source: "image://" + unit + "/" + w + "x" + h "/text-bg"
*

// Every image used could be a BorderImage
BorderImage {
width: 1024
height: 768
source: "image://super[/dimensions[/units]]/resource[.ext]" <-- Optional extension to override the default priority ordering
source: "image://super/100x75/resource" <-- width is 100 pixels, height 75 pixels
source: "image://super/2.5x2.0/mm/resource" <-- width is 2.5 millimeters, height is 2.0 millimeters
source: theme.avatar.source <-- width and height is specified by the theme
}

theme.avatar contains:
{
width <--- In pixels
height <--- In pixels
source <--- Uses the uber theme image provider
}

width: 20 <--- hard coded, non density independent
width: mm2px(5) <---hard coded, density independent
width: theme.avatar.width <--- theme over-ridable, density independent

--------------

supporting the scaled size of the border in a border image via the theme; probably requires creating a new "borderimage" replacement that supports a set of target border size properties. Usage example is to take a 1px border from a pixel asset and have the border actually scaled to 2mm on the display

*
* So, instead, set the source width and height to the scaled dimensions : */

==vector vs. raster==
==naming conventions==
==resource sharing==
==scaling==

User:Jketreno/scaling

2011-04-26T08:16:03Z

Btdrucke: /* thoughts on asset theme scaling */

'''THIS PAGE IS A WORK IN PROGRESS AND DOES NOT NECESSARILY CORRESPOND TO CURRENT REALITY'''

=Introduction=
This document provides an overview of how applications can be written to support the broadest range of physical screen characteristics with the least amount of work by the application authors and graphic designers.

The intent is to provide a means of allowing applications to be written in a density independent manner, where the physical size of UI elements is consistent across a wide spectrum of devices. As automatic software scaling and conversion can not know the internal meaning of a graphics element (which pixels are important), pixel based assets must be designed for the lowest targeted pixels-per-inch (PPI). In this manner, system software can scale up to the actual device pixel density.

By following the guidelines in this document, application creators can create a single application package which will work across all devices, varying both in pixel density and physical screen sizes.

'''Lower priority:''' In addition to the varying densities targeted by MeeGo, the system should support various "distance-from-eye" scenarios as well as varying "input device resolution". An example of the former is a status bar on a tablet that is held 6-8" farther from the eyes than a handset--this may require that the status bar and fonts are slightly larger to maintain legibility. This may be achieved by providing a readability scaling factor used elements not intended to be manipulated via touch. An example of the later (varying input device resolution) is a scaling factor applied to the specified physical size of an element to accommodate higher precision devices (mice and stylus) as well as lower precision devices (gyro/accelerometer remotes, thumb-stick remotes, etc.)

==Target Resolutions and PPI==
The following image illustrates a small application running across the full range of screen sizes and densities currently supported by MeeGo. These images have been scaled to provide consistent relative sizing in the image. This was done by converting 1:1 pixel images to a virtual pixel density of 160ppi. Click the image to go to the higher resolution version.
[[Image:meego-units-example.png|center|thumb|400px|Density Independent Rendered Sample]]

A small 1:1 pixel crop from the highest density display (269ppi) and the lowest density (113ppi) can be seen here. When placed on the actual devices, the toolbar, buttons, and fonts would be physically the same size.
[[Image:meego-units-example-1to1.png|center|thumb|400px|1:1 Pixel Comparison]]

As can be seen in the table below, touch enabled MeeGo user experiences target two major physical screen size classifications; tablet (>7") and handset (~4"). In addition to the varying physical dimensions of the screens, the devices have various PPIs [dots-per-inch -- also referred to as PPI or pixels-per-inch]. Based on the expected frequency of deployment, we are focusing our "pixel perfect" UIs for only a select set of DPIs and screen resolutions.

==Current Device Resolutions==
The following provides examples of potential screen profiles which should be supported by MeeGo:
<table cellpadding="5px">
<tr><td colspan="5"><b>Handset</b></td><tr>
<tr style="font-style: italic;"><td>Diagonal</td><td>Resolution</td><td>PPI</td><td>Aspect Ratio</td></tr>
<tr><td>4"</td><td>800x480</td><td>233</td><td>15:9</td></tr>
<tr><td>4.3"</td><td>960x540</td><td>256</td><td>16:9</td></tr>
<tr><td>3.67"</td><td>864x480</td><td>269</td><td>16.2:9</td></tr>
<tr><td colspan="5"><b>Tablet</b></td><tr>
<tr style="font-style: italic;"><td>Diagonal</td><td>Resolution</td><td>PPI</td><td>Aspect Ratio</td></tr>
<tr><td>10"</td><td>1024x600</td><td>119</td><td>15.4:9</td></tr>
<tr><td>10"</td><td>1024x600</td><td>119</td><td>15.4:9</td></tr>
<tr><td>11.6"</td><td>1360x768</td><td>135</td><td>16:9</td></tr>
<tr><td>10"</td><td>1280x800</td><td>151</td><td>16:10</td></tr>
<tr><td>7"</td><td>1280x800</td><td>216</td><td>16:10</td></tr>
</table>
[http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density Industry list of display densities]

=Implementation Details=
==Getting the code==
git clone '''todo -- where is the code repository???'''
cd meego-units
qmake
make && sudo make install
==accessing the units==
To start, you need to import the MeeGo Units plug-in:
import Qt 4.7
import MeeGo.units 1.0
This loads the libmeegounitsplugin adds a new QML type called 'MeeGoUnits' Since plug-ins do not have direct access to the global object namespace, the plug-in can't automatically populate a top level namespace with a 'Units' element--so you must instantiate it within your top level widget:
Rectangle {
MeeGoUnits {
id: units
}
}
At this point, you can now reference the unit conversion properties via '''units'''. The properties exposed are '''mm''', '''inch''', '''vp''', and '''density'''. All three are implemented as properties with notification signals, so if the underlying device PPI changes, all UI elements can be re-laid out. This is useful when moving (at run-time) an application from a small handset screen to a larger display (for example via an attached HDMI)

Extending the above example to set the rectangle size to be 10cm x 5cm:
Rectangle {
MeeGoUnits {
id: units
}
width: units.mm2px(100.0)
height: units.mm2px(50.0)
}
Using the conversion properties is pretty straight forward and works as you would expect. The following instantiates a 1cm x 1cm rectangle, offset from the top left of its parent by 1cm:
Rectangle {
x: units.mm2px(10.0)
y: units.mm2px(10.0)
width: units.mm2px(10.0)
height: units.mm2px(10.0)
}

==a note on rounding==
Since the value of the properties returned by MeeGoUnits are non-integer (for example, units.mm might be '3.66667'), the result of most operations with the units will result in non-integer numbers as well. Due to the cast of real to int, you may encounter rounding problems which typically manifest themselves as QML Items not always lining up. This can be remedied by using the mm2px() conversion method exposed by the units object vs. using units.mm directly.

The following shows a simplified example which can lead to rounding problems:
Rectangle {
width: 20.0 * units.mm
height: 10.0 * units.mm
...
}
Better code:
Rectangle {
width: units.mm2px(20.0)
height: units.mm2px(10.0)
...
}

==text==
Text {
font.pixelSize: units.mm2px(2.5) // create text that is 2.5mm tall
text: "2.5mm font"
}

==images==
Image {
source: "text-bg.jpg"
width: units.mm2px(9.5)
height: units.mm2px(6.0)
sourceSize.width: units.mm2px(9.5)
sourceSize.height: units.mm2px(6.0)
}

===thoughts on asset theme scaling===
/* Not done yet -- auto scaling and caching from an asset daemon with target size scaling:
*
* source: "image://" + unit + "/" + w + "x" + h "/text-bg"
*

BorderImage {
width: 1024
height: 768
source: "image://super{/dimensions{/units}}/resource{.ext}"
source: "image://super/" + width + "x" + height + "/px/resource"
source: theme.avatar.source
}

theme.avatar contains:
{
width <--- In pixels
height <--- In pixels
source <--- uses the uber theme image provider
}

width: 20 <--- hard coded, non density independent
width: mm2px(5) <---hard coded, density independent
width: theme.avatarWidth <--- theme over-ridable, density independent

--------------

supporting the scaled size of the border in a border image via the theme; probably requires creating a new "borderimage" replacement that supports a set of target border size properties. Usage example is to take a 1px border from a pixel asset and have the border actually scaled to 2mm on the display

*
* So, instead, set the source width and height to the scaled dimensions : */

==vector vs. raster==
==naming conventions==
==resource sharing==
==scaling==

MeeGo UX Components

2011-04-20T04:11:21Z

Btdrucke:

=Overview=
The '''meego-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meego-ux-components&project=Trunk OBS]] provides visual components for third-party developers to use to quickly create applications adhering to the MeeGo UX look-and-feel. These components are supported and are an official part of the MeeGo API for developers.

Many components in this package first appeared in the '''meegolabs-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meegolabs-ux-components&project=Trunk OBS]]. Code in this package includes experimental code and early versions with unstable APIs. There is no guarantee of support for these components nor will they necessarily maintain consistent software interfaces.

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components (See [[Components_Migration|Components Migration]]).

=API Documentation=
Eventually, API docs will be generated automatically from the tip of the git repository at http://apidocs.meego.com. For now, there is a snapshot of the docs [[Components_API_Snapshot|here]].

=Installing MeeGo UX Components=
You can install the MeeGo UX components either from the zypper (recommended) or directly form the latest version of the source code. This code assumes you are working either on a MeeGo system [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Windows|(Windows]] | [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux|Linux)]], within the [[SDK/Qemu|MeeGo SDK QEMU environment]], or within a [[Developing_in_a_Meego_Environment#Step_1:_Chrooting_into_the_development_image|MeeGo chroot configuration]].

==Using Zypper==
To use MeeGo UX components for your project, you will need to install the development version of the package. Using zypper:
zypper install meego-ux-components-devel

==From a Source Package==
First ensure that you have an enabled Trunk source zypper repo. Bring in a source archive and all the needed build-time dependencies with:
zypper source-install meego-ux-components

==From a Git Repo==
We'll first clone the source from the upstream repository location on Gitorious:
git clone git://meego.gitorious.org/meego-ux/meego-ux-components

The easiest way to prepare your development environment with all the build-time dependencies is to install the source package as described above.
If you don't want to do that, read the README file for instructions on installing dependent packages manually. Finally, make and install:

cd meego-ux-components
qmake
make
sudo make install

=Examples of Using Components=

To see the components in action and to verify correct installation, we can use the three example programs provided:

* meego-ux-components-widgetgallery - A gallery of components which demonstrate each components and interactively lets you change component properties. See [[MeeGo_UX_Components_WidgetGallery|screen shots]].
* meego-ux-components-app-photos - An example application that uses MeeGo UX components
* meego-ux-components-tutorial - An on-line tutorial on how to use MeeGo UX Components

To run on a development system, use meego-qml-launcher. Your application should have a file at ''/usr/share/<application-name>/main.qml''. This tool exports theme information to QML applications (font sizes, colors, dimensions, etc) and also ensures that your application is treated as a system-wide singleton. That is, if the app is already running, meego-qml-launcher will send a "raise" dbus signal instead of launching a second instance.

$ meego-qml-launcher --fullscreen --app meego-ux-components-widgetallery

When running on target hardware, you can add the --opengl option to use hardware graphics acceleration.

$ meego-qml-launcher --opengl --fullscreen --app meego-ux-components-widgetgallery

=Using Components in a New Application=
Now that the MeeGo UX Components are installed on your system, you can begin developing a new application using the components.

# Launch Qt Creator.
# Select 'Create Project'
# Under Projects select 'Qt Quick Project'
# 'QML Application' will be selected for the template type.
# Click 'Choose...'
# Give the project a name, for example "thatwaseasy". Click 'Next'
# Click 'Finish' Qt Creator will now create the project and provide an initial QML file

Let's run it to see what it does. Click the green arrow in the lower left corner of Qt Creator. This will run the application. After a few moments a new window will appear with the text 'Hello world' Now let's add a MeeGo UX button and when it is pressed, we will change the text to say "That was easy!"

Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

=Adding MeeGo UX Components=
Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

MeeGo UX Components

2011-04-20T04:06:26Z

Btdrucke: /* Building your first application */

=Overview=
The '''meego-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meego-ux-components&project=Trunk OBS]] provides visual components for third-party developers to use to quickly create applications adhering to the MeeGo UX look-and-feel. These components are supported and are an official part of the MeeGo API for developers.

Many components in this package first appeared in the '''meegolabs-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meegolabs-ux-components&project=Trunk OBS]]. Code in this package includes experimental code and early versions with unstable APIs. There is no guarantee of support for these components nor will they necessarily maintain consistent software interfaces.

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components (See [[Components_Migration|Components Migration]]).

=Installing MeeGo UX Components=
You can install the MeeGo UX components either from the zypper (recommended) or directly form the latest version of the source code. This code assumes you are working either on a MeeGo system [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Windows|(Windows]] | [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux|Linux)]], within the [[SDK/Qemu|MeeGo SDK QEMU environment]], or within a [[Developing_in_a_Meego_Environment#Step_1:_Chrooting_into_the_development_image|MeeGo chroot configuration]].

==Using Zypper==
To use MeeGo UX components for your project, you will need to install the development version of the package. Using zypper:
zypper install meego-ux-components-devel

==From a Source Package==
First ensure that you have an enabled Trunk source zypper repo. Bring in a source archive and all the needed build-time dependencies with:
zypper source-install meego-ux-components

==From a Git Repo==
We'll first clone the source from the upstream repository location on Gitorious:
git clone git://meego.gitorious.org/meego-ux/meego-ux-components

The easiest way to prepare your development environment with all the build-time dependencies is to install the source package as described above.
If you don't want to do that, read the README file for instructions on installing dependent packages manually. Finally, make and install:

cd meego-ux-components
qmake
make
sudo make install

=Examples of Using Components=

To see the components in action and to verify correct installation, we can use the three example programs provided:

* meego-ux-components-widgetgallery - A gallery of components which demonstrate each components and interactively lets you change component properties. See [[MeeGo_UX_Components_WidgetGallery|screen shots]].
* meego-ux-components-app-photos - An example application that uses MeeGo UX components
* meego-ux-components-tutorial - An on-line tutorial on how to use MeeGo UX Components

To run on a development system, use meego-qml-launcher. Your application should have a file at ''/usr/share/<application-name>/main.qml''. This tool exports theme information to QML applications (font sizes, colors, dimensions, etc) and also ensures that your application is treated as a system-wide singleton. That is, if the app is already running, meego-qml-launcher will send a "raise" dbus signal instead of launching a second instance.

$ meego-qml-launcher --fullscreen --app meego-ux-components-widgetallery

When running on target hardware, you can add the --opengl option to use hardware graphics acceleration.

$ meego-qml-launcher --opengl --fullscreen --app meego-ux-components-widgetgallery

=Using Components in a New Application=
Now that the MeeGo UX Components are installed on your system, you can begin developing a new application using the components.

# Launch Qt Creator.
# Select 'Create Project'
# Under Projects select 'Qt Quick Project'
# 'QML Application' will be selected for the template type.
# Click 'Choose...'
# Give the project a name, for example "thatwaseasy". Click 'Next'
# Click 'Finish' Qt Creator will now create the project and provide an initial QML file

Let's run it to see what it does. Click the green arrow in the lower left corner of Qt Creator. This will run the application. After a few moments a new window will appear with the text 'Hello world' Now let's add a MeeGo UX button and when it is pressed, we will change the text to say "That was easy!"

Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

=Adding MeeGo UX Components=
Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

Components Migration

2011-04-19T22:13:49Z

Btdrucke: Created page with "==Migration of Components from MeeGo.Labs.Components to MeeGo.Components== ''PAGE UNDER CONSTRUCTION'' Currently some component code versions exists in both meegolabs-ux-compone..."

==Migration of Components from MeeGo.Labs.Components to MeeGo.Components==
''PAGE UNDER CONSTRUCTION''

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components.

Component migration will occur in three phases:

===Phase I (done April 8th)===
* deprecate Media pickers (image/video/music)
* deprecate Date and Time pickers
* Contacts picker will remain in meegolabs-ux-components for the time being

===Phase II (schedule to end April 22)===
* all other duplicated components (see table below)
* Window and AppPage/ApplicationPage will not be migrated in this phase

===Phase III (scheduled to end April 29)===
* Window and AppPage components

import MeeGo.Labs.Components 0.1 as Labs
import MeeGo.Components 0.1

// meego-ux-components window
Window {
...
// meego-ux-components button
Button {
}
// meegolabs-ux-components iconbutton
Labs.IconButton {
}
...
}

==Window, Book and Page==

A general change in the meego-ux-components is the concept of how to use Window
and AppPage in order to create a navigation path to your application. Please
find the examples and the tutorial in the devel package to help you understand
the concept easily.

==Phase II Components Migration:==

{|
|MeeGo Labs         ||MeeGo-Ux-Components   ||Changes
|-
|ActionMenu         ||ActionMenu            ||API changed
|-
|Button             ||Button                ||API and Design
|-
|CheckBox           ||CheckBox              ||API and Design
|-
|ContextMenu        ||ModalContextMenu      ||derived from ModalFog, API change
|-
|DropDown           ||DropDown              ||API and Design
|-
|EditPane           ||TextField             ||replace by TextField
|-
|ExpandingBox       ||ExpandingBox          ||API and Design
|-
|Fog                ||ModalFog              ||whole concept changed
|-
|IconButton         ||IconButton            ||API and Design
|-
|MessageBox         ||ModalMesseageBox      ||derived from ModalFog, API change
|-
|ModalDialog        ||ModalDialog           ||API and Design
|-
|ModalSurface       ||ModalFog              ||API and Design
|-
|PickerDialog       ||ModalDialog           ||-
|-
|PopupList          ||PopupList             ||API and Design
|-
|RadioButton        ||RadioButton           ||Design
|-
|RadioGroup.js      ||RadioGroup.js         ||Design
|-
|RadioGroup.qml     ||RadioGroup.qml        ||API and Design
|-
|Slider             ||Slider                ||API and Design
|-
|Spinner            ||Spinner               ||No API changes
|-
|StatusBar          ||StatusBar             ||No changes
|-
|TextEntry          ||TextEntry             ||API and Design
|-
|ToggleButton       ||ToggleButton          ||API and Design
|-
|TopItem            ||TopItem               ||API
|-
|VerticalSlider     ||VerticalSlider        ||API and Design
|}

MeeGo UX Components

2011-04-19T21:53:06Z

Btdrucke: /* Examples of Using Components */

=Overview=
The '''meego-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meego-ux-components&project=Trunk OBS]] provides visual components for third-party developers to use to quickly create applications adhering to the MeeGo UX look-and-feel. These components are supported and are an official part of the MeeGo API for developers.

Many components in this package first appeared in the '''meegolabs-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meegolabs-ux-components&project=Trunk OBS]]. Code in this package includes experimental code and early versions with unstable APIs. There is no guarantee of support for these components nor will they necessarily maintain consistent software interfaces.

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components (See [[Components_Migration|Components Migration]]).

=Installing MeeGo UX Components=
You can install the MeeGo UX components either from the zypper (recommended) or directly form the latest version of the source code. This code assumes you are working either on a MeeGo system [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Windows|(Windows]] | [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux|Linux)]], within the [[SDK/Qemu|MeeGo SDK QEMU environment]], or within a [[Developing_in_a_Meego_Environment#Step_1:_Chrooting_into_the_development_image|MeeGo chroot configuration]].

==Using Zypper==
To use MeeGo UX components for your project, you will need to install the development version of the package. Using zypper:
zypper install meego-ux-components-devel

==From a Source Package==
First ensure that you have an enabled Trunk source zypper repo. Bring in a source archive and all the needed build-time dependencies with:
zypper source-install meego-ux-components

==From a Git Repo==
We'll first clone the source from the upstream repository location on Gitorious:
git clone git://meego.gitorious.org/meego-ux/meego-ux-components

The easiest way to prepare your development environment with all the build-time dependencies is to install the source package as described above.
If you don't want to do that, read the README file for instructions on installing dependent packages manually. Finally, make and install:

cd meego-ux-components
qmake
make
sudo make install

=Examples of Using Components=

To see the components in action and to verify correct installation, we can use the three example programs provided:

* meego-ux-components-widgetgallery - A gallery of components which demonstrate each components and interactively lets you change component properties. See [[MeeGo_UX_Components_WidgetGallery|screen shots]].
* meego-ux-components-app-photos - An example application that uses MeeGo UX components
* meego-ux-components-tutorial - An on-line tutorial on how to use MeeGo UX Components

To run on a development system, use meego-qml-launcher. Your application should have a file at ''/usr/share/<application-name>/main.qml''. This tool exports theme information to QML applications (font sizes, colors, dimensions, etc) and also ensures that your application is treated as a system-wide singleton. That is, if the app is already running, meego-qml-launcher will send a "raise" dbus signal instead of launching a second instance.

$ meego-qml-launcher --fullscreen --app meego-ux-components-widgetallery

When running on target hardware, you can add the --opengl option to use hardware graphics acceleration.

$ meego-qml-launcher --opengl --fullscreen --app meego-ux-components-widgetgallery

=Building your first application=
Now that the MeeGo UX Components are installed on your system, you can begin developing a new application using the components.

# Launch Qt Creator.
# Select 'Create Project'
# Under Projects select 'Qt Quick Project'
# 'QML Application' will be selected for the template type.
# Click 'Choose...'
# Give the project a name, for example "thatwaseasy". Click 'Next'
# Click 'Finish' Qt Creator will now create the project and provide an initial QML file

Let's run it to see what it does. Click the green arrow in the lower left corner of Qt Creator. This will run the application. After a few moments a new window will appear with the text 'Hello world' Now let's add a MeeGo UX button and when it is pressed, we will change the text to say "That was easy!"

=Adding MeeGo UX Components=
Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

MeeGo UX Components

2011-04-19T21:50:45Z

Btdrucke: /* Screen Shots of the Meego UX Components */

=Overview=
The '''meego-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meego-ux-components&project=Trunk OBS]] provides visual components for third-party developers to use to quickly create applications adhering to the MeeGo UX look-and-feel. These components are supported and are an official part of the MeeGo API for developers.

Many components in this package first appeared in the '''meegolabs-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meegolabs-ux-components&project=Trunk OBS]]. Code in this package includes experimental code and early versions with unstable APIs. There is no guarantee of support for these components nor will they necessarily maintain consistent software interfaces.

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components (See [[Components_Migration|Components Migration]]).

=Installing MeeGo UX Components=
You can install the MeeGo UX components either from the zypper (recommended) or directly form the latest version of the source code. This code assumes you are working either on a MeeGo system [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Windows|(Windows]] | [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux|Linux)]], within the [[SDK/Qemu|MeeGo SDK QEMU environment]], or within a [[Developing_in_a_Meego_Environment#Step_1:_Chrooting_into_the_development_image|MeeGo chroot configuration]].

==Using Zypper==
To use MeeGo UX components for your project, you will need to install the development version of the package. Using zypper:
zypper install meego-ux-components-devel

==From a Source Package==
First ensure that you have an enabled Trunk source zypper repo. Bring in a source archive and all the needed build-time dependencies with:
zypper source-install meego-ux-components

==From a Git Repo==
We'll first clone the source from the upstream repository location on Gitorious:
git clone git://meego.gitorious.org/meego-ux/meego-ux-components

The easiest way to prepare your development environment with all the build-time dependencies is to install the source package as described above.
If you don't want to do that, read the README file for instructions on installing dependent packages manually. Finally, make and install:

cd meego-ux-components
qmake
make
sudo make install

=Examples of Using Components=

To see the components in action and to verify correct installation, we can use the three example programs provided:

* meego-ux-components-widgetgallery - A gallery of components which demonstrate each components and interactively lets you change component properties
* meego-ux-components-app-photos - An example application that uses MeeGo UX components
* meego-ux-components-tutorial - An on-line tutorial on how to use MeeGo UX Components

To run on a development system, use meego-qml-launcher. Your application should have a file at ''/usr/share/<application-name>/main.qml''. This tool exports theme information to QML applications (font sizes, colors, dimensions, etc) and also ensures that your application is treated as a system-wide singleton. That is, if the app is already running, meego-qml-launcher will send a "raise" dbus signal instead of launching a second instance.

$ meego-qml-launcher --fullscreen --app meego-ux-components-widgetallery

When running on target hardware, you can add the --opengl option to use hardware graphics acceleration.

$ meego-qml-launcher --opengl --fullscreen --app meego-ux-components-widgetallery

=Building your first application=
Now that the MeeGo UX Components are installed on your system, you can begin developing a new application using the components.

# Launch Qt Creator.
# Select 'Create Project'
# Under Projects select 'Qt Quick Project'
# 'QML Application' will be selected for the template type.
# Click 'Choose...'
# Give the project a name, for example "thatwaseasy". Click 'Next'
# Click 'Finish' Qt Creator will now create the project and provide an initial QML file

Let's run it to see what it does. Click the green arrow in the lower left corner of Qt Creator. This will run the application. After a few moments a new window will appear with the text 'Hello world' Now let's add a MeeGo UX button and when it is pressed, we will change the text to say "That was easy!"

=Adding MeeGo UX Components=
Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

MeeGo UX Components WidgetGallery

2011-04-19T21:49:50Z

Btdrucke: Created page with "=Screen Shots of the Meego UX Components Widget Gallery= Run the gallery with the following command. Only use the --opengl option when running on target hardware. $ meego-qml..."

=Screen Shots of the Meego UX Components Widget Gallery=

Run the gallery with the following command. Only use the --opengl option when running on target hardware.

$ meego-qml-launcher --fullscreen --opengl --app meego-ux-components-widgetgallery

Some screen shots of the gallery application:

[[File:Meego-ux-widgetgallery-1.png|800px]]
::(Initial view - showing the list of widgets)

[[File:Meego-ux-widgetgallery-Buttons.png|800px]]
::(Showing Button Widgets)

[[File:Meego-ux-widgetgallery-ModalDialogs.png|800px]]
::(Showing Modal Dialog Widgets)

[[File:Meego-ux-widgetgallery-date-picker.png|800px]]
::(Showing Date Picker Widget in action)

[[File:Meego-ux-widgetgallery-messagebox.png|800px]]
::(Showing ModalMessageBox in action)

[[File:Meego-ux-widgetgallery-progressbar.png|800px]]
::(Showing ProgressBar widget in action after clicking the Start button)

MeeGo UX Components

2011-04-19T21:43:27Z

Btdrucke: /* Example Programs */

=Overview=
The '''meego-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meego-ux-components&project=Trunk OBS]] provides visual components for third-party developers to use to quickly create applications adhering to the MeeGo UX look-and-feel. These components are supported and are an official part of the MeeGo API for developers.

Many components in this package first appeared in the '''meegolabs-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meegolabs-ux-components&project=Trunk OBS]]. Code in this package includes experimental code and early versions with unstable APIs. There is no guarantee of support for these components nor will they necessarily maintain consistent software interfaces.

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components (See [[Components_Migration|Components Migration]]).

=Installing MeeGo UX Components=
You can install the MeeGo UX components either from the zypper (recommended) or directly form the latest version of the source code. This code assumes you are working either on a MeeGo system [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Windows|(Windows]] | [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux|Linux)]], within the [[SDK/Qemu|MeeGo SDK QEMU environment]], or within a [[Developing_in_a_Meego_Environment#Step_1:_Chrooting_into_the_development_image|MeeGo chroot configuration]].

==Using Zypper==
To use MeeGo UX components for your project, you will need to install the development version of the package. Using zypper:
zypper install meego-ux-components-devel

==From a Source Package==
First ensure that you have an enabled Trunk source zypper repo. Bring in a source archive and all the needed build-time dependencies with:
zypper source-install meego-ux-components

==From a Git Repo==
We'll first clone the source from the upstream repository location on Gitorious:
git clone git://meego.gitorious.org/meego-ux/meego-ux-components

The easiest way to prepare your development environment with all the build-time dependencies is to install the source package as described above.
If you don't want to do that, read the README file for instructions on installing dependent packages manually. Finally, make and install:

cd meego-ux-components
qmake
make
sudo make install

=Examples of Using Components=

To see the components in action and to verify correct installation, we can use the three example programs provided:

* meego-ux-components-widgetgallery - A gallery of components which demonstrate each components and interactively lets you change component properties
* meego-ux-components-app-photos - An example application that uses MeeGo UX components
* meego-ux-components-tutorial - An on-line tutorial on how to use MeeGo UX Components

To run on a development system, use meego-qml-launcher. Your application should have a file at ''/usr/share/<application-name>/main.qml''. This tool exports theme information to QML applications (font sizes, colors, dimensions, etc) and also ensures that your application is treated as a system-wide singleton. That is, if the app is already running, meego-qml-launcher will send a "raise" dbus signal instead of launching a second instance.

$ meego-qml-launcher --fullscreen --app meego-ux-components-widgetallery

When running on target hardware, you can add the --opengl option to use hardware graphics acceleration.

$ meego-qml-launcher --opengl --fullscreen --app meego-ux-components-widgetallery

=Building your first application=
Now that the MeeGo UX Components are installed on your system, you can begin developing a new application using the components.

# Launch Qt Creator.
# Select 'Create Project'
# Under Projects select 'Qt Quick Project'
# 'QML Application' will be selected for the template type.
# Click 'Choose...'
# Give the project a name, for example "thatwaseasy". Click 'Next'
# Click 'Finish' Qt Creator will now create the project and provide an initial QML file

Let's run it to see what it does. Click the green arrow in the lower left corner of Qt Creator. This will run the application. After a few moments a new window will appear with the text 'Hello world' Now let's add a MeeGo UX button and when it is pressed, we will change the text to say "That was easy!"

=Adding MeeGo UX Components=
Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

=Screen Shots of the Meego UX Components=

[[File:Meego-ux-widgetgallery-1.png|800px]]
::(Initial view - showing the list of widgets)

[[File:Meego-ux-widgetgallery-Buttons.png|800px]]
::(Showing Button Widgets)

[[File:Meego-ux-widgetgallery-ModalDialogs.png|800px]]
::(Showing Modal Dialog Widgets)

[[File:Meego-ux-widgetgallery-date-picker.png|800px]]
::(Showing Date Picker Widget in action)

[[File:Meego-ux-widgetgallery-messagebox.png|800px]]
::(Showing ModalMessageBox in action)

[[File:Meego-ux-widgetgallery-progressbar.png|800px]]
::(Showing ProgressBar widget in action after clicking the Start button)

MeeGo UX Components

2011-04-19T21:42:40Z

Btdrucke: /* Seeing the MeeGo UX Components */

=Overview=
The '''meego-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meego-ux-components&project=Trunk OBS]] provides visual components for third-party developers to use to quickly create applications adhering to the MeeGo UX look-and-feel. These components are supported and are an official part of the MeeGo API for developers.

Many components in this package first appeared in the '''meegolabs-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meegolabs-ux-components&project=Trunk OBS]]. Code in this package includes experimental code and early versions with unstable APIs. There is no guarantee of support for these components nor will they necessarily maintain consistent software interfaces.

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components (See [[Components_Migration|Components Migration]]).

=Installing MeeGo UX Components=
You can install the MeeGo UX components either from the zypper (recommended) or directly form the latest version of the source code. This code assumes you are working either on a MeeGo system [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Windows|(Windows]] | [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux|Linux)]], within the [[SDK/Qemu|MeeGo SDK QEMU environment]], or within a [[Developing_in_a_Meego_Environment#Step_1:_Chrooting_into_the_development_image|MeeGo chroot configuration]].

==Using Zypper==
To use MeeGo UX components for your project, you will need to install the development version of the package. Using zypper:
zypper install meego-ux-components-devel

==From a Source Package==
First ensure that you have an enabled Trunk source zypper repo. Bring in a source archive and all the needed build-time dependencies with:
zypper source-install meego-ux-components

==From a Git Repo==
We'll first clone the source from the upstream repository location on Gitorious:
git clone git://meego.gitorious.org/meego-ux/meego-ux-components

The easiest way to prepare your development environment with all the build-time dependencies is to install the source package as described above.
If you don't want to do that, read the README file for instructions on installing dependent packages manually. Finally, make and install:

cd meego-ux-components
qmake
make
sudo make install

=Example Programs=

To see the components in action and to verify correct installation, we can use the three example programs provided:

* meego-ux-components-widgetgallery - A gallery of components which demonstrate each components and interactively lets you change component properties
* meego-ux-components-app-photos - An example application that uses MeeGo UX components
* meego-ux-components-tutorial - An on-line tutorial on how to use MeeGo UX Components

To run on a development system, use meego-qml-launcher. Your application should have a file at ''/usr/share/<application-name>/main.qml''. This tool exports theme information to QML applications (font sizes, colors, dimensions, etc) and also ensures that your application is treated as a system-wide singleton. That is, if the app is already running, meego-qml-launcher will send a "raise" dbus signal instead of launching a second instance.

$ meego-qml-launcher --fullscreen --app meego-ux-components-widgetallery

When running on target hardware, you can add the --opengl option to use hardware graphics acceleration.

$ meego-qml-launcher --opengl --fullscreen --app meego-ux-components-widgetallery

=Building your first application=
Now that the MeeGo UX Components are installed on your system, you can begin developing a new application using the components.

# Launch Qt Creator.
# Select 'Create Project'
# Under Projects select 'Qt Quick Project'
# 'QML Application' will be selected for the template type.
# Click 'Choose...'
# Give the project a name, for example "thatwaseasy". Click 'Next'
# Click 'Finish' Qt Creator will now create the project and provide an initial QML file

Let's run it to see what it does. Click the green arrow in the lower left corner of Qt Creator. This will run the application. After a few moments a new window will appear with the text 'Hello world' Now let's add a MeeGo UX button and when it is pressed, we will change the text to say "That was easy!"

=Adding MeeGo UX Components=
Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

=Screen Shots of the Meego UX Components=

[[File:Meego-ux-widgetgallery-1.png|800px]]
::(Initial view - showing the list of widgets)

[[File:Meego-ux-widgetgallery-Buttons.png|800px]]
::(Showing Button Widgets)

[[File:Meego-ux-widgetgallery-ModalDialogs.png|800px]]
::(Showing Modal Dialog Widgets)

[[File:Meego-ux-widgetgallery-date-picker.png|800px]]
::(Showing Date Picker Widget in action)

[[File:Meego-ux-widgetgallery-messagebox.png|800px]]
::(Showing ModalMessageBox in action)

[[File:Meego-ux-widgetgallery-progressbar.png|800px]]
::(Showing ProgressBar widget in action after clicking the Start button)

MeeGo UX Components

2011-04-19T21:09:12Z

Btdrucke: /* Install the MeeGo UX Components */

=Overview=
The '''meego-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meego-ux-components&project=Trunk OBS]] provides visual components for third-party developers to use to quickly create applications adhering to the MeeGo UX look-and-feel. These components are supported and are an official part of the MeeGo API for developers.

Many components in this package first appeared in the '''meegolabs-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meegolabs-ux-components&project=Trunk OBS]]. Code in this package includes experimental code and early versions with unstable APIs. There is no guarantee of support for these components nor will they necessarily maintain consistent software interfaces.

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components (See [[Components_Migration|Components Migration]]).

=Installing MeeGo UX Components=
You can install the MeeGo UX components either from the zypper (recommended) or directly form the latest version of the source code. This code assumes you are working either on a MeeGo system [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Windows|(Windows]] | [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux|Linux)]], within the [[SDK/Qemu|MeeGo SDK QEMU environment]], or within a [[Developing_in_a_Meego_Environment#Step_1:_Chrooting_into_the_development_image|MeeGo chroot configuration]].

==Using Zypper==
To use MeeGo UX components for your project, you will need to install the development version of the package. Using zypper:
zypper install meego-ux-components-devel

==From a Source Package==
First ensure that you have an enabled Trunk source zypper repo. Bring in a source archive and all the needed build-time dependencies with:
zypper source-install meego-ux-components

==From a Git Repo==
We'll first clone the source from the upstream repository location on Gitorious:
git clone git://meego.gitorious.org/meego-ux/meego-ux-components

The easiest way to prepare your development environment with all the build-time dependencies is to install the source package as described above.
If you don't want to do that, read the README file for instructions on installing dependent packages manually. Finally, make and install:

cd meego-ux-components
qmake
make
sudo make install

=Seeing the MeeGo UX Components=

Next lets test the install and verify that the widgets are installed. The default location for the sample applications using the components are:
/usr/share/meego-ux-app-photos
/usr/share/meego-ux-tutorial
/usr/share/meego-ux-widgetgallery

We will run the widget gallery using the qmlviewer:
$ qmlviewer /usr/share/meego-ux-widgetgallery/main.qml

=Building your first application=
Now that the MeeGo UX Components are installed on your system, you can begin developing a new application using the components.

# Launch Qt Creator.
# Select 'Create Project'
# Under Projects select 'Qt Quick Project'
# 'QML Application' will be selected for the template type.
# Click 'Choose...'
# Give the project a name, for example "thatwaseasy". Click 'Next'
# Click 'Finish' Qt Creator will now create the project and provide an initial QML file

Let's run it to see what it does. Click the green arrow in the lower left corner of Qt Creator. This will run the application. After a few moments a new window will appear with the text 'Hello world' Now let's add a MeeGo UX button and when it is pressed, we will change the text to say "That was easy!"

=Adding MeeGo UX Components=
Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

=Screen Shots of the Meego UX Components=

[[File:Meego-ux-widgetgallery-1.png|800px]]
::(Initial view - showing the list of widgets)

[[File:Meego-ux-widgetgallery-Buttons.png|800px]]
::(Showing Button Widgets)

[[File:Meego-ux-widgetgallery-ModalDialogs.png|800px]]
::(Showing Modal Dialog Widgets)

[[File:Meego-ux-widgetgallery-date-picker.png|800px]]
::(Showing Date Picker Widget in action)

[[File:Meego-ux-widgetgallery-messagebox.png|800px]]
::(Showing ModalMessageBox in action)

[[File:Meego-ux-widgetgallery-progressbar.png|800px]]
::(Showing ProgressBar widget in action after clicking the Start button)

MeeGo UX Components

2011-04-19T20:57:07Z

Btdrucke: /* Overview */

=Overview=
The '''meego-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meego-ux-components&project=Trunk OBS]] provides visual components for third-party developers to use to quickly create applications adhering to the MeeGo UX look-and-feel. These components are supported and are an official part of the MeeGo API for developers.

Many components in this package first appeared in the '''meegolabs-ux-components''' package [[http://meego.gitorious.org/meego-ux/meegolabs-ux-components git]/[http://build.meego.com/package/show?package=meegolabs-ux-components&project=Trunk OBS]]. Code in this package includes experimental code and early versions with unstable APIs. There is no guarantee of support for these components nor will they necessarily maintain consistent software interfaces.

Currently some component code versions exists in both meegolabs-ux-components and meego-ux-components. In order to avoid confusion for third party developers and to decrease the burden of maintaining two branches and keeping them in sync, we are deprecating code in meegolabs-ux-components where it is already available in meego-ux-components (See [[Components_Migration|Components Migration]]).

=Install the MeeGo UX Components=
You can install the MeeGo UX components either from the zypper (recommended) or directly form the latest version of the source code. This code assumes you are working either on a MeeGo system [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Windows|(Windows]] | [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux|Linux)]], within the [[SDK/Qemu|MeeGo SDK QEMU environment]], or within a [[Developing_in_a_Meego_Environment#Step_1:_Chrooting_into_the_development_image|MeeGo chroot configuration]].

==Zypper==
To install the MeeGo UX Components via zypper:
zypper install meego-ux-components-devel

==From Source==
We'll first clone the source from the upstream repository location on Gitorious:
git clone git://meego.gitorious.org/meego-ux/meego-ux-components
cd meego-ux-components
qmake
make
sudo make install
NOTE: If you haven't been doing active development from sources, you may need several development dependency packages. The easiest way to get those dependencies installed is to use zypper to install the sources for meego-u-components first. You can then pull from GIT for the tip of development. This command tells zypper to install the source for meego-ux-components, which will install any build dependencies as well:
zypper si meego-ux-components

=Seeing the MeeGo UX Components=

Next lets test the install and verify that the widgets are installed. The default location for the sample applications using the components are:
/usr/share/meego-ux-app-photos
/usr/share/meego-ux-tutorial
/usr/share/meego-ux-widgetgallery

We will run the widget gallery using the qmlviewer:
$ qmlviewer /usr/share/meego-ux-widgetgallery/main.qml

=Building your first application=
Now that the MeeGo UX Components are installed on your system, you can begin developing a new application using the components.

# Launch Qt Creator.
# Select 'Create Project'
# Under Projects select 'Qt Quick Project'
# 'QML Application' will be selected for the template type.
# Click 'Choose...'
# Give the project a name, for example "thatwaseasy". Click 'Next'
# Click 'Finish' Qt Creator will now create the project and provide an initial QML file

Let's run it to see what it does. Click the green arrow in the lower left corner of Qt Creator. This will run the application. After a few moments a new window will appear with the text 'Hello world' Now let's add a MeeGo UX button and when it is pressed, we will change the text to say "That was easy!"

=Adding MeeGo UX Components=
Installed with the MeeGo UX Components are a set of QML files provided as a tutorial. You can find the contents of the first file in:
/usr/share/meego-ux-tutorial/step1/main.qml.

Open that file in Qt Creator, copy its contents, and replace the contents of the QML file that Qt Creator generated for you.

You can now run that first step by clicking on the green arrow (or pressing CTRL-R on the keyboard) Save your changes when prompted.

You can explore the other tutorial steps and see what they each do. Experiment with the various components you see in the widgets gallery.

=Screen Shots of the Meego UX Components=

[[File:Meego-ux-widgetgallery-1.png|800px]]
::(Initial view - showing the list of widgets)

[[File:Meego-ux-widgetgallery-Buttons.png|800px]]
::(Showing Button Widgets)

[[File:Meego-ux-widgetgallery-ModalDialogs.png|800px]]
::(Showing Modal Dialog Widgets)

[[File:Meego-ux-widgetgallery-date-picker.png|800px]]
::(Showing Date Picker Widget in action)

[[File:Meego-ux-widgetgallery-messagebox.png|800px]]
::(Showing ModalMessageBox in action)

[[File:Meego-ux-widgetgallery-progressbar.png|800px]]
::(Showing ProgressBar widget in action after clicking the Start button)

Main Page

2011-04-13T06:32:03Z

Btdrucke: /* MeeGo Components */

= Structure and Governance =

MeeGo is an open source project led by the MeeGo Technical Steering Group (TSG). The governance model is based on meritocracy and the best practices and values of the Open Source culture. The MeeGo project lives under the auspices of the Linux Foundation.

* [http://meego.com/about/governance MeeGo Project Structure and Governance Overview]
* Bi-weekly [[Technical Steering Group meetings]]
* [[Working Group Process]]

== MeeGo Project Functions ==
* [[Community Office]]
* [[Localization team|Localization]]
* [http://meego.com/about/governance/program-office Program Office]
* [[Core_OS_Program | Core OS Program]]
* [[Handset_Program | Handset UX Program]]
* [[In-vehicle | In Vehicle Infotainment - IVI]]
* [[Product Management]]
* [[Quality]]
** [[Error Management]]
* [[Release_Engineering|Release Engineering]]
* [http://meego.com/about/governance/ui-design User Interface Design]
* [[SDK]]
* [[Architecture]]

= User =

* [[MeeGo Netbook FAQ]]
* [http://meego.com/devices/netbook/installing-meego-your-netbook Install MeeGo on your netbook]
* [[Devices|Supported devices]]
* [[Install MeeGo from Hard Disk]]

= Developer =
== Developer Guide ==

* [[SDK/Docs/1.1|Developer Guide for MeeGo 1.1]]
* [[SDK/Docs/1.0|Developer Guide for MeeGo 1.0]]
* [[Build_Infrastructure | Build Infrastructure]]
* [[MeeGo Porting Guide]]
* [http://appdeveloper.intel.com/en-us/meego-develop Intel Tablet Guide]
* [[QML tutorials]] - Some tutorials to help get started with QML, the Qt Modelling Language.
* [http://mxr.meego.com/ MeeGo cross reference] - Index of MeeGo source code

Other documents:
{| border="1"
! Document
! Variety (Version)
! Architectures
|-
|Instructions for [[ARM|ARM based devices (N900, BeagleBoard, PandaBoard, Snowball)]]
|All
|ARM
|-
|Instructions for [[MeeGo_1.0_Netbook_VirtualBox|VirtualBox]]
|Netbook (1.0)
|Intel
|-
|Instructions for [[MeeGo SDK on Windows with VirtualBox]]
|All
|All
|-
|Tips for [[Developing With The Aava]]
|Handset/Aava
|Intel
|}

== Release Process ==
The MeeGo Release Process includes:
* [[Release_Engineering/Process|Release process and work flow]]
* [[Release_Engineering/Release_Timeline|MeeGo releases every 6 months]]
* [[Release_Engineering/Process|Nightly builds for developers and weekly releases will be available]]

== MeeGo Components ==
* [[MeeGo_UX_Components|MeeGo Components]] - Supported common QML components
** [[Components_Migration|Migration to Components]] - Guides and roadmap for migrating from MeeGo.Labs.Components to MeeGo.Components
* [[MeeGoLabs_UX_Components|MeeGo Labs Components]] - Unsupported, experimental QML components

= Community =

== Contributing to MeeGo ==
* Read our [[Community guidelines]]: [[Wiki contribution guidelines|Wiki]], [[Mailing list guidelines|mailing list]], [[Forum/Guidelines|forum]], and [[Community guidelines|more]].
* [[Community communication|Participate in our forums, mailing lists, and more]].
* [http://meego.com/about/contribution-guidelines Contribute to MeeGo].
* [[Build_Infrastructure/Community_Builder|Building applications]] for MeeGo

See also [[Who's who]].

== Meetings ==

[[MeeGo-Meeting IRC Schedule]]

The following groups have regular meetings, see their respective pages for details.

* [[Technical Steering Group meetings]]
* [[Community Office/Meetings|Community Office meetings]]
* [[Localization team]]

Regional Activities.
* [[Local MeeGo Networks]]

== Bi-Annual MeeGo Conference ==

'''Upcoming Conferences'''
* [[MeeGo Conference Spring 2011|Spring 2011: May 23 - 25 at the Hyatt Regency, San Francisco]]
* [[MeeGo Conference Fall 2011|Fall 2011: November Date TBD in Europe]]

'''Past Conference Wrap-Up Information'''
* [[MeeGo_Conference_2010|Fall 2010: November 15 - 17 in Dublin]]

== Resources ==
* [[MeeGo FAQ]]
* [[Glossary|Glossary and Acronyms]]
* [[Community guidelines]]
* [[Special:PopularPages|Popular Wiki Pages]]
* [[Special:MostLinkedPages|Most Linked-to Pages]]

[[Category:Top level]]

Main Page

2011-04-06T14:40:33Z

Btdrucke: /* Developer */

= Structure and Governance =

MeeGo is an open source project led by the MeeGo Technical Steering Group (TSG). The governance model is based on meritocracy and the best practices and values of the Open Source culture. The MeeGo project lives under the auspices of the Linux Foundation.

* [http://meego.com/about/governance MeeGo Project Structure and Governance Overview]
* Bi-weekly [[Technical Steering Group meetings]]
* [[Working Group Process]]

== MeeGo Project Functions ==
* [[Community Office]]
* [[Localization team|Localization]]
* [http://meego.com/about/governance/program-office Program Office]
* [[Core_OS_Program | Core OS Program]]
* [[Handset_Program | Handset UX Program]]
* [[In-vehicle | In Vehicle Infotainment - IVI]]
* [[Product Management]]
* [[Quality]]
** [[Error Management]]
* [[Release_Engineering|Release Engineering]]
* [http://meego.com/about/governance/ui-design User Interface Design]
* [[SDK]]
* [[Architecture]]

= User =

* [[MeeGo Netbook FAQ]]
* [http://meego.com/devices/netbook/installing-meego-your-netbook Install MeeGo on your netbook]
* [[Devices|Supported devices]]
* [[Install MeeGo from Hard Disk]]

= Developer =
== Developer Guide ==

* [[SDK/Docs/1.1|Developer Guide for MeeGo 1.1]]
* [[SDK/Docs/1.0|Developer Guide for MeeGo 1.0]]
* [[Build_Infrastructure | Build Infrastructure]]
* [[MeeGo Porting Guide]]
* [[QML tutorials]] - Some tutorials to help get started with QML, the Qt Modelling Language.
* [http://mxr.meego.com/ MeeGo cross reference] - Index of MeeGo source code

Other documents:
{| border="1"
! Document
! Variety (Version)
! Architectures
|-
|Instructions for [[ARM|ARM based devices (N900, BeagleBoard, PandaBoard, Snowball)]]
|All
|ARM
|-
|Instructions for [[MeeGo_1.0_Netbook_VirtualBox|VirtualBox]]
|Netbook (1.0)
|Intel
|-
|Instructions for [[MeeGo SDK on Windows with VirtualBox]]
|All
|All
|-
|Tips for [[Developing With The Aava]]
|Handset/Aava
|Intel
|}

== Release Process ==
The MeeGo Release Process includes:
* [[Release_Engineering/Process|Release process and work flow]]
* [[Release_Engineering/Release_Timeline|MeeGo releases every 6 months]]
* [[Release_Engineering/Process|Nightly builds for developers and weekly releases will be available]]

== MeeGo Components ==
* [[MeeGo_UX_Components|MeeGo Components]] - Supported common QML components
* [[MeeGoLabs_UX_Components|MeeGo Labs Components]] - Unsupported, experimental QML components

= Community =

== Contributing to MeeGo ==
* Read our [[Community guidelines]]: [[Wiki contribution guidelines|Wiki]], [[Mailing list guidelines|mailing list]], [[Forum/Guidelines|forum]], and [[Community guidelines|more]].
* [[Community communication|Participate in our forums, mailing lists, and more]].
* [http://meego.com/about/contribution-guidelines Contribute to MeeGo].
* [[Build_Infrastructure/Community_Builder|Building applications]] for MeeGo

See also [[Who's who]].

== Meetings ==

[[MeeGo-Meeting IRC Schedule]]

The following groups have regular meetings, see their respective pages for details.

* [[Technical Steering Group meetings]]
* [[Community Office/Meetings|Community Office meetings]]
* [[Localization team]]

Regional Activities.
* [[Local MeeGo Networks]]

== Bi-Annual MeeGo Conference ==

'''Upcoming Conferences'''
* [[MeeGo Conference Spring 2011|Spring 2011: May 23 - 25 at the Hyatt Regency, San Francisco]]
* [[MeeGo Conference Fall 2011|Fall 2011: November Date TBD in Europe]]

'''Past Conference Wrap-Up Information'''
* [[MeeGo_Conference_2010|Fall 2010: November 15 - 17 in Dublin]]

== Resources ==
* [[MeeGo FAQ]]
* [[Glossary|Glossary and Acronyms]]
* [[Community guidelines]]
* [[Special:PopularPages|Popular Wiki Pages]]
* [[Special:MostLinkedPages|Most Linked-to Pages]]

[[Category:Top level]]