Revision as of 18:05, 25 April 2011

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.

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.

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:

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