(→images) |
|||
| Line 90: | Line 90: | ||
==images== | ==images== | ||
Image { | Image { | ||
| + | // Since this image will be scaled on many devices, | ||
| + | // smooth the scaling so the image looks better | ||
| + | smooth: true | ||
source: "text-bg.jpg" | source: "text-bg.jpg" | ||
width: units.mm2px(9.5) | width: units.mm2px(9.5) | ||
height: units.mm2px(6.0) | height: units.mm2px(6.0) | ||
| - | |||
| - | |||
} | } | ||
<!--.... | <!--.... | ||
THIS PAGE IS A WORK IN PROGRESS AND DOES NOT NECESSARILY CORRESPOND TO CURRENT REALITY
Contents |
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.)
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.
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.
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.
The following provides examples of potential screen profiles which should be supported by MeeGo:
| Handset | ||||
| Diagonal | Resolution | PPI | Aspect Ratio | |
| 4" | 800x480 | 233 | 15:9 | |
| 4.3" | 960x540 | 256 | 16:9 | |
| 3.67" | 864x480 | 269 | 16.2:9 | |
| Tablet | ||||
| Diagonal | Resolution | PPI | Aspect Ratio | |
| 10" | 1024x600 | 119 | 15.4:9 | |
| 10" | 1024x600 | 119 | 15.4:9 | |
| 11.6" | 1360x768 | 135 | 16:9 | |
| 10" | 1280x800 | 151 | 16:10 | |
| 7" | 1280x800 | 216 | 16:10 | |
Industry list of display densities
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
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.
int mm2px(real millimeters) int inch2px(real inches) int vp2px(real virtualPixels)
property real mm // Pixels per millimeter property real inch // Pixels per inch property real vp // Pixels per "virtual-pixel"
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)
...
}
Create a 10cm x 5cm box:
Rectangle {
Units { id: units }
width: units.mm2px(100.0)
height: units.mm2px(50.0)
}
Text {
font.pixelSize: units.mm2px(2.5) // create text that is 2.5mm tall
text: "2.5mm font"
}
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)
}