MeeGo wiki - User contributions [en]

User:Jketreno/multi-point-touch

2011-06-10T22:03:46Z

Jketreno: /* Touch Latency */

=Status=
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev uses libmtdev in order to easily support both of the protocol A and B exposed by the kernel.
==Touch Latency==
When dealing with touch based interaction concepts, it is critical to minimize time difference between when the user attempts to interact with the UI and when the user receives feedback that something is happening. The variables at play which contribute heavily to this latency include:

# Firmware touch detection (it takes time for the hardware to filter out noise to determine that an actual finger touched the screen vs. an errant capacitance change)
# Kernel driver processing time
# Time between when the kernel is done and when the X input driver pulls the event out
# X input driver processing
# Time between when the input driver is done and when an Qt application receives the event
# Qt processing time
# Application code processing time which results in the UI changing
# The time between when the UI changes and when the next vblank occurs such that the user can actually *see* the result (which may require additional time to post a damage event to the window manager, the compositing of the new UI, and then a vblank)

By instrumenting the xorg-x11-driver-mtev we can determine the amount of time spent between 2 through 5. By instrumenting Qt we can determine the time spent between 5 and 7. Accurately measuring the time between 7 and 8 is difficult. For the purpose of measuring the part that we can control in the touch stack, measuring 2 through 7 is sufficient.

The patches to add this information can be found here:

* [http://api.meego.com/public/source/home:jketreno:touch-latency/xorg-x11-drv-mtev/debug.patch?rev=b3b40537385aa6b1aabda46fd851e05b xorg-x11-drv-mtev]
* [http://api.meego.com/public/source/home:jketreno:touch-latency/qt/qtTouchLatencyDebug.patch?rev=8636c4689650fd41c2121f56fce95714 Qt Touch Latency Debug patch]

Versions of Qt and xorg-x11-drv-mtev with the above patches applied can be found in my home project in the [http://build.meego.com/project/show?project=home%3Ajketreno%3Atouch-latency MeeGo OBS system].

=Using Touch with MeeGo=
MeeGo 1.2 provides a GestureArea element derived from the qml-gesturearea project.

==Gesture support in Qt==
As gesture support is added to the official versions QML, MeeGo will work to maintain compatibility with those features in a way which allows applications written with the MeeGo Components' GestureArea to still work.

For the current status of Gesture support in Qt, you can see the following bugreports:
* [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea]
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea]
* [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 Additional information].

==multiple input device support==
Qt on MeeGo is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See [https://bugs.meego.com/show_bug.cgi?id=17865 BMC#17865] if you have something to add to this topic.

==core pointer==
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc. This is typically the behavior you want.

However, if you don't want the touch device to control the pointer, you can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

==meego packages you may need==
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

=Troubleshooting=
==touch doesn't work on my system==
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

File:MtevTouchLatencyDebug.patch

2011-06-10T20:32:10Z

Jketreno:

User:Jketreno/multi-point-touch

2011-06-10T00:48:30Z

Jketreno: /* Touch Latency */

=Status=
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev uses libmtdev in order to easily support both of the protocol A and B exposed by the kernel.
==Touch Latency==
When dealing with touch based interaction concepts, it is critical to minimize time difference between when the user attempts to interact with the UI and when the user receives feedback that something is happening. The variables at play which contribute heavily to this latency include:

# Firmware touch detection (it takes time for the hardware to filter out noise to determine that an actual finger touched the screen vs. an errant capacitance change)
# Kernel driver processing time
# Time between when the kernel is done and when the X input driver pulls the event out
# X input driver processing
# Time between when the input driver is done and when an Qt application receives the event
# Qt processing time
# Application code processing time which results in the UI changing
# The time between when the UI changes and when the next vblank occurs such that the user can actually *see* the result (which may require additional time to post a damage event to the window manager, the compositing of the new UI, and then a vblank)

By instrumenting the xorg-x11-driver-mtev we can determine the amount of time spent between 2 through 5. By instrumenting Qt we can determine the time spent between 5 and 7. Accurately measuring the time between 7 and 8 is difficult. For the purpose of measuring the part that we can control in the touch stack, measuring 2 through 7 is sufficient.

The patches to add this information can be found here:

* [http://api.meego.com/public/source/home:jketreno/xorg-x11-drv-mtev/debug.patch?rev=a64635cf9c7fd59d898a7e2d63aa5d4e xorg-x11-drv-mtev]
* [http://wiki.meego.com/images/QtTouchLatencyDebug.patch Qt Touch Latency Debug patch]

=Using Touch with MeeGo=
MeeGo 1.2 provides a GestureArea element derived from the qml-gesturearea project.

==Gesture support in Qt==
As gesture support is added to the official versions QML, MeeGo will work to maintain compatibility with those features in a way which allows applications written with the MeeGo Components' GestureArea to still work.

For the current status of Gesture support in Qt, you can see the following bugreports:
* [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea]
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea]
* [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 Additional information].

==multiple input device support==
Qt on MeeGo is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See [https://bugs.meego.com/show_bug.cgi?id=17865 BMC#17865] if you have something to add to this topic.

==core pointer==
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc. This is typically the behavior you want.

However, if you don't want the touch device to control the pointer, you can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

==meego packages you may need==
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

=Troubleshooting=
==touch doesn't work on my system==
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

File:QtTouchLatencyDebug.patch

2011-06-10T00:46:18Z

Jketreno:

User:Jketreno/multi-point-touch

2011-06-10T00:45:55Z

Jketreno: /* Touch Latency */

=Status=
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev uses libmtdev in order to easily support both of the protocol A and B exposed by the kernel.
==Touch Latency==
When dealing with touch based interaction concepts, it is critical to minimize time difference between when the user attempts to interact with the UI and when the user receives feedback that something is happening. The variables at play which contribute heavily to this latency include:

# Firmware touch detection (it takes time for the hardware to filter out noise to determine that an actual finger touched the screen vs. an errant capacitance change)
# Kernel driver processing time
# Time between when the kernel is done and when the X input driver pulls the event out
# X input driver processing
# Time between when the input driver is done and when an Qt application receives the event
# Qt processing time
# Application code processing time which results in the UI changing
# The time between when the UI changes and when the next vblank occurs such that the user can actually *see* the result (which may require additional time to post a damage event to the window manager, the compositing of the new UI, and then a vblank)

By instrumenting the xorg-x11-driver-mtev we can determine the amount of time spent between 2 through 5. By instrumenting Qt we can determine the time spent between 5 and 7. Accurately measuring the time between 7 and 8 is difficult. For the purpose of measuring the part that we can control in the touch stack, measuring 2 through 7 is sufficient.

The patches I used can be found here:

* [http://api.meego.com/public/source/home:jketreno/xorg-x11-drv-mtev/debug.patch?rev=a64635cf9c7fd59d898a7e2d63aa5d4e& xorg-x11-drv-mtev]
* [ Qt]
[[Media:qtTouchLatencyDebug.patch]]

=Using Touch with MeeGo=
MeeGo 1.2 provides a GestureArea element derived from the qml-gesturearea project.

==Gesture support in Qt==
As gesture support is added to the official versions QML, MeeGo will work to maintain compatibility with those features in a way which allows applications written with the MeeGo Components' GestureArea to still work.

For the current status of Gesture support in Qt, you can see the following bugreports:
* [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea]
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea]
* [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 Additional information].

==multiple input device support==
Qt on MeeGo is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See [https://bugs.meego.com/show_bug.cgi?id=17865 BMC#17865] if you have something to add to this topic.

==core pointer==
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc. This is typically the behavior you want.

However, if you don't want the touch device to control the pointer, you can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

==meego packages you may need==
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

=Troubleshooting=
==touch doesn't work on my system==
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

User:Jketreno/multi-point-touch

2011-06-10T00:45:15Z

Jketreno: /* Touch Latency */

=Status=
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev uses libmtdev in order to easily support both of the protocol A and B exposed by the kernel.
==Touch Latency==
When dealing with touch based interaction concepts, it is critical to minimize time difference between when the user attempts to interact with the UI and when the user receives feedback that something is happening. The variables at play which contribute heavily to this latency include:

# Firmware touch detection (it takes time for the hardware to filter out noise to determine that an actual finger touched the screen vs. an errant capacitance change)
# Kernel driver processing time
# Time between when the kernel is done and when the X input driver pulls the event out
# X input driver processing
# Time between when the input driver is done and when an Qt application receives the event
# Qt processing time
# Application code processing time which results in the UI changing
# The time between when the UI changes and when the next vblank occurs such that the user can actually *see* the result (which may require additional time to post a damage event to the window manager, the compositing of the new UI, and then a vblank)

By instrumenting the xorg-x11-driver-mtev we can determine the amount of time spent between 2 through 5. By instrumenting Qt we can determine the time spent between 5 and 7. Accurately measuring the time between 7 and 8 is difficult. For the purpose of measuring the part that we can control in the touch stack, measuring 2 through 7 is sufficient.

The patches I used can be found here:

* [http://api.meego.com/public/source/home:jketreno/xorg-x11-drv-mtev/debug.patch?rev=a64635cf9c7fd59d898a7e2d63aa5d4e& xorg-x11-drv-mtev]
* [ Qt]
[[Media:qtTouchLatencyDebug.patch Qt Latency Debug Patch]]

=Using Touch with MeeGo=
MeeGo 1.2 provides a GestureArea element derived from the qml-gesturearea project.

==Gesture support in Qt==
As gesture support is added to the official versions QML, MeeGo will work to maintain compatibility with those features in a way which allows applications written with the MeeGo Components' GestureArea to still work.

For the current status of Gesture support in Qt, you can see the following bugreports:
* [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea]
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea]
* [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 Additional information].

==multiple input device support==
Qt on MeeGo is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See [https://bugs.meego.com/show_bug.cgi?id=17865 BMC#17865] if you have something to add to this topic.

==core pointer==
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc. This is typically the behavior you want.

However, if you don't want the touch device to control the pointer, you can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

==meego packages you may need==
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

=Troubleshooting=
==touch doesn't work on my system==
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

User:Jketreno/multi-point-touch

2011-06-10T00:44:39Z

Jketreno: /* Touch Latency */

=Status=
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev uses libmtdev in order to easily support both of the protocol A and B exposed by the kernel.
==Touch Latency==
When dealing with touch based interaction concepts, it is critical to minimize time difference between when the user attempts to interact with the UI and when the user receives feedback that something is happening. The variables at play which contribute heavily to this latency include:

# Firmware touch detection (it takes time for the hardware to filter out noise to determine that an actual finger touched the screen vs. an errant capacitance change)
# Kernel driver processing time
# Time between when the kernel is done and when the X input driver pulls the event out
# X input driver processing
# Time between when the input driver is done and when an Qt application receives the event
# Qt processing time
# Application code processing time which results in the UI changing
# The time between when the UI changes and when the next vblank occurs such that the user can actually *see* the result (which may require additional time to post a damage event to the window manager, the compositing of the new UI, and then a vblank)

By instrumenting the xorg-x11-driver-mtev we can determine the amount of time spent between 2 through 5. By instrumenting Qt we can determine the time spent between 5 and 7. Accurately measuring the time between 7 and 8 is difficult. For the purpose of measuring the part that we can control in the touch stack, measuring 2 through 7 is sufficient.

The patches I used can be found here:

* [http://api.meego.com/public/source/home:jketreno/xorg-x11-drv-mtev/debug.patch?rev=a64635cf9c7fd59d898a7e2d63aa5d4e& xorg-x11-drv-mtev]
* [ Qt]

=Using Touch with MeeGo=
MeeGo 1.2 provides a GestureArea element derived from the qml-gesturearea project.

==Gesture support in Qt==
As gesture support is added to the official versions QML, MeeGo will work to maintain compatibility with those features in a way which allows applications written with the MeeGo Components' GestureArea to still work.

For the current status of Gesture support in Qt, you can see the following bugreports:
* [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea]
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea]
* [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 Additional information].

==multiple input device support==
Qt on MeeGo is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See [https://bugs.meego.com/show_bug.cgi?id=17865 BMC#17865] if you have something to add to this topic.

==core pointer==
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc. This is typically the behavior you want.

However, if you don't want the touch device to control the pointer, you can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

==meego packages you may need==
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

=Troubleshooting=
==touch doesn't work on my system==
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

User:Jketreno/multi-point-touch

2011-06-09T23:05:18Z

Jketreno: /* Status */

=Status=
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev uses libmtdev in order to easily support both of the protocol A and B exposed by the kernel.
==Touch Latency==
When dealing with touch based interaction concepts, it is critical to minimize time difference between when the user attempts to interact with the UI and when the user receives feedback that something is happening. The variables at play which contribute heavily to this latency include:

# Firmware touch detection (it takes time for the hardware to filter out noise to determine that an actual finger touched the screen vs. an errant capacitance change)
# Kernel driver processing time
# Time between when the kernel is done and when the X input driver pulls the event out
# X input driver processing
# Time between when the input driver is done and when an Qt application receives the event
# Qt processing time
# Application code processing time which results in the UI changing
# The time between when the UI changes and when the next vblank occurs such that the user can actually *see* the result (which may require additional time to post a damage event to the window manager, the compositing of the new UI, and then a vblank)

By instrumenting the xorg-x11-driver-mtev we can determine the amount of time spent between 2 through 5. By instrumenting Qt we can determine the time spent between 5 and 7. Accurately measuring the time between 7 and 8 is difficult. For the purpose of measuring the part that we can control in the touch stack, measuring 2 through 7 is sufficient.

=Using Touch with MeeGo=
MeeGo 1.2 provides a GestureArea element derived from the qml-gesturearea project.

==Gesture support in Qt==
As gesture support is added to the official versions QML, MeeGo will work to maintain compatibility with those features in a way which allows applications written with the MeeGo Components' GestureArea to still work.

For the current status of Gesture support in Qt, you can see the following bugreports:
* [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea]
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea]
* [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 Additional information].

==multiple input device support==
Qt on MeeGo is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See [https://bugs.meego.com/show_bug.cgi?id=17865 BMC#17865] if you have something to add to this topic.

==core pointer==
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc. This is typically the behavior you want.

However, if you don't want the touch device to control the pointer, you can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

==meego packages you may need==
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

=Troubleshooting=
==touch doesn't work on my system==
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

User:Jketreno/multi-point-touch

2011-06-09T22:47:07Z

Jketreno: /* Status */

=Status=
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev uses libmtdev in order to easily support both of the protocol A and B exposed by the kernel.

=Using Touch with MeeGo=
MeeGo 1.2 provides a GestureArea element derived from the qml-gesturearea project.

==Gesture support in Qt==
As gesture support is added to the official versions QML, MeeGo will work to maintain compatibility with those features in a way which allows applications written with the MeeGo Components' GestureArea to still work.

For the current status of Gesture support in Qt, you can see the following bugreports:
* [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea]
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea]
* [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 Additional information].

==multiple input device support==
Qt on MeeGo is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See [https://bugs.meego.com/show_bug.cgi?id=17865 BMC#17865] if you have something to add to this topic.

==core pointer==
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc. This is typically the behavior you want.

However, if you don't want the touch device to control the pointer, you can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

==meego packages you may need==
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

=Troubleshooting=
==touch doesn't work on my system==
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

User:Jketreno/multi-point-touch

2011-06-09T17:20:07Z

Jketreno:

=Status=
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev users libmtdev in order to easily support both of the protocol A and B exposed by the kernel.

=Using Touch with MeeGo=
MeeGo 1.2 provides a GestureArea element derived from the qml-gesturearea project.

==Gesture support in Qt==
As gesture support is added to the official versions QML, MeeGo will work to maintain compatibility with those features in a way which allows applications written with the MeeGo Components' GestureArea to still work.

For the current status of Gesture support in Qt, you can see the following bugreports:
* [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea]
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea]
* [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].
* [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 Additional information].

==multiple input device support==
Qt on MeeGo is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See [https://bugs.meego.com/show_bug.cgi?id=17865 BMC#17865] if you have something to add to this topic.

==core pointer==
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc. This is typically the behavior you want.

However, if you don't want the touch device to control the pointer, you can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

==meego packages you may need==
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

=Troubleshooting=
==touch doesn't work on my system==
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

User:Jketreno/multi-point-touch

2011-06-09T16:34:31Z

Jketreno: /* multiple input device support */

Random tidbits of information about projects I'm hacking on...

==multi-point-touch==
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev users libmtdev in order to easily support both of the protocol A and B exposed by the kernel.

===touch doesn't work on my system===
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

===enabling a native application===
Prior to having patches to Qt to add XInput2.0 support, applications had to load a plugin that would connect to the X event queue and process the XInput2.0 events. That is no longer necessary and applications will now just work.

===enabling a QML application===
With Qt 4.7.0 through 4.7.2, you can use the qml-gesturearea project from qt-labs to add multi-point touch gestures to your QML applications.

As of Qt 4.7.3, you should use the MouseArea, Flickable, [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea], [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea], and [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].

Additional information in JIRA can be found [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 here].

===multiple input device support===
Qt is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

See [https://bugs.meego.com/show_bug.cgi?id=17865 BMC#17865] if you have something to add to this topic.

===core pointer===
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc.

You can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

===meego packages you may need===
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

User:Jketreno/theme-assets

2011-05-09T16:46:57Z

Jketreno: /* 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=
The following is a place holder for discussing the asset caching and rescaling support by the image provider.

// '''provider''' is a placeholder for the image provider name below
BorderImage {
width: 1024
height: 768
source: "image://provider[/dimensions[/units]]/resource[.ext]" <-- Optional extension to override the default priority ordering
source: "image://provider/100x75/resource" <-- width is 100 pixels, height 75 pixels
source: "image://provider/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 may require 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

=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-05-09T15:45:36Z

Jketreno: /* thoughts on asset theme scaling */

User:Jketreno/theme-assets

2011-05-09T15:43:52Z

Jketreno: /* 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 ('''provider''' is a placeholder for the image provider name below)
BorderImage {
width: 1024
height: 768
source: "image://provider[/dimensions[/units]]/resource[.ext]" <-- Optional extension to override the default priority ordering
source: "image://provider/100x75/resource" <-- width is 100 pixels, height 75 pixels
source: "image://provider/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-05-06T19:03:52Z

Jketreno: /* images */

'''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==
MeeGo Units are now available in the MeeGo.Components project.
git clone git://meego.gitorious.org/meego-ux/meego-ux-components
cd meego-ux-components
qmake
make && sudo make install
==accessing the units==
To start, you need to import the MeeGo Components:
import Qt 4.7
import MeeGo.Components 0.1
You can then instantiate and reference the Units:
Rectangle {
Units { id: units }
}
At this point, you can now reference the unit conversion properties via '''units'''.
==Methods==
int mm2px(real millimeters)
int inch2px(real inches)
int vp2px(real virtualPixels)
==Properties==
property real '''mm''' // Pixels per millimeter
property real '''inch''' // Pixels per inch
property real '''vp''' // Pixels per "virtual-pixel"
====a note on rounding====
Since the value of the properties returned by Units 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() methods 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)
...
}
==Examples==
Create a 10cm x 5cm box:
Rectangle {
Units { id: units }
width: units.mm2px(100.0)
height: units.mm2px(50.0)
}
==text==
Text {
font.pixelSize: units.mm2px(2.5) // create text that is 2.5mm tall
text: "2.5mm font"
}
==images==
Image {
// Since this image will be scaled on many devices,
// smooth the scaling so the image looks better
smooth: true
source: "text-bg.jpg"
width: units.mm2px(9.5)
height: units.mm2px(6.0)
}

User:Jketreno/scaling

2011-05-06T19:01:50Z

Jketreno:

'''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==
MeeGo Units are now available in the MeeGo.Components project.
git clone git://meego.gitorious.org/meego-ux/meego-ux-components
cd meego-ux-components
qmake
make && sudo make install
==accessing the units==
To start, you need to import the MeeGo Components:
import Qt 4.7
import MeeGo.Components 0.1
You can then instantiate and reference the Units:
Rectangle {
Units { id: units }
}
At this point, you can now reference the unit conversion properties via '''units'''.
==Methods==
int mm2px(real millimeters)
int inch2px(real inches)
int vp2px(real virtualPixels)
==Properties==
property real '''mm''' // Pixels per millimeter
property real '''inch''' // Pixels per inch
property real '''vp''' // Pixels per "virtual-pixel"
====a note on rounding====
Since the value of the properties returned by Units 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() methods 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)
...
}
==Examples==
Create a 10cm x 5cm box:
Rectangle {
Units { id: units }
width: units.mm2px(100.0)
height: units.mm2px(50.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)
}

User:Jketreno/scaling

2011-04-25T18:11:00Z

Jketreno:

'''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==

User:Jketreno/scaling

2011-04-25T18:10:26Z

Jketreno:

'''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/scaling

2011-04-25T18:05:09Z

Jketreno:

'''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==

File:Icon-close-multistate.png

2011-04-22T22:29:48Z

Jketreno:

File:Border-slicing.png

2011-04-22T22:28:22Z

Jketreno:

File:Border-streched.png

2011-04-22T22:28:08Z

Jketreno:

File:Downscaling-example.png

2011-04-22T22:26:05Z

Jketreno:

File:Scalable-vs-pixel.png

2011-04-22T22:25:35Z

Jketreno:

File:Scalable-example.png

2011-04-22T22:25:07Z

Jketreno:

User:Jketreno/theme-assets

2011-04-22T22:21:37Z

Jketreno:

'''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.

=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==

File:Meego-units-example-1to1.png

2011-04-22T21:58:33Z

Jketreno:

File:Meego-units-example.png

2011-04-22T21:57:25Z

Jketreno:

User:Jketreno/scaling

2011-04-22T21:53:30Z

Jketreno:

'''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/scaling

2011-04-22T21:52:45Z

Jketreno: Created page with "=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 wor..."

=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-22T21:45:52Z

Jketreno: Created page with "'''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 broke..."

'''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#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#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.

=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

2011-04-22T21:44:09Z

Jketreno:

Random tidbits of information about projects I'm hacking on...

[http://wiki.meego.com/~jketreno/multi-point-touch Multi-Point-Touch on MeeGo]<br>
[http://wiki.meego.com/~jketreno/content Improving MeeGo Content Management]<br>
[http://wiki.meego.com/~jketreno/scaling A Density Independent UI on MeeGo]<br>
[http://wiki.meego.com/~jketreno/theme-assets Theme Assets]<br>
[http://wiki.meego.com/~jketreno/meego-image-resize MeeGo Image Resize script]<br>

User:Jketreno/meego-image-resize

2011-04-04T19:42:22Z

Jketreno:

If you download a MeeGo image and would like to run it from a USB stick or MicroSD, you may want to resize the image to use all of the space available on your removable media. This script will resize the downloaded .bin image to whatever size you specify (in M). You can then mount it locally, install packages, etc. before transferring it to your removable media.
#!/bin/bash
TARGET=$1
[ -z ${TARGET} ] && die "Usage: $0 meego-image.bin [size in M]"
shift
SIZE=$1
[ -z ${SIZE} ] && SIZE=7600

function die {
echo $@
exit -1
}

function unhook {
local path=$1
[ -e "${path}" ] && {
mount | grep -q "${PWD}/${path}" && {
sudo umount "${path}" || die "Unable to unmount '${path}'"
}
rmdir "${path}" || die "Unable to rmdir '${path}'"
}
return 0
}

function hook {
local path=$1
local image=$2
unhook "${path}"
mkdir "${path}" || die "Unable to create directory '${path}'"
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep primary))
local OFFSET=${VALUE[1]/B}
sudo mount -o loop,offset=${OFFSET} "${image}" "${path}" ||
die "Unable to mount '${image}' to '${path}'"
return 0
}

function resize {
local image=$1
local size=$2
local tmp=($(du --apparent-size -B $((1024*1024)) "${image}"))
local current="${tmp[0]}"
[ "${current}" != "${size}" ] && {
echo -n "Settting '${image}' to ${size}M..."
dd if=/dev/zero of=${image} bs=1M seek=$((size - 1)) count=1 > /dev/null
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep btrfs\$))
[ -z "${VALUE[0]}" ] && die "$0 only supports BTRFS images"
local OFFSET=${VALUE[1]/B}
echo -e "rm 1\nmkpart primary btrfs ${OFFSET}b -1\nq" | parted "${image}" > /dev/null
echo "done"
}

return 0
}

resize "${TARGET}" 7600

echo -n "Finalizing image resize..."
TMP=.tmp-resize
hook ${TMP} "${TARGET}"
sudo btrfs filesystem resize max "${TARGET}".*${PWD}/${TMP}.*$,\1,p")
unhook ${TMP}
echo "done"

'''NOTE:''' To perform the above you need the btrfs utilities.

User:Jketreno/meego-image-resize

2011-04-04T19:28:19Z

Jketreno:

If you download a MeeGo image and would like to run it from a USB stick or MicroSD, you may want to resize the image to use all of the space available on your removable media. This script will resize the downloaded .bin image to whatever size you specify (in M). You can then mount it locally, install packages, etc. before transferring it to your removable media.
#!/bin/bash
TARGET=$1
[ -z ${TARGET} ] && die "Usage: $0 meego-image.bin [size in M]"
shift
SIZE=$1
[ -z ${SIZE} ] && SIZE=7600

function die {
echo $@
exit -1
}

function unhook {
local path=$1
[ -e "${path}" ] && {
mount | grep -q "${PWD}/${path}" && {
sudo umount "${path}" || die "Unable to unmount '${path}'"
}
rmdir "${path}" || die "Unable to rmdir '${path}'"
}
return 0
}

function hook {
local path=$1
local image=$2
unhook "${path}"
mkdir "${path}" || die "Unable to create directory '${path}'"
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep primary))
local OFFSET=${VALUE[1]/B}
sudo mount -o loop,offset=${OFFSET} "${image}" "${path}" ||
die "Unable to mount '${image}' to '${path}'"
return 0
}

function resize {
local image=$1
local size=$2
local tmp=($(du --apparent-size -B $((1024*1024)) "${image}"))
local current="${tmp[0]}"
[ "${current}" != "${size}" ] && {
echo -n "Settting '${image}' to ${size}M..."
dd if=/dev/zero of=${image} bs=1M seek=$((size - 1)) count=1 > /dev/null
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep btrfs\$))
[ -z "${VALUE[0]}" ] && die "$0 only supports BTRFS images"
local OFFSET=${VALUE[1]/B}
echo -e "rm 1\nmkpart primary btrfs ${OFFSET}b -1\nq" | parted "${image}" > /dev/null
echo "done"
}

return 0
}

resize "${TARGET}" 7600

echo -n "Finalizing image resize..."
TMP=.tmp-resize
hook ${TMP} "${TARGET}"
sudo btrfsctl -r ${SIZE}M -A $(mount | sed -ne "s,^$[^ ]*$ .*${PWD}/${TMP}.*$,\1,p")
unhook ${TMP}
echo "done"

'''NOTE:''' The above might not actually resize the file system within the disk image. If you mount the drive and find that it is only 2G still, you can fix this by using meego-chroot-sdk to enter the image on your system. Then perform the following:
zypper install btrfs-progs
btrfs filesystem resize max /
Your file system should now be resized to the full image size.

User:Jketreno/meego-image-resize

2011-04-04T19:27:45Z

Jketreno:

If you download a MeeGo image and would like to run it from a USB stick or MicroSD, you may want to resize the image to use all of the space available on your removable media. This script will resize the downloaded .bin image to whatever size you specify (in M). You can then mount it locally, install packages, etc. before transferring it to your removable media.
#!/bin/bash
TARGET=$1
[ -z ${TARGET} ] && die "Usage: $0 meego-image.bin [size in M]"
shift
SIZE=$1
[ -z ${SIZE} ] && SIZE=7600

function die {
echo $@
exit -1
}

function unhook {
local path=$1
[ -e "${path}" ] && {
mount | grep -q "${PWD}/${path}" && {
sudo umount "${path}" || die "Unable to unmount '${path}'"
}
rmdir "${path}" || die "Unable to rmdir '${path}'"
}
return 0
}

function hook {
local path=$1
local image=$2
unhook "${path}"
mkdir "${path}" || die "Unable to create directory '${path}'"
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep primary))
local OFFSET=${VALUE[1]/B}
sudo mount -o loop,offset=${OFFSET} "${image}" "${path}" ||
die "Unable to mount '${image}' to '${path}'"
return 0
}

function resize {
local image=$1
local size=$2
local tmp=($(du --apparent-size -B $((1024*1024)) "${image}"))
local current="${tmp[0]}"
[ "${current}" != "${size}" ] && {
echo -n "Settting '${image}' to ${size}M..."
dd if=/dev/zero of=${image} bs=1M seek=$((size - 1)) count=1 > /dev/null
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep btrfs\$))
[ -z "${VALUE[0]}" ] && die "$0 only supports BTRFS images"
local OFFSET=${VALUE[1]/B}
echo -e "rm 1\nmkpart primary btrfs ${OFFSET}b -1\nq" | parted "${image}" > /dev/null
echo "done"
}

return 0
}

resize "${TARGET}" 7600

echo -n "Finalizing image resize..."
TMP=.tmp-resize
hook ${TMP} "${TARGET}"
sudo btrfsctl -r ${SIZE}M -A $(mount | sed -ne "s,^$[^ ]*$ .*${PWD}/${TMP}.*$,\1,p")
unhook ${TMP}
echo "done"

'''NOTE:''' The above might not actually resize the file system within the disk image. If you mount the drive and find that it is only 2G still, you can fix this by using meego-chroot-sdk to enter the image on your system. Then perform the following:
zypper install btrfs-progs
btrfs filesystem resize max /
Your file system should now be resized to the full image size.

zypper install

User:Jketreno/meego-image-resize

2011-04-01T16:28:08Z

Jketreno:

If you download a MeeGo image and would like to run it from a USB stick or MicroSD, you may want to resize the image to use all of the space available on your removable media. This script will resize the downloaded .bin image to whatever size you specify (in M). You can then mount it locally, install packages, etc. before transferring it to your removable media.
#!/bin/bash
TARGET=$1
[ -z ${TARGET} ] && die "Usage: $0 meego-image.bin [size in M]"
shift
SIZE=$1
[ -z ${SIZE} ] && SIZE=7600

function die {
echo $@
exit -1
}

function unhook {
local path=$1
[ -e "${path}" ] && {
mount | grep -q "${PWD}/${path}" && {
sudo umount "${path}" || die "Unable to unmount '${path}'"
}
rmdir "${path}" || die "Unable to rmdir '${path}'"
}
return 0
}

function hook {
local path=$1
local image=$2
unhook "${path}"
mkdir "${path}" || die "Unable to create directory '${path}'"
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep primary))
local OFFSET=${VALUE[1]/B}
sudo mount -o loop,offset=${OFFSET} "${image}" "${path}" ||
die "Unable to mount '${image}' to '${path}'"
return 0
}

function resize {
local image=$1
local size=$2
local tmp=($(du --apparent-size -B $((1024*1024)) "${image}"))
local current="${tmp[0]}"
[ "${current}" != "${size}" ] && {
echo -n "Settting '${image}' to ${size}M..."
dd if=/dev/zero of=${image} bs=1M seek=$((size - 1)) count=1 > /dev/null
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep btrfs\$))
[ -z "${VALUE[0]}" ] && die "$0 only supports BTRFS images"
local OFFSET=${VALUE[1]/B}
echo -e "rm 1\nmkpart primary btrfs ${OFFSET}b -1\nq" | parted "${image}" > /dev/null
echo "done"
}

return 0
}

resize "${TARGET}" 7600

echo -n "Finalizing image resize..."
TMP=.tmp-resize
hook ${TMP} "${TARGET}"
sudo btrfsctl -r ${SIZE}M -A $(mount | sed -ne "s,^$[^ ]*$ .*${PWD}/${TMP}.*$,\1,p")
unhook ${TMP}
echo "done"

User:Jketreno/meego-image-resize

2011-04-01T16:18:55Z

Jketreno:

#!/bin/bash
TARGET=$1
[ -z ${TARGET} ] && die "Usage: $0 meego-image.bin [size in M]"
shift
SIZE=$1
[ -z ${SIZE} ] && SIZE=7600

function die {
echo $@
exit -1
}

function unhook {
local path=$1
[ -e "${path}" ] && {
mount | grep -q "${PWD}/${path}" && {
sudo umount "${path}" || die "Unable to unmount '${path}'"
}
rmdir "${path}" || die "Unable to rmdir '${path}'"
}
return 0
}

function hook {
local path=$1
local image=$2
unhook "${path}"
mkdir "${path}" || die "Unable to create directory '${path}'"
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep primary))
local OFFSET=${VALUE[1]/B}
sudo mount -o loop,offset=${OFFSET} "${image}" "${path}" ||
die "Unable to mount '${image}' to '${path}'"
return 0
}

function resize {
local image=$1
local size=$2
local tmp=($(du --apparent-size -B $((1024*1024)) "${image}"))
local current="${tmp[0]}"
[ "${current}" != "${size}" ] && {
echo -n "Settting '${image}' to ${size}M..."
dd if=/dev/zero of=${image} bs=1M seek=$((size - 1)) count=1 > /dev/null
local VALUE=($(echo -ne "u b\np\nq\n" | parted "${image}" | grep btrfs\$))
[ -z "${VALUE[0]}" ] && die "$0 only supports BTRFS images"
local OFFSET=${VALUE[1]/B}
echo -e "rm 1\nmkpart primary btrfs ${OFFSET}b -1\nq" | parted "${image}" > /dev/null
echo "done"
}

return 0
}

resize "${TARGET}" 7600

echo -n "Finalizing image resize..."
TMP=.tmp-resize
hook ${TMP} "${TARGET}"
sudo btrfsctl -r ${SIZE}M -A $(mount | sed -ne "s,^$[^ ]*$ .*${PWD}/${TMP}.*$,\1,p")
unhook ${TMP}
echo "done"

User:Jketreno/meego-image-resize

2011-04-01T16:17:11Z

Jketreno: Created page with "#!/bin/bash TARGET=$1 [ -z ${TARGET} ] && die "Usage: $0 meego-image.bin [size in M]" shift SIZE=$1 [ -z ${SIZE} ] && SIZE=7600 function die { echo $@ exit -1 } function unh…"

User:Jketreno

2011-04-01T16:15:56Z

Jketreno:

MeeGo UX Components

2011-03-30T22:05:06Z

Jketreno:

=Overview=
This page will walk you through the process of creating an application with the QML based MeeGo UX Components. The MeeGo UX Components provide a set UI elements allowing you to quickly build applications which tightly integrate with the MeeGo user experience.

=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 [http://link-to-download-meego-image.com MeeGo system], within the [http://link-to-sdk-qemu-info.com MeeGo SDK QEMU environment], or within a [http://link-to-meego-chroot-info.com 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)

User:Jketreno/multi-point-touch

2011-03-12T16:24:55Z

Jketreno: /* enabling a QML application */

Random tidbits of information about projects I'm hacking on...

==multi-point-touch==
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev users libmtdev in order to easily support both of the protocol A and B exposed by the kernel.

===touch doesn't work on my system===
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

===enabling a native application===
Prior to having patches to Qt to add XInput2.0 support, applications had to load a plugin that would connect to the X event queue and process the XInput2.0 events. That is no longer necessary and applications will now just work.

===enabling a QML application===
With Qt 4.7.0 through 4.7.2, you can use the qml-gesturearea project from qt-labs to add multi-point touch gestures to your QML applications.

As of Qt 4.7.3, you should use the MouseArea, Flickable, [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea], [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-154 PanArea], and [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].

Additional information in JIRA can be found [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 here].

===multiple input device support===
Qt is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

===core pointer===
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc.

You can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

===meego packages you may need===
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

User:Jketreno/multi-point-touch

2011-03-08T00:31:21Z

Jketreno: /* touch doesn't work on my system */

Random tidbits of information about projects I'm hacking on...

==multi-point-touch==
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev users libmtdev in order to easily support both of the protocol A and B exposed by the kernel.

===touch doesn't work on my system===
If you are using the evtouch driver on your system, you may experience problems due to the input driver your kernel is using. If the kernel driver does not advertise to user space that it supports the left button (by setting the BTN_LEFT bit in the input_device's keybit field) then the X input driver will not map those button identifiers to the "Button Left" label. Qt relies on correctly set button labels in order to map the incoming touch data to the appropriate touch device.

You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

Fixing the driver for your system may be as easy as adding the following line to the driver's initialization sequence:

ts->idev->keybit[BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT);

===enabling a native application===
Prior to having patches to Qt to add XInput2.0 support, applications had to load a plugin that would connect to the X event queue and process the XInput2.0 events. That is no longer necessary and applications will now just work.

===enabling a QML application===
With Qt 4.7.0 through 4.7.2, you can use the qml-gesturearea project from qt-labs to add multi-point touch gestures to your QML applications.

As of Qt 4.7.3, you should use the MouseArea, Flickable, [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea], and [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].

Additional information in JIRA can be found [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 here].

===multiple input device support===
Qt is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

===core pointer===
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc.

You can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

===meego packages you may need===
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

User:Jketreno/multi-point-touch

2011-03-07T16:39:52Z

Jketreno:

Random tidbits of information about projects I'm hacking on...

==multi-point-touch==
The kernel's multi-touch-protocol is now supported in MeeGo. Qt applications will receive Touch events and can use the Qt gesture infrastructure. Non-Qt applications will need to write to XInput2.0 and extract contact data from the XEvent data.

The general flow is:
HW => Kernel driver => multi-touch-protocol => xorg-x11-input-mtev => XEvent => Application

xorg-x11-input-mtev users libmtdev in order to easily support both of the protocol A and B exposed by the kernel.

===touch doesn't work on my system===
If you are using the evtouch driver on your system, you may experience problems due to the X evtouch input driver incorrectly advertising that it provides button labels, but not actually setting them to valid X atoms. You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

===enabling a native application===
Prior to having patches to Qt to add XInput2.0 support, applications had to load a plugin that would connect to the X event queue and process the XInput2.0 events. That is no longer necessary and applications will now just work.

===enabling a QML application===
With Qt 4.7.0 through 4.7.2, you can use the qml-gesturearea project from qt-labs to add multi-point touch gestures to your QML applications.

As of Qt 4.7.3, you should use the MouseArea, Flickable, [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea], and [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].

Additional information in JIRA can be found [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 here].

===multiple input device support===
Qt is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

===core pointer===
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc.

You can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

===meego packages you may need===
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

User:Jketreno/multi-point-touch

2011-02-28T17:36:27Z

Jketreno: /* touch doesn't work on my system */

Random tidbits of information about projects I'm hacking on...

==multi-point-touch==
During the MeeGo Conference I gave a presentation on multi-point-touch support on MeeGo ([http://conference2010.meego.com/session/multi-touch-meego-hardware-user overview and video] [http://conference2010.meego.com/sites/all/files/sessions/meego-conference-2010-multi-point-touch.odp slides]). As mentioned during that presentation, to add multi-point-touch to Qt applications running on top of MeeGo 1.1 requires a few changes.

The feature in MeeGo's bugzilla which is tracking the status of inclusion can be found [http://bugs.meego.com/show_bug.cgi?id=11625 here].

As you will find in the comments on that bug, since the MeeGo Conference last year, work has continued to move forward. The components that need to be changed in current (as of early January 2011) MeeGo systems are now all available in MeeGo Trunk.

If you are running an older image, you need to update to the latest version of Qt in Trunk (build version stamp 4.7.1-4 or newer), xorg-x11-drv-mtev (remove xf86-input-mtev if you have it), and mtdev.

'''NOTE''': If you had previously install the multipointtouchplugin, you need to remove it via one of these methods:
zypper remove multipointtouchplugin
or
rm /usr/lib/qt4/plugins/libmultipointtouchplugin.so
If you do not remove that plugin, touch will not work correctly with the XInput2.0 enabled version of Qt.

===touch doesn't work on my system===
If you are using the evtouch driver on your system, you may experience problems due to the X evtouch input driver incorrectly advertising that it provides button labels, but not actually setting them to valid X atoms. You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors or "Button Unknown" labels. A correct driver will report labels such as: Button Left, Button Right, etc.

See [https://bugs.meego.com/show_bug.cgi?id=12777 BMC#12777] for additional details on this problem.

===enabling a native application===
Prior to having patches to Qt to add XInput2.0 support, applications had to load a plugin that would connect to the X event queue and process the XInput2.0 events. That is no longer necessary and applications will now just work.

===enabling a QML application===
With Qt 4.7.0 through 4.7.2, you can use the qml-gesturearea project from qt-labs to add multi-point touch gestures to your QML applications.

As of Qt 4.7.3, you should use the MouseArea, Flickable, [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea], and [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].

Additional information in JIRA can be found [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 here].

===multiple input device support===
Qt is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

===core pointer===
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc.

You can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

===meego packages you may need===
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

User:Jketreno

2011-02-23T18:59:00Z

Jketreno: Replaced content with "Random tidbits of information about projects I'm hacking on... [http://wiki.meego.com/~jketreno/multi-point-touch Multi-Point-Touch on MeeGo]<br> [http://wiki.meego.com/~jke…"

User:Jketreno/multi-point-touch

2011-02-23T18:57:14Z

Jketreno: Created page with "Random tidbits of information about projects I'm hacking on... ==multi-point-touch== During the MeeGo Conference I gave a presentation on multi-point-touch support on MeeGo ([ht…"

Random tidbits of information about projects I'm hacking on...

==multi-point-touch==
During the MeeGo Conference I gave a presentation on multi-point-touch support on MeeGo ([http://conference2010.meego.com/session/multi-touch-meego-hardware-user overview and video] [http://conference2010.meego.com/sites/all/files/sessions/meego-conference-2010-multi-point-touch.odp slides]). As mentioned during that presentation, to add multi-point-touch to Qt applications running on top of MeeGo 1.1 requires a few changes.

The feature in MeeGo's bugzilla which is tracking the status of inclusion can be found [http://bugs.meego.com/show_bug.cgi?id=11625 here].

As you will find in the comments on that bug, since the MeeGo Conference last year, work has continued to move forward. The components that need to be changed in current (as of early January 2011) MeeGo systems are now all available in MeeGo Trunk.

If you are running an older image, you need to update to the latest version of Qt in Trunk (build version stamp 4.7.1-4 or newer), xorg-x11-drv-mtev (remove xf86-input-mtev if you have it), and mtdev.

'''NOTE''': If you had previously install the multipointtouchplugin, you need to remove it via one of these methods:
zypper remove multipointtouchplugin
or
rm /usr/lib/qt4/plugins/libmultipointtouchplugin.so
If you do not remove that plugin, touch will not work correctly with the XInput2.0 enabled version of Qt.

===touch doesn't work on my system===
If you are using the evtouch driver on your system, you may experience problems due to the X evtouch input driver incorrectly advertising that it provides button labels, but not actually setting them to valid X atoms. You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors.

===enabling a native application===
Prior to having patches to Qt to add XInput2.0 support, applications had to load a plugin that would connect to the X event queue and process the XInput2.0 events. That is no longer necessary and applications will now just work.

===enabling a QML application===
With Qt 4.7.0 through 4.7.2, you can use the qml-gesturearea project from qt-labs to add multi-point touch gestures to your QML applications.

As of Qt 4.7.3, you should use the MouseArea, Flickable, [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea], and [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].

Additional information in JIRA can be found [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 here].

===multiple input device support===
Qt is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

===core pointer===
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc.

You can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

===meego packages you may need===
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

User:Jketreno

2011-02-23T00:21:45Z

Jketreno:

Random tidbits of information about projects I'm hacking on...

==multi-point-touch==
During the MeeGo Conference I gave a presentation on multi-point-touch support on MeeGo ([http://conference2010.meego.com/session/multi-touch-meego-hardware-user overview and video] [http://conference2010.meego.com/sites/all/files/sessions/meego-conference-2010-multi-point-touch.odp slides]). As mentioned during that presentation, to add multi-point-touch to Qt applications running on top of MeeGo 1.1 requires a few changes.

The feature in MeeGo's bugzilla which is tracking the status of inclusion can be found [http://bugs.meego.com/show_bug.cgi?id=11625 here].

As you will find in the comments on that bug, since the MeeGo Conference last year, work has continued to move forward. The components that need to be changed in current (as of early January 2011) MeeGo systems are now all available in MeeGo Trunk.

If you are running an older image, you need to update to the latest version of Qt in Trunk (build version stamp 4.7.1-4 or newer), xorg-x11-drv-mtev (remove xf86-input-mtev if you have it), and mtdev.

'''NOTE''': If you had previously install the multipointtouchplugin, you need to remove it via one of these methods:
zypper remove multipointtouchplugin
or
rm /usr/lib/qt4/plugins/libmultipointtouchplugin.so
If you do not remove that plugin, touch will not work correctly with the XInput2.0 enabled version of Qt.

===touch doesn't work on my system===
If you are using the evtouch driver on your system, you may experience problems due to the X evtouch input driver incorrectly advertising that it provides button labels, but not actually setting them to valid X atoms. You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors.

===enabling a native application===
Prior to having patches to Qt to add XInput2.0 support, applications had to load a plugin that would connect to the X event queue and process the XInput2.0 events. That is no longer necessary and applications will now just work.

===enabling a QML application===
With Qt 4.7.0 through 4.7.2, you can use the qml-gesturearea project from qt-labs to add multi-point touch gestures to your QML applications.

As of Qt 4.7.3, you should use the MouseArea, Flickable, [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea], and [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].

Additional information in JIRA can be found [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 here].

===multiple input device support===
Qt is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

===core pointer===
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc.

You can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

===meego packages you may need===
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

User:Jketreno

2011-02-23T00:21:19Z

Jketreno: /* enabling a QML application */

Random tidbits of information about projects I'm hacking on...

==multi-point-touch==
During the MeeGo Conference I gave a presentation on multi-point-touch support on MeeGo ([http://conference2010.meego.com/session/multi-touch-meego-hardware-user overview and video] [http://conference2010.meego.com/sites/all/files/sessions/meego-conference-2010-multi-point-touch.odp slides]). As mentioned during that presentation, to add multi-point-touch to Qt applications running on top of MeeGo 1.1 requires a few changes.

The feature in MeeGo's bugzilla which is tracking the status of inclusion can be found [http://bugs.meego.com/show_bug.cgi?id=11625 here].

As you will find in the comments on that bug, since the MeeGo Conference last year, work has continued to move forward. The components that need to be changed in current (as of early January 2011) MeeGo systems are now all available in MeeGo Trunk.

If you are running an older image, you need to update to the latest version of Qt in Trunk (build version stamp 4.7.1-4 or newer), xorg-x11-drv-mtev (remove xf86-input-mtev if you have it), and mtdev.

'''NOTE''': If you had previously install the multipointtouchplugin, you need to remove it via one of these methods:
zypper remove multipointtouchplugin
or
rm /usr/lib/qt4/plugins/libmultipointtouchplugin.so
If you do not remove that plugin, touch will not work correctly with the XInput2.0 enabled version of Qt.

===touch doesn't work on my system===
If you are using the evtouch driver on your system, you may experience problems due to the X evtouch input driver incorrectly advertising that it provides button labels, but not actually setting them to valid X atoms. You can determine if this is the case on your system by running:

xinput list --long "Virtual core pointer"

On a functional input driver, you will see various text names for the field 'Button labels:' On a broken input driver, you will see a series of X BadAtom errors.

===enabling a native application===
Prior to having patches to Qt to add XInput2.0 support, applications had to load a plugin that would connect to the X event queue and process the XInput2.0 events. That is no longer necessary and applications will now just work.

===enabling a QML application===
With Qt 4.7.0 through 4.7.2, you can use the qml-gesturearea project from qt-labs to add multi-point touch gestures to your QML applications.

As of Qt 4.7.3, you should use the MouseArea, Flickable, [http://bugreports.qt.nokia.com/browse/QTBUG-15491 PinchArea], and [http://bugreports.qt.nokia.com/browse/QTBUG-11638 TouchArea]. The GIT tree for TouchArea is [http://qt.gitorious.org/qt-labs/qml-toucharea here].

Additional information in JIRA can be found [http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-153 here].

===qml-gesturearea===
As Frederik Gladhorn indicated during [http://conference2010.meego.com/session/gestures-qt his talk] at the MeeGo Conference in Dublin, the folks over at Qt have been working on an improved QML GestureArea component.

You can pull and play with what they're cooking as follows:
git clone git://gitorious.org/qt-labs/qml-gesturearea.git
git clone git://gitorious.org/qt-labs/qml-gestures-examples.git
If you are building qml-gesturearea with a version of Qt prior to 4.7.1, you may need to patch it to get it to build:
cd qml-gesturearea
sed -i -e 's,q->timeout(),700,g' qdeclarativegesturerecognizers.cpp
qmake
make && sudo make install

===multiple input device support===
Qt is configured to listen to pointer (mouse) events the first core pointer provided by X. Additional core pointers are ignored. Touch events are received from any touch device bound to the first core pointer, as well as any touch devices which are floating (not bound to any core pointer)

===core pointer===
If you do nothing, X will default to binding an input device to the first Core Pointer. This means that the touch screen will default to control the cursor --as you move your finger around, mouse events will be generated, the cursor will move, etc.

You can use the xinput utility to "float" the touch device. On the Lenovo S10, running 'xinput list' shows something like the following:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Cando Corporation Cando 10.1 Multi Touch Panel with Controller id=13 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=16 [slave pointer (2)]
...

Looking at the above, you can see the touch device (Cando Corporation...) is device id 13. To float that input device, run:

xinput float 13

'''NOTE:''' If you don't have xinput, you can install it on MeeGo by running:
zypper install xorg-x11-utils-xinput

Once you float the input device, it will no longer move the mouse pointer. To reattach it, run:
xinput reattach 13 2
'2' is the device ID for the 'Virtual core pointer' you are reattaching the device to.

To keep X from connecting a device to the core pointer when starting the system, you can add:
Option "SendCoreEvents" "false"
to the InputClass section for the device, for example you can place the following in /usr/share/X11/xorg.conf.d as 60-cando.conf:
Section "InputClass"
Identifier "Cando Multi Touch Panel"
MatchVendor "Cando"
MatchDevicePath "/dev/input/event*"
Driver "mtev"
Option "SendCoreEvents" "false"
EndSection

===meego packages you may need===
To perform the above steps on this wiki, you may need to install the xinput utility:
zypper install xorg-x11-utils-xinput

User:Jketreno/content

2011-02-18T18:16:00Z

Jketreno: /* locations on disk */

=content management for MeeGo=
This page captures the stream of thoughts related to ways to improve content management on MeeGo.

The primary goal is to provide a responsive user experience for applications which are consuming content. This means that content must be inspected and had meta data extracted from it (including thumbnails) prior to the application requesting the content. A consequence of that requirement means that on-the-fly indexing is a dead end as you can not guarantee that indexing will be complete when the application is launched.

The best time to perform the indexing and scanning of content is at the time of content acquisition; the user is already expecting to wait for content to copy/save to the system--a minor delay in an already anticipated delay is much better than a delay at a time when the user does not expect a delay.

A side benefit of performing index-at-acquisition is that we no longer have to perform any background indexing or thumb nailing on the system -- which has frequently introduced sporadic responsiveness to the UI as the system can inadvertently lock system resources while an index is occurring.

==index-at-acquisition==
Since MeeGo provides a posix interface to the file system, it would be problematic to enforce a requirement that all applications use a specific API for reading and writing to the content storage locations. An alternative approach is to use a file system in user space (FUSE). The FUSE file system would be mounted to the various locations in the user's home directory where content must be placed for it to be accessible from the content management applications.

The FUSE implementation would block the final close of a file within the mounted file system until indexing, thumb nailing, and meta data extraction is complete. A benefit to this approach is that the content being written to disk is (in most cases) present in RAM and more easily accessed for whatever processing is required. This means that in addition to the benefits already mentioned, the cost of indexing and thumb nailing at index-at-acquisition time is less than the cost of on-demand/on-the-fly indexing.

==Photos==
Thumb nailing of photos will occur at the time of acquisition, as outlined above. The specific thumbnails generated by the FUSE are as follows:
* Thumbnail for view in photo viewer -- size is target display density dependent, based on intended physical size of thumbnail. Two thumbnails are generated, one for each orientation. Enhanced functionality to ensure that regions-of-interest (ROI) are placed into the thumbnail may be employed via manual or automatic detection (for example, auto-center of detected faces, 5:3 ratio split rules for high contrast/line detection, etc.)
* Target display resolution scaled image -- used for "full screen" mode
* Full resolution image -- asynchronously used for "zoom" mode and kept as the original image source, unmodified

==locations on disk==
The following locations are subject to index-at-acquisition:<br>
${HOME}/Pictures<br>
${HOME}/Videos<br>
${HOME}/Music<br>
${HOME}/Downloads<br>

==database ontologies==
'''tbd'''

==MeeGo APIs for accessing content and data==
'''tbd'''

==FUSE implementation details==
'''tbd'''

User:Jketreno/content

2011-02-18T18:15:47Z

Jketreno: /* locations on disk */

=content management for MeeGo=
This page captures the stream of thoughts related to ways to improve content management on MeeGo.

The primary goal is to provide a responsive user experience for applications which are consuming content. This means that content must be inspected and had meta data extracted from it (including thumbnails) prior to the application requesting the content. A consequence of that requirement means that on-the-fly indexing is a dead end as you can not guarantee that indexing will be complete when the application is launched.

The best time to perform the indexing and scanning of content is at the time of content acquisition; the user is already expecting to wait for content to copy/save to the system--a minor delay in an already anticipated delay is much better than a delay at a time when the user does not expect a delay.

A side benefit of performing index-at-acquisition is that we no longer have to perform any background indexing or thumb nailing on the system -- which has frequently introduced sporadic responsiveness to the UI as the system can inadvertently lock system resources while an index is occurring.

==index-at-acquisition==
Since MeeGo provides a posix interface to the file system, it would be problematic to enforce a requirement that all applications use a specific API for reading and writing to the content storage locations. An alternative approach is to use a file system in user space (FUSE). The FUSE file system would be mounted to the various locations in the user's home directory where content must be placed for it to be accessible from the content management applications.

The FUSE implementation would block the final close of a file within the mounted file system until indexing, thumb nailing, and meta data extraction is complete. A benefit to this approach is that the content being written to disk is (in most cases) present in RAM and more easily accessed for whatever processing is required. This means that in addition to the benefits already mentioned, the cost of indexing and thumb nailing at index-at-acquisition time is less than the cost of on-demand/on-the-fly indexing.

==Photos==
Thumb nailing of photos will occur at the time of acquisition, as outlined above. The specific thumbnails generated by the FUSE are as follows:
* Thumbnail for view in photo viewer -- size is target display density dependent, based on intended physical size of thumbnail. Two thumbnails are generated, one for each orientation. Enhanced functionality to ensure that regions-of-interest (ROI) are placed into the thumbnail may be employed via manual or automatic detection (for example, auto-center of detected faces, 5:3 ratio split rules for high contrast/line detection, etc.)
* Target display resolution scaled image -- used for "full screen" mode
* Full resolution image -- asynchronously used for "zoom" mode and kept as the original image source, unmodified

==locations on disk==
The following locations are subject to index-on-acquisition:<br>
${HOME}/Pictures<br>
${HOME}/Videos<br>
${HOME}/Music<br>
${HOME}/Downloads<br>

==database ontologies==
'''tbd'''

==MeeGo APIs for accessing content and data==
'''tbd'''

==FUSE implementation details==
'''tbd'''

User:Jketreno/content

2011-02-17T18:36:24Z

Jketreno:

=content management for MeeGo=
This page captures the stream of thoughts related to ways to improve content management on MeeGo.

The primary goal is to provide a responsive user experience for applications which are consuming content. This means that content must be inspected and had meta data extracted from it (including thumbnails) prior to the application requesting the content. A consequence of that requirement means that on-the-fly indexing is a dead end as you can not guarantee that indexing will be complete when the application is launched.

The best time to perform the indexing and scanning of content is at the time of content acquisition; the user is already expecting to wait for content to copy/save to the system--a minor delay in an already anticipated delay is much better than a delay at a time when the user does not expect a delay.

A side benefit of performing index-at-acquisition is that we no longer have to perform any background indexing or thumb nailing on the system -- which has frequently introduced sporadic responsiveness to the UI as the system can inadvertently lock system resources while an index is occurring.

==index-at-acquisition==
Since MeeGo provides a posix interface to the file system, it would be problematic to enforce a requirement that all applications use a specific API for reading and writing to the content storage locations. An alternative approach is to use a file system in user space (FUSE). The FUSE file system would be mounted to the various locations in the user's home directory where content must be placed for it to be accessible from the content management applications.

The FUSE implementation would block the final close of a file within the mounted file system until indexing, thumb nailing, and meta data extraction is complete. A benefit to this approach is that the content being written to disk is (in most cases) present in RAM and more easily accessed for whatever processing is required. This means that in addition to the benefits already mentioned, the cost of indexing and thumb nailing at index-at-acquisition time is less than the cost of on-demand/on-the-fly indexing.

==Photos==
Thumb nailing of photos will occur at the time of acquisition, as outlined above. The specific thumbnails generated by the FUSE are as follows:
* Thumbnail for view in photo viewer -- size is target display density dependent, based on intended physical size of thumbnail. Two thumbnails are generated, one for each orientation. Enhanced functionality to ensure that regions-of-interest (ROI) are placed into the thumbnail may be employed via manual or automatic detection (for example, auto-center of detected faces, 5:3 ratio split rules for high contrast/line detection, etc.)
* Target display resolution scaled image -- used for "full screen" mode
* Full resolution image -- asynchronously used for "zoom" mode and kept as the original image source, unmodified

==locations on disk==
${HOME}/Pictures<br>
${HOME}/Videos<br>
${HOME}/Music<br>

==database ontologies==
'''tbd'''

==MeeGo APIs for accessing content and data==
'''tbd'''

==FUSE implementation details==
'''tbd'''