MeeGo wiki - User contributions [en]

Lexicon

2011-04-27T13:48:22Z

Amigadave: typo

#REDIRECT [[Glossary]]

Lexicon

2011-04-27T13:48:10Z

Amigadave: redirect to glossary

# REDIRECT [[Glossary]]

Glossary

2011-04-27T13:48:00Z

Amigadave: copy introduction from Lexicon

MeeGo has many terms whose meaning is not immediately apparent. This page will attempt to help rectify that.

== A ==
;''Architecture: ''
:The Meego architecture describes the components for the whole system and is broken down into Layer, Domain and Api http://meego.com/developers/meego-architecture

;''ARM: ''
:The CPU powering the N900 and many other mobile devices. See [[ARM]]

;''ATM: ''
:At The Moment

== B ==

;''Beagle-board: ''
:Is an OMAP3 based development board suitable for embedded projects. See [[ARM/Meego on the Beagle]]

;''BME (Battery Management Entity): ''
:Is proxied to D-Bus via the bme-dbus-proxy daemon

;''BOSS: (Build Orchestration Supervision System) ''
:Is the workflow tool for releases. See [[Release Infrastructure/BOSS]]

== C ==
;''Compliance: ''
: is designed to make sure things stay compatible, such that the devices supporting a particular MeeGo version can run the same software. [[Quality/Compliance]]

== D ==

;''DE''
:Developer edition

;''DirectUI (DUI)''
:see MeeGo Touch Framework

;''Dual Boot''
:is a way of allowing meego devices to run multiple operating systems. See [[ARM/N900/Install/Dual Boot]]

== E ==
;''EMGD (Embedded Media and Graphics Driver) ''
: are Intel graphics drivers required for a number of netbook class devices http://edc.intel.com/Software/Downloads/EMGD/
: Currently not part of the standard netbook release images.

== F ==

;''FOSS: ''
:Free/Open Source Software

;''Fremantle: ''
:current Maemo 5 release *

== G ==
;''GMA500 (Graphics Media Accelerator 500) ''
: is the 3d graphics chip built into many Intel Atom based chipsets, related to the EMGD driver

== H ==
;''Handset''
: is one of the key components and deliverables of the Meego project http://meego.com/devices/handset/
;''Harmattan: ''
:future Maemo 6 (now MeeGo handheld) release by Nokia, to include bundled officially-supported Qt libraries, see MeeGo-Harmattan
;''Harmattan UI framework: ''
:see MeeGo Touch Framework
;''Harmattan UX''
:the user interface and applications of MeeGo-Harmattan.
;''HXT''
: MeeGo Handset Execution Team

== I ==

;''IRC (Internet Relay Chat) ''
:one of the key collaborative areas for Meego working and discussion

;''IIRC: ''
:If I Recall Correctly

;''IMG''
:Image creator

;''Intel''
: principle founding company (along with Nokia) of the Meego project
== K ==

;''Kernel (linux)''
: is the open source core of the operating system and without which we would not have Meego! See [[MeeGo kernel documentation for contributors]]

;''Kickstart files (.ks)''
: provide a list of packages and settings to use for automated installs. See [[Image Creation]]

== L ==

;''LSB (Linux Standard Base): ''
:The goal of the LSB is to develop and promote a set of open standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system even in binary form.

== M ==
;''MADDE''
:Maemo Application Development and Debugging Environment and offers the following features:
:* Command-line cross-compiling
:* Multi-platform support (Linux (32-bit/64-bit), Windows, Mac OS X)
:* Configurable for different targets & toolchains
:* Client for the device to simplify the development process
:It will used as part of future releases of the MeeGo SDK, along with QEMU, to enable cross-OS development.
;''Maemo''
:a software platform developed by Nokia for smartphones and Internet Tablets. It was initially based on the Debian Linux distribution. One of the predecessors of MeeGo, along with Moblin.
;''Maemo 5''
:the default operating system on the Nokia N900, and current latest stable and independent version of Maemo. Based on the GTK toolkit. Aliases: Fremantle
;''Maemo 6''
:see MeeGo-Harmattan
;''Maemo 6 UI framework''
:see MeeGo Touch framework
;''MeeGo''
:an open source, Linux project which brings together the Moblin project, headed up by Intel, and Maemo, by Nokia, into a single open source activity. Managed by the Linux Foundation. The important thing to note that you end users will mostly be using an edition of MeeGo, MeeGo itself is not a single product (that’s why "will X run/get MeeGo" is a bad question), just like people are using a Linux distributions, not Linux (as in kernel) alone.
;''MeeGo Compatible''
:something that implements the [http://meego.com/developers/meego-api MeeGo APIs], but is not necessarily based on MeeGo Core (for example Meego-Harmattan).
;''MeeGo Core 1.0''
:the base of every MeeGo system ([http://meego.com/sites/all/files/users/u13/MeeGoArch1.png diagram]), and described in detail [http://meego.com/developers/meego-architecture here]. It contains:
:* Kernel based on Linux 2.6.33
:* DeviceKit and udev for interacting with hardware devices
:* Modern 2D/3D graphics stack including Kernel Mode Setting, non-root X
:* Voice and data connectivity with Connman connection manager, Ofono telephony stack and BlueZ Bluetooth
:* Qt 4.6
:* Universal Plug and Play (gUPnP)
:* Media frameworks
:* Next generation file system BTRFS, as the default file system
:* Does NOT contain a user interface or end-user applications
;''MeeGo Garage''
:A client app installer in the MeeGo 1.0 Netbook release containing miscellaneous applications not part of the official MeeGo release and open for contributions from community. The name "Garage" may be changed in future releases. Ongoing community work is happening to create the official community repositories.
;''MeeGo Handheld''
:MeeGo Core + MeeGo Touch Framework + Reference Handheld UX (not yet released).
;''MeeGo Hardware adaptation project for the N900''
:Nokia as founding member of MeeGo project is using N900 as the ARM reference platform of MeeGo at the moment. This means that we have an active project that focuses to make a MeeGo hardware adaptation for the N900. The goal of the project is thus to open as much N900 specific drivers as possible in MeeGo scope.
;''MeeGo Hardware adaptation project for the N8x0''
:a 'skunkworks' project by the maemo.org community and others to bring MeeGo to Nokia N8x0, hence not a vendor-pushed hardware adaptation. Initially focus will be on Nokia N810. Some additional work to add support for ARMv6+VFP is also included in this.
;''MeeGo-Harmattan''
:the default operating system of the Nokia N9. Successor of Maemo 5, but based of the Qt toolkit. Originally named Maemo 6, but later rebranded as MeeGo-Harmattan (provisional name). It is MeeGo compatible (that is, has a MeeGo API) but is not to be confused with MeeGo 1.0 Handheld as it is NOT based on MeeGo Core. MeeGo-Harmattan will not be released as a Nokia product for the N900. Aliases: Harmattan, Maemo 6, MeeGo 1.0 N.
;''MeeGo Netbook''
:MeeGo Core + Reference Netbook UX
;''MeeGo SDK''
:A [[Getting started with the MeeGo SDK for Linux|software development kit for MeeGo]]
;''MeeGo Touch Framework (MTF)''
:provides the features needed for developers creating applications for touch-enabled devices. Features include standardized window navigation, list and other widget behavior, and common theming for components.
;''MeeGo Web RunTime''
:Web Runtime (WRT) allows web developers to use standard web languages — HTML, CSS, and JavaScript — to create applications for mobile devices. WRT exposes the features of the underlying platform so that applications can interact with device data and combine location-based context with web information.
;''MeeGo 1.0 N''
:A name which has appeared on [http://www.slideshare.net/NokiaAppForumBulgaria/software-development-with-qt some] [http://www.slideshare.net/elenakotina/qt-quick-qml Nokia] slides as a synonym for Harmattan. See MeeGo-Harmattan.
;''Moblin''
:short for 'mobile Linux', is an open source operating system and application stack for Mobile Internet Devices (MIDs), netbooks, nettops, and embedded devices. One of the predecessors of MeeGo, along with Maemo.
;''Moblin 2.1''
:last stable independent release of Moblin
;''Moblin 2.2''
:see Meego 1.0 Netbook

== N ==

;''Nokia''
: principle founding company (along with Intel) of the Meego project

;''Nokia Qt SDK''
:A custom version of the Qt SDK, which includes additional functionality for developing for Symbian/Maemo devices (with announced MeeGo support later on). These include tools for cross compiling (see MADDE) and simulation. Not to be confused with the Qt SDK as the two are not interchangeable due to a custom mix of features (neither is a a superset of the other)

;''N900''
: Nokia ARM powered handheld phone for open Meego development. See [[ARM/N900]]

;''Netbook''
: is one of the key components and deliverables of the Meego project http://meego.com/devices/netbook/

== O ==
;''OBS (OpenSuse Build System) : ''
:The Opensuse Build Service. is an open and complete distribution development platform that provides a transparent infrastructure for development. The service provides software developers with a convenient and easy to use tool to create and release open source software for openSUSE and other Linux distributions on different hardware architectures and for a broad user audience. See [[Build System]]

;''OCS (Open Collaboration Services) : ''
: a web API for browsing application catalogues, doing event and contact discovery [http://www.freedesktop.org/wiki/Specifications/open-collaboration-services OCS API]. Also, OBS command line client

;''Orbit''
:see UI Extensions for Mobile

;''OSSO (Open Source Software Operations): ''
:It was a department inside Nokia responsible for producing Maemo. It has been replaced by Maemo Software.

;''OTS (Open Test System): ''
:Suite of testing tools and configuration files for managing reproducible QA testing. See [[Quality/QA-tools/OTS|OTS Wiki]]

== P ==
;''PA (PulseAudio)''
: is the low level sound system component used by Meego. See [[Quality/TestSuite/PulseAudio Test Plan]]

== Q ==
;''QML''
:a Declarative UI tool, in effect a markup language that defines UI elements and their behavior in a declarative manner, allowing, snappy, whizzy UIs. Present in Qt4.7+

;''Qt''
:a cross-platform application and UI framework. Using Qt, you can write web-enabled applications once and deploy them across desktop, mobile and embedded operating systems without rewriting the source code.

;''Qt Quick''
:the Qt User Interface Creation Kit, which consists of QML, a specialized editor in QtCreator and all-around support for the declarative approach. Present in Qt4.7+. Aliases: Qt Declarative, Declarative UI, Bauhaus.

;''Qt SDK''
:The software development kit for the Qt framework

;''QtMobility''
:extends Qt with libraries providing additional features for applications targeting mobile platforms. These include the Service Framework and Contact and Bearer Management APIs, Messaging, Sensors, Camera, etc.

== R ==
;''Reference Netbook UX''
:a reference (example) implementation of a user interface for netbooks, utilizing Moblin’s Clutter-based MX toolkit. It is expected to be replaced or augmented with manufacturer provided user interfaces/system applications on actual devices.

;''Reference Handheld UX''
:a reference (example) implementation of a user interface for handheld devices, based on the MeeGo Touch framework. It is expected to be replaced or augmented with manufacturer provided user interfaces/system applications on actual devices.

;''REVS''
:Release Engineering Visibility System

== S ==

;''SR: ''
:Submit Request
:A submit request holds together all the changes relating to a specific fix.
:Bug reports commonly refer to them by SR #
:The Meego Commits mailing list documents the progression of each SR
:A Front end for SRs may be in place once the BOSS system becomes operational
:http://lists.meego.com/pipermail/meego-commits/

;''SSO: ''
:Single Sign On

;''SVC (Social Vendor Contract): ''
:A social contract for vendors to commit to, in order to have community spending time on them and not waste their time and end up with locked devices with a open system.

== T ==
;''TMO (talk.maemo.org): ''
:Main forum for Maemo non-technical community.

;''UC (Use Case): ''
: Nokianism for Use case description in documentation.

== U ==
;''Uiemo''
:see UI Extensions for Mobile

;''UI Extensions for Mobile''
:UI Extensions for Mobile is an extension library for Qt, which contains more than 50 UI elements tailored for mobile user experience. There is a proposal to use UI Extensions for Mobile and Qt together with Direct UI as a replacement for the existing S60 'Avkon' set of UI elements in Symbian^4, but has been demonstrated to work on Maemo, too. UI Extensions for Mobile was previously known as Orbit and has been open sourced. Aliases: Uiemo, Orbit

== Useful links ==
* [http://www.acronymfinder.com Acronym Finder]
* [http://wiki.maemo.org/Codenames Maemo Codenames]

Glossary

2011-04-27T13:47:27Z

Amigadave: move content from Lexicon

== A ==
;''Architecture: ''
:The Meego architecture describes the components for the whole system and is broken down into Layer, Domain and Api http://meego.com/developers/meego-architecture

;''ARM: ''
:The CPU powering the N900 and many other mobile devices. See [[ARM]]

;''ATM: ''
:At The Moment

== B ==

;''Beagle-board: ''
:Is an OMAP3 based development board suitable for embedded projects. See [[ARM/Meego on the Beagle]]

;''BME (Battery Management Entity): ''
:Is proxied to D-Bus via the bme-dbus-proxy daemon

;''BOSS: (Build Orchestration Supervision System) ''
:Is the workflow tool for releases. See [[Release Infrastructure/BOSS]]

== C ==
;''Compliance: ''
: is designed to make sure things stay compatible, such that the devices supporting a particular MeeGo version can run the same software. [[Quality/Compliance]]

== D ==

;''DE''
:Developer edition

;''DirectUI (DUI)''
:see MeeGo Touch Framework

;''Dual Boot''
:is a way of allowing meego devices to run multiple operating systems. See [[ARM/N900/Install/Dual Boot]]

== E ==
;''EMGD (Embedded Media and Graphics Driver) ''
: are Intel graphics drivers required for a number of netbook class devices http://edc.intel.com/Software/Downloads/EMGD/
: Currently not part of the standard netbook release images.

== F ==

;''FOSS: ''
:Free/Open Source Software

;''Fremantle: ''
:current Maemo 5 release *

== G ==
;''GMA500 (Graphics Media Accelerator 500) ''
: is the 3d graphics chip built into many Intel Atom based chipsets, related to the EMGD driver

== H ==
;''Handset''
: is one of the key components and deliverables of the Meego project http://meego.com/devices/handset/
;''Harmattan: ''
:future Maemo 6 (now MeeGo handheld) release by Nokia, to include bundled officially-supported Qt libraries, see MeeGo-Harmattan
;''Harmattan UI framework: ''
:see MeeGo Touch Framework
;''Harmattan UX''
:the user interface and applications of MeeGo-Harmattan.
;''HXT''
: MeeGo Handset Execution Team

== I ==

;''IRC (Internet Relay Chat) ''
:one of the key collaborative areas for Meego working and discussion

;''IIRC: ''
:If I Recall Correctly

;''IMG''
:Image creator

;''Intel''
: principle founding company (along with Nokia) of the Meego project
== K ==

;''Kernel (linux)''
: is the open source core of the operating system and without which we would not have Meego! See [[MeeGo kernel documentation for contributors]]

;''Kickstart files (.ks)''
: provide a list of packages and settings to use for automated installs. See [[Image Creation]]

== L ==

;''LSB (Linux Standard Base): ''
:The goal of the LSB is to develop and promote a set of open standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system even in binary form.

== M ==
;''MADDE''
:Maemo Application Development and Debugging Environment and offers the following features:
:* Command-line cross-compiling
:* Multi-platform support (Linux (32-bit/64-bit), Windows, Mac OS X)
:* Configurable for different targets & toolchains
:* Client for the device to simplify the development process
:It will used as part of future releases of the MeeGo SDK, along with QEMU, to enable cross-OS development.
;''Maemo''
:a software platform developed by Nokia for smartphones and Internet Tablets. It was initially based on the Debian Linux distribution. One of the predecessors of MeeGo, along with Moblin.
;''Maemo 5''
:the default operating system on the Nokia N900, and current latest stable and independent version of Maemo. Based on the GTK toolkit. Aliases: Fremantle
;''Maemo 6''
:see MeeGo-Harmattan
;''Maemo 6 UI framework''
:see MeeGo Touch framework
;''MeeGo''
:an open source, Linux project which brings together the Moblin project, headed up by Intel, and Maemo, by Nokia, into a single open source activity. Managed by the Linux Foundation. The important thing to note that you end users will mostly be using an edition of MeeGo, MeeGo itself is not a single product (that’s why "will X run/get MeeGo" is a bad question), just like people are using a Linux distributions, not Linux (as in kernel) alone.
;''MeeGo Compatible''
:something that implements the [http://meego.com/developers/meego-api MeeGo APIs], but is not necessarily based on MeeGo Core (for example Meego-Harmattan).
;''MeeGo Core 1.0''
:the base of every MeeGo system ([http://meego.com/sites/all/files/users/u13/MeeGoArch1.png diagram]), and described in detail [http://meego.com/developers/meego-architecture here]. It contains:
:* Kernel based on Linux 2.6.33
:* DeviceKit and udev for interacting with hardware devices
:* Modern 2D/3D graphics stack including Kernel Mode Setting, non-root X
:* Voice and data connectivity with Connman connection manager, Ofono telephony stack and BlueZ Bluetooth
:* Qt 4.6
:* Universal Plug and Play (gUPnP)
:* Media frameworks
:* Next generation file system BTRFS, as the default file system
:* Does NOT contain a user interface or end-user applications
;''MeeGo Garage''
:A client app installer in the MeeGo 1.0 Netbook release containing miscellaneous applications not part of the official MeeGo release and open for contributions from community. The name "Garage" may be changed in future releases. Ongoing community work is happening to create the official community repositories.
;''MeeGo Handheld''
:MeeGo Core + MeeGo Touch Framework + Reference Handheld UX (not yet released).
;''MeeGo Hardware adaptation project for the N900''
:Nokia as founding member of MeeGo project is using N900 as the ARM reference platform of MeeGo at the moment. This means that we have an active project that focuses to make a MeeGo hardware adaptation for the N900. The goal of the project is thus to open as much N900 specific drivers as possible in MeeGo scope.
;''MeeGo Hardware adaptation project for the N8x0''
:a 'skunkworks' project by the maemo.org community and others to bring MeeGo to Nokia N8x0, hence not a vendor-pushed hardware adaptation. Initially focus will be on Nokia N810. Some additional work to add support for ARMv6+VFP is also included in this.
;''MeeGo-Harmattan''
:the default operating system of the Nokia N9. Successor of Maemo 5, but based of the Qt toolkit. Originally named Maemo 6, but later rebranded as MeeGo-Harmattan (provisional name). It is MeeGo compatible (that is, has a MeeGo API) but is not to be confused with MeeGo 1.0 Handheld as it is NOT based on MeeGo Core. MeeGo-Harmattan will not be released as a Nokia product for the N900. Aliases: Harmattan, Maemo 6, MeeGo 1.0 N.
;''MeeGo Netbook''
:MeeGo Core + Reference Netbook UX
;''MeeGo SDK''
:A [[Getting started with the MeeGo SDK for Linux|software development kit for MeeGo]]
;''MeeGo Touch Framework (MTF)''
:provides the features needed for developers creating applications for touch-enabled devices. Features include standardized window navigation, list and other widget behavior, and common theming for components.
;''MeeGo Web RunTime''
:Web Runtime (WRT) allows web developers to use standard web languages — HTML, CSS, and JavaScript — to create applications for mobile devices. WRT exposes the features of the underlying platform so that applications can interact with device data and combine location-based context with web information.
;''MeeGo 1.0 N''
:A name which has appeared on [http://www.slideshare.net/NokiaAppForumBulgaria/software-development-with-qt some] [http://www.slideshare.net/elenakotina/qt-quick-qml Nokia] slides as a synonym for Harmattan. See MeeGo-Harmattan.
;''Moblin''
:short for 'mobile Linux', is an open source operating system and application stack for Mobile Internet Devices (MIDs), netbooks, nettops, and embedded devices. One of the predecessors of MeeGo, along with Maemo.
;''Moblin 2.1''
:last stable independent release of Moblin
;''Moblin 2.2''
:see Meego 1.0 Netbook

== N ==

;''Nokia''
: principle founding company (along with Intel) of the Meego project

;''Nokia Qt SDK''
:A custom version of the Qt SDK, which includes additional functionality for developing for Symbian/Maemo devices (with announced MeeGo support later on). These include tools for cross compiling (see MADDE) and simulation. Not to be confused with the Qt SDK as the two are not interchangeable due to a custom mix of features (neither is a a superset of the other)

;''N900''
: Nokia ARM powered handheld phone for open Meego development. See [[ARM/N900]]

;''Netbook''
: is one of the key components and deliverables of the Meego project http://meego.com/devices/netbook/

== O ==
;''OBS (OpenSuse Build System) : ''
:The Opensuse Build Service. is an open and complete distribution development platform that provides a transparent infrastructure for development. The service provides software developers with a convenient and easy to use tool to create and release open source software for openSUSE and other Linux distributions on different hardware architectures and for a broad user audience. See [[Build System]]

;''OCS (Open Collaboration Services) : ''
: a web API for browsing application catalogues, doing event and contact discovery [http://www.freedesktop.org/wiki/Specifications/open-collaboration-services OCS API]. Also, OBS command line client

;''Orbit''
:see UI Extensions for Mobile

;''OSSO (Open Source Software Operations): ''
:It was a department inside Nokia responsible for producing Maemo. It has been replaced by Maemo Software.

;''OTS (Open Test System): ''
:Suite of testing tools and configuration files for managing reproducible QA testing. See [[Quality/QA-tools/OTS|OTS Wiki]]

== P ==
;''PA (PulseAudio)''
: is the low level sound system component used by Meego. See [[Quality/TestSuite/PulseAudio Test Plan]]

== Q ==
;''QML''
:a Declarative UI tool, in effect a markup language that defines UI elements and their behavior in a declarative manner, allowing, snappy, whizzy UIs. Present in Qt4.7+

;''Qt''
:a cross-platform application and UI framework. Using Qt, you can write web-enabled applications once and deploy them across desktop, mobile and embedded operating systems without rewriting the source code.

;''Qt Quick''
:the Qt User Interface Creation Kit, which consists of QML, a specialized editor in QtCreator and all-around support for the declarative approach. Present in Qt4.7+. Aliases: Qt Declarative, Declarative UI, Bauhaus.

;''Qt SDK''
:The software development kit for the Qt framework

;''QtMobility''
:extends Qt with libraries providing additional features for applications targeting mobile platforms. These include the Service Framework and Contact and Bearer Management APIs, Messaging, Sensors, Camera, etc.

== R ==
;''Reference Netbook UX''
:a reference (example) implementation of a user interface for netbooks, utilizing Moblin’s Clutter-based MX toolkit. It is expected to be replaced or augmented with manufacturer provided user interfaces/system applications on actual devices.

;''Reference Handheld UX''
:a reference (example) implementation of a user interface for handheld devices, based on the MeeGo Touch framework. It is expected to be replaced or augmented with manufacturer provided user interfaces/system applications on actual devices.

;''REVS''
:Release Engineering Visibility System

== S ==

;''SR: ''
:Submit Request
:A submit request holds together all the changes relating to a specific fix.
:Bug reports commonly refer to them by SR #
:The Meego Commits mailing list documents the progression of each SR
:A Front end for SRs may be in place once the BOSS system becomes operational
:http://lists.meego.com/pipermail/meego-commits/

;''SSO: ''
:Single Sign On

;''SVC (Social Vendor Contract): ''
:A social contract for vendors to commit to, in order to have community spending time on them and not waste their time and end up with locked devices with a open system.

== T ==
;''TMO (talk.maemo.org): ''
:Main forum for Maemo non-technical community.

;''UC (Use Case): ''
: Nokianism for Use case description in documentation.

== U ==
;''Uiemo''
:see UI Extensions for Mobile

;''UI Extensions for Mobile''
:UI Extensions for Mobile is an extension library for Qt, which contains more than 50 UI elements tailored for mobile user experience. There is a proposal to use UI Extensions for Mobile and Qt together with Direct UI as a replacement for the existing S60 'Avkon' set of UI elements in Symbian^4, but has been demonstrated to work on Maemo, too. UI Extensions for Mobile was previously known as Orbit and has been open sourced. Aliases: Uiemo, Orbit

== Useful links ==
* [http://www.acronymfinder.com Acronym Finder]
* [http://wiki.maemo.org/Codenames Maemo Codenames]

Quality/MeeGo1.2HandSetUXTestPlanforMozillaFennecBrowser

2011-04-27T13:41:17Z

Amigadave: categorise, wikify section headings and table formatting

== Component Summary ==
This test plan is for MeeGo 1.2 HandSet UX Mozilla Fennec Browser. Firefox Mobile is the Browser built for the way you use the web on your mobile device.

== Features To Be Tested ==
All testable features coming to MeeGo 1.2 HandSet UX Mozilla Fennec Browser will be covered in this test plan.

* Mozilla Fennec browser 1.2 Features that will be verified are listed below (up-to-date list can be found from FeatureZilla [http://bugs.meego.com/buglist.cgi?action=wrap&bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&classification=MeeGo%20Features&deadlinefrom=&deadlineto=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field0-0-0=noop&longdesc=&longdesc_type=allwordssubstr&product=MeeGo%20Handset%20Features&short_desc=&short_desc_type=allwordssubstr&type0-0-0=noop&value0-0-0=&version=1.2&votes=&=&component=Web%20browser here]):

{| class="wikitable"
|+ Fennec browser features to be tested
|-
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3103 3103] - [FEA] Browser remember web passwords
| Browser should provide support to remember web site passwords and pre-fill those to the web page once re-visited.
| Moved from release 1.1
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3128 3128] - [FEA] Browser web page orientation
| Browser should support of rendering the content optimised both on landscape and portrait modes depending on the orientation of the device (if device orientation supported by the device).
| Moved from release 1.1
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4104 4104] - [FEA] Browser - File download in progress indicator
| The device SHALL provide continuous progress feedback during file download so the user knows the download is still in progress. Remaining time or % in progress SHALL be indicated.
| Moved from release 1.1
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4127 4127] - [FEA] Browser - Videos and CSS Layering
| The browser SHALL support the display of HTML elements on top of an embedded video object using standard CSS layering (position and z-index properties).
| Moved from release 1.1
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4130 4130] - [FEA] Browser - Deletion of cookies
| The user SHALL be able to delete his cookies
| Moved from release 1.1
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=9263 9263] - [FEA] [I18N]The Web browser shall be internationalized according to the dependencies listed in Core Master 5068.
| This includes such items as:
* Unicode support
* All translatable strings are externalized
* UI adaptability to longer and shorter strings than English
* Ability to accept, display, sort, search, copy, paste, and print accented and double-byte characters
* No concatenation of translatable strings
* Support for the POR languages: en_US, en_GB, fr, de, es, it, fi, sv, pl, ru, nl, pt_BR, ja, ko, zh_TW, zh_CN
| Feature can be tested based on description but extended testing should be done during localization / internationalization testing.
|}

* Also MeeGo 1.1 release browser features ([http://bugs.meego.com/buglist.cgi?action=wrap&bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&classification=MeeGo%20Features&deadlinefrom=&deadlineto=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field0-0-0=noop&longdesc=&longdesc_type=allwordssubstr&product=MeeGo%20Handset%20Features&short_desc=&short_desc_type=allwordssubstr&type0-0-0=noop&value0-0-0=&version=1.1&votes=&=&component=Web%20browser link] to featurezilla) are included in testing

== Features Not To Be Tested ==
Mozilla Fennec features that are not fully tested because of lacking testability (up-to-date list can be found from FeatureZilla [http://bugs.meego.com/buglist.cgi?action=wrap&bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&classification=MeeGo%20Features&deadlinefrom=&deadlineto=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field0-0-0=noop&longdesc=&longdesc_type=allwordssubstr&product=MeeGo%20Handset%20Features&short_desc=&short_desc_type=allwordssubstr&type0-0-0=noop&value0-0-0=&version=1.1&version=1.2&votes=&=&component=Web%20browser&cf_testability=No here])
{| class="wikitable"
|+ Fennec browser features that are not to be tested
|-
! Feature Name
! Description
! Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4128 4128] - [FEA] Browser - Access Architecture
| It SHALL be possible to access XHTML+CSS content with the following access architectures:
* Standard Internet architecture (HTTP over TCP/IP)
* Standard internet architecture with an explicit HTTP proxy
| Feature will be partially tested. More detailed description needed for full verification
|}

== Strategy and Approach ==
Mozilla Fennec Browser is tested in different test sets. Test sets containing Mozilla Fennec Browser (MFB) related test cases are:
* Sanity Test Set
** Contains few basic MFB test cases that MFB application is part of SW image, can be opened and basic browsing can be made
* Key Feature Test Set
** Consists of key features defined by product management. In the begin release 1.1 key features will be used for the test set but after product management defines key features for 1.2 they will be updated to test set. Test set will be run to Preview and Weekly images
* Feature Basic Acceptance Set (BAT)
** 10-30 important browser test cases selected from Basic Feature Test Set. Will be run weekly
* Basic Feature Test Set
** Contains basic feature UI (Functional) test cases for every testable MFB feature. Will be run once for every major milestone
* Extended Feature Test Set
** Contains bunch of well selected MFB test cases to verify that delivered features (Functional) forming component are working. Will be run once during Feature Development Phase (MM2-MM3) and once in Stabilization Phase (MM3-MM4)

[[Quality/TestSetGuideline|Test Set Guideline]]

Note! Nokia Browser team will also perform extensive UI application test set for MFB to ensure that all relevant MFB related bugs are detected and reported.

== Hardware Platforms ==
* All [http://meego.com/devices/handset/handset-supported-hardware official supported HW's]

== QA Contact ==
* [mailto:anssi.takku@nokia.com Anssi Takku]

[[Category:QA]]
[[Category:Meego-1.2]]

Quality/MeeGo1.2 Handset UX Social Networking TestPlan

2011-04-27T13:10:52Z

Amigadave: categorise, wikify table formatting and links

==History ==

{| class="wikitable"
! Date
! Modification
|-
|12/03/2010
|Creation of this wiki
|-
| 
| 
|}

==Component Summary==
This test plan is for MeeGo 1.2 HandSet Social networking application. 
'''Social Networking''' is an application integrates with some popular social networking web services for the MeeGo system, to allows the user to fetch web services by setting up corresponding user accounts.

==Feature to be Tested==

{| class="wikitable"
! Feature Name
! Detailed Feature Description
! Comments
|-
| Social Networking
||
* Social networking main window UI, layout and button response check
* Launch/close social networking application
* Set up social networking accounts (last.fm and twitter)
* last.fm context menu (View on Last.fm, Remove from timeline)
* Status update and Refresh
* Settings for last.fm and twitter.com
* Individual update for last.fm and twitter.com
* Post new twitter status
* Twitter context menu (Reply, Retweet, View on twitter.com, Remove from timeline)
||
* No detailed social networking feature request in featurezilla.
* Twitter web service is blocked in China.
|}

==Feature not to be Tested==
{| class="wikitable"
!|Feature Name
!|Feature Description
!|Comments
|-
|
|
|
|-
|}
* Translation for other languages except Chinese Simplified will not be covered in Handset UX Social Networking Test Plan.

==Test Strategy and Approach==
'''''Test Strategy'''''
* '''Usage Model test''': check social networking web services functionalities and interactive with home screen work correctly by touch gestures from user perspective.
* '''Test from UI''': to ensure all GUI functionality for social networking are correct and visual effect are consistent.

'''''Based on the test strategy, following areas will be tested with high priority:'''''
* UI experience and functionality test, interaction with touch screen, common UI operation etc. It also includes i18n/l10n test.
* Functionality verification, collaboration with home screen，web browser　and with related devices.

'''''We will also cover the following functionality test:'''''
* Relative UI changes in social networking application etc.
* Stress and Negative testing to ensure the stability and robust of the social networking.

==Test Design==
Test Design is based on [[Quality/HandsetDeviceUsageModel|Handset Test Design usage Model]]. According to the usage modal, characteristics and application features, the check points and priority of each features were defined. Test design tables are drafted below, and which will become the base to design test cases.

{| class="wikitable"
! Feature Category
! Feature ID-description
! Test Points
! Collaboration
! Conditions
|-
|Social Networking
|
|
* Check Social networking UI, layout (Portrait and Landscape), theme and button response.
* Check if social networking application could be launched and closed in full screen mode and live thumbnail mode
* Check if social networking integrates following web services (Last.fm, twitter) by directly clicking the web service icon.
* Check if social networking accounts (Last.fm, twitter) can be configured and login
* Check if viewing social network postings/feeds ( see your friends' Twitter updates or Last.fm updates) for all libsocialweb-supported social networks.
* Check if social network status/broadcast timely updated (i.e. post a Twitter update, post a Last.fm update) for all libsocialweb-supported social networks.
* Check if last.fm context menu (View on Last.fm, Remove from timeline) works
* Check if Twitter context menu (Reply, Retweet, View on twitter.com, Remove from timeline) work
* Check if settings for last.fm and twitter.com work
* Check if support individual update view for last.fm and twitter.com
|
* Home Screen
* Web browser
* Settings
* VKB/HWKB
|
* Orientation (landscape and portrait view)
* Gesture: tap, swipe, tap and hold (long press), drag

|-
|I18n and L10n
| 
|Check text internationalization & Chinese language localization support on social networking application, which covers:
* Application name and icon
* Button label and its icon
* Window title
* Text message
* Date, time format
| 
| 
|}

==Risk and Dependency==
* No detailed social networking feature request in featurezilla.
* Following social networking services are not unavailable in PRC: twitter, facebook, bebo, vimeo etc.

==Test Environment==
===Hardware Platforms===
* nCDK
* iCDK

===Tools===
* bluetooth devices, wlan devices, network simulators, wireless AP

==QA Contact==
* [mailto:cathy.li@intel.com Cathy Li]

==Developers==
* [mailto:james.ausmus@intel.com James Ausmus]

==Reference==
* [[Quality/HandsetDeviceUsageModel|Handset Test Design Usage Model]]

[[Category:QA]]
[[Category:Meego-1.2]]

Quality/MeeGo1.2HandSetUXTestPlanforUIinfrastructure

2011-04-27T13:00:23Z

Amigadave: categorise, wikify section headings and table formatting

== Component Summary ==
This test plan is for MeeGo 1.2 HandSet UX Short Message Service (SMS). SMS depends on ofono (for telephony services), SMS history (ofono SMS history plugin) and libseaside (for contacts data).

== Feature To Be Tested ==
All testable features coming to MeeGo 1.2 HandSet UX SMS features will be covered in this test plan. This testplan contains also legacy features from Meego 1.1 release that are coming to 1.2 release. Note! Also SMS setting features are covered in this test plan.

* are summarized as below:

{| class="wikitable"
|+ SMS Features to be tested
|-
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2655 2655] - [FEA] SMS application message handling functionality || SMS should support following message handling functionality
-Open message
-Forward message
-Reply to message
-Extract phone number from SMS header and text
-Call back to SMS sender
-Extract URL from SMS text body
-Send Multi-page messages
-Automatic storage of last edited message in drafts
-Sending to multiple recipients by selecting recipients from address book &
multiple phone numbers entries
-Display number of characters in the SMS while it is being composed.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2629 2629] - [FEA] Short Message Service (SMS) application || A short message service application (SMS) is required to send and receive
cellular short text messages.

SMS should support numeric key entry to enter a recipient phone number and
integration to a Contacts application to select a recipient.

SMS should support message history of sent and received message.

SMS should support message notifications of success of the message delivery to
the recipient.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3019 3019] - [FEA] SMS sending to multiple recipients || SMS should support of sending to multiple recipients by selecting recipients
from address book & multiple phone numbers entries. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4159 4159] - [FEA] SMS - SMS Message Indication || The device shall support SMS Message indication to match an existing contact.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3015 3015] - [FEA] SMS pick phone number from message || SMS should support to extract a phone number from SMS header and text to
provide a quick way to call back to the sender or other indicated number.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3022 3022] - [FEA] SMS delivery notifications ||SMS should support message notifications of success of the message delivery to
the recipient.
|| xxx
|-
| Feature http://bugs.meego.com/show_bug.cgi?id=3020 3020] - [FEA] SMS composing a message || SMS should support composing a message with characters supported by the current
cellular network and the language localisation of the device.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2656 2656] - [FEA] SMS Cell Broadcast ||SMS should support broadcast messages (advertising, public information, etc.)
as specified for Cell Broadcast service (SMS-CB) in 3GPP GSM 03.41
specification.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3016 3016] - [FEA] SMS pick URL from message ||SMS should support to extract an URL from SMS text body and provide actions to
utilise the URL in other applications, e.g. to launch the Browser.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3013 3013] - [FEA] SMS message forward || SMS should support forwarding a message.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3014 3014] - [FEA] SMS message reply ||SMS should support replying to a received message.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4154 4154] - [FEA] SMS - Recieve an SMS ||The system shall be able to receive a newly delivered SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4155 4155] - [FEA] SMS - Send an SMS || The user shall be able to send an SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4158 4158] - [FEA] SMS - Save an SMS || The user shall be able to save an SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3021 3021] - [FEA] SMS display number of characters once composing || SMS should support of displaying number of characters inputted and left to fit
to a single message while it is being composed.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3023 3023] - [FEA] SMS message history || SMS should support message history of sent and received message.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4153 4153] - [FEA] SMS - Create an SMS || The user shall be able to create a message for SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4157 4157] - [FEA] SMS - View an SMS || The user shall be able to view an SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4156 4156] - [FEA] SMS - Delete an SMS || The User shall be able to delete an SMS message.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3017 3017] - [FEA] SMS multi-page messages || SMS should support to send messages that exceed the number of characters
supported by the current cellular network in a single message (e.g. GSM 160
characters) by providing the means to send such a message splitted to multiple
messages (multi-page messages).
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3018 3018] - [FEA] SMS autostore message in creation || SMS should support storing last edited message automatically as a draft in a
provided folder.
|| xxx
|-
| xxx || xxx || xxx
|-
|}

== Feature Not To Be Tested ==
List of Not testable features can be found using this query: [http://bugs.meego.com/buglist.cgi?action=wrap&bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&classification=MeeGo%20Features&deadlinefrom=&deadlineto=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field0-0-0=noop&longdesc=&longdesc_type=allwordssubstr&product=MeeGo%20Handset%20Features&short_desc=&short_desc_type=allwordssubstr&type0-0-0=noop&value0-0-0=&version=1.1&version=1.2&votes=&=&component=SMS&cf_testability=No Not testable features]

== Strategy and Approach ==
SMS is tested in different test sets. Test sets containing SMS related test cases are
* Sanity Test Set
** Contains few basic SMS test cases that SMS application is part of SW image, can be opened and basic SMS sending/receiving can be made
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable SMS feature
* Extended Feature Test Set
** Contains bunch of well selected SMS test cases to verify that delivered features (Functional) forming component are working
* System Functional Test Set
** Contains interaction and negative test cases were SMS is used together with other components that are part of system
* System Performance Test Set
** Contains only Response Time part

[[Quality/TestSetGuideline|Test Set Guideline]]

== Handset UX QA Testing Frequency ==

There are articles on [[Quality/TestSetGuideline|Overall test sets and definitions]] and [[Release_Engineering/Milestones|official milestones and definitons]].

Next picture illustrates test execution frequency for Handset UX QA team and is aligned with MM milestones. Please, click on picture and select full resolution.

[[File:MeeGoReleaseTimeline_Test_Execution.JPG|600px]]

== Hardware Platforms ==

Supported hardware info: http://meego.com/devices/handset/handset-supported-hardware

== QA Contact ==

* [mailto:mika.m.ikonen@nokia.com Mika Ikonen]

[[Category:QA]]
[[Category:Meego-1.2]]

Quality/MeeGo1.2HandSetUXTestPlanforInstantMessaging

2011-04-27T12:49:30Z

Amigadave: wikify section headings, categorise, wikify table formatting

== Component Summary ==
This test plan is for MeeGo 1.2 HandSet UX Instant Messaging. IM depends on ofono (for telephony services), IM history (ofono IM history plugin) and libseaside (for contacts data).

== Feature To Be Tested ==
All testable features coming to MeeGo 1.2 HandSet UX Instant Messaging will be covered in this test plan.

{| class="wikitable"
|+ IM Features to be tested
|-
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3068 3068] - [FEA] Instant Messaging (IM) application || An instant messaging application should be provided to exchange instant
messages with other users using common Internet IM services, such as Gtalk.
||
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=6380 6380] - [FEA] Support IRC as a protocol ||The meego IM app should be able to be used to communicate with the MeeGo
community, which uses IRC to communicate.
||
|-
|}

== Feature Not To Be Tested ==
List of features that are not tested as part of MeeGo 1.2 HandSet UX are:

Features: http://bugs.meego.com/show_bug.cgi?id=3067 and http://bugs.meego.com/show_bug.cgi?id=8508 are on Waiting state so currently those features are NOT tested.

== Strategy and Approach ==
IM is tested in different test sets. Test sets containing IM related test cases are
* Sanity Test Set
** Contains basic IM test cases that IM application is part of SW image, can be opened and basic IM usage is possible
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable IM feature
* Extended Feature Test Set
** Contains bunch of well selected IM test cases to verify that delivered features (Functional) forming component are working
* System Functional Test Set
** Contains interaction and negative test cases were IM is used together with other components that are part of system
* System Performance Test Set
** Contains only Response Time part

[[Quality/TestSetGuideline]]

== Handset UX QA Testing Frequency ==

There are articles on [[Quality/TestSetGuideline|Overall test sets and definitions]] and [[Release_Engineering/Milestones|official milestones and definitons]]

Next picture illustrates test execution frequency for Handset UX QA team and is aligned with MM milestones. Please, click on picture and select full resolution.

[[File:MeeGoReleaseTimeline_Test_Execution.JPG|600px]]

== Hardware Platforms ==
Supported hardware info: http://meego.com/devices/handset/handset-supported-hardware

== QA Contact ==
* [mailto:mika.m.ikonen@nokia.com Mika Ikonen]

[[Category:QA]]
[[Category:Meego-1.2]]

Quality/MeeGo1.2HandSetUXTestPlanforDialer

2011-04-27T12:03:37Z

Amigadave: categorise, wikify section headings and table formatting

== Component Summary ==
This test plan is for MeeGo 1.2 HandSet UX Dialer application. Dialer is a simple Voice Call Dialer/Manager. It depends on ofono (for telephony services), call history (ofono call history plign) and libseaside (for contacts data).

== Feature To Be Tested ==
All testable features coming to MeeGo 1.2 HandSet UX Dialer will be covered in this test plan. This test plan also covers legacy features from Meego 1.1 release. Note! Also telephony settings features are covered in this test plan.

{| class="wikitable"
|+ Dialer features to be tested
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2630 2630] - [FEA] Dialer application || A phone dialing application (Dialer) is required to make and receive voice
calls.

Dialer should support integrated dialpad and integration to a Contacts
application.

Dialer should support call history with dialed, received and missed calls.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2657 2657] - [FEA] Dialer application extended call handling functionality || Dialer should support the following features
* User Determined User Busy
* Call hold/retrieve
* Call waiting
* Multiple calls
* Explicit Call Transfer (ECT)
* Call Completion to Busy Subscriber (CCBS)
* USSD Service
* Multiparty call
* Private conversation during multi-party call
* Split multiparty call
* Mute call
* Auto redial
* Send DTMF tones
* Volume up/down
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2658 2658] - [FEA] Dialer application call statistics || Dialer application should support call statistics of
* Duration of call
* Cost of call
* Remaining ACM balance (TBD)
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4143 4143] - [FEA] Dialer - Call from Call History || The system shall allow the user to initiate a call from a phone number in the
call history.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5435 5435] - [FEA] Ringing tone assignment with a contact || The device should support a ringing tone to be assigned to a specific contact.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2660 2660] - [FEA] Dialer application Call Line Identification || Dialer should support Call Line Identification (CLIP+CLIR) GSM Supplementary
Service.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2795 2795] - [FEA] Dialer application Call hold and retrieve || Dialer should support to put the call on hold and retrieve it back from hold.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2796 2796] - [FEA] Dialer application Call waiting || Dialer should support Call waiting functionality
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2797 2797] - [FEA] Dialer application support for Multiple calls || Dialer should support handling Multiple calls at the same time. Minimum 2 calls
at the same time should be supported (one on hold, one on line).
|| xxx
|-
| 1.2 Feature [http://bugs.meego.com/show_bug.cgi?id=2809 2809] - [FEA] Dialer application mute incoming call ringtone || Dialer application should support to be able to mute incoming call ringing
tone.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2811 2811] - [FEA] Dialer application DTMF support || Dialer should support sending Dual-Tone Multi-Frequency (DTMF) tones to the
network in order to interact with provided network services, such as service
numbers and conference centers.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4133 4133] - [FEA]Dialer - One Click Viewing || The system shall provide one click viewing access while in a call to the
following functions: mute, contacts, call history, loud speaker, hold, and home
screen.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4134 4134] - [FEA] Dialer - Dialer - Make a Call || The user shall be able to make a call.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4135 4135] - [FEA] Dialer - Receive Call || The system shall be able to receive calls from a connected device.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4136 4136] - [FEA] Dialer - End Call || The system shall be able to end an active call by selecting end or by pressing
the hangup button
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4137 4137] - [FEA] Dialer - Voice Mail indicator || The system shall notify the user that there is a Voice Mail waiting
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4138 4138] - [FEA] Dialer - Display Name or Number || The system presents a call screen that shows the Name or number, if the number
matches a contact address book entry, the name is shown, otherwise the number.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4139 4139] - [FEA] Dialer - Display Contact's Photo || The system presents a call screen that shall display the contact's photo if it
matches an address book entry.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4140 4140] - [FEA] Dialer - Display Call Duration || The system shall display the duration while in a call
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4149 4149] - [FEA] Dialer - Sinlge key voicemail access || Dial to voicemail with a single key press.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4150 4150] - [FEA] Dialer - Call selected Service Number || Makes voice call to selected service number
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4152 4152] - [FEA] Dialer - Phonebook access || The terminal shall allow the user to browse the local phonebook while being in
a call.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2659 2659] - [FEA] Dialer application voice mail support || Dialer should support voice mail services
* Dial voice mailbox number stored in the SIM phonebook
* An indication for Voice Message Waiting (CPHS only)
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4142 4142] - [FEA] Dialer - View Call History || The system shall be able to display the history of placed (outgoing and
rejected) and received (missed and answered) calls. Should list date of call,
time of call, duration of call, type of call ( placed or received) and total
number of calls
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2794 2794] - [FEA] Dialer application User Determined User Busy || Dialer should support User Determined User Busy functionality.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2803 2803] - [FEA] Dialer application Explicit Call Transfer (ECT) || Dialer should support Explicit Call Transfer (ECT) to allows a user who has two
calls to connect these two calls together and release its connections to both
other parties.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2804 2804] - [FEA] Dialer application Call Completion to Busy Subscriber (CCBS) || Dialer should support Call Completion to Busy Subscriber (CCBS) GSM service to
automatically redial repeatedly to busy destination number to have the call
completed when the busy destination becomes idle, without having to make a new
call attempt.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2806 2806] - [FEA] Dialer application Multiparty call || Dialer should support multiparty calling to establish a multiparty call with
minimun three parties.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2807 2807] - [FEA] Dialer application private conversation during Multiparty call || Dialer should support of switching to a private conversation with any of the
call parties during multiparty call.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2808 2808] - [FEA] Dialer application split Multiparty call || Dialer application should support of splitting a multiparty call to independent
calls.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2810 2810] - [FEA] Dialer call volume handling during a call || Dialer application should support of adjusting the call volume up and down and muting the microphone during call establishment and during a call.
The application should remember the set volume level for the next call, except
if muted.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4141 4141] - [FEA] Dialer - Auto Redial || The system shall be able to auto redial a recently placed call.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4144 4144] - [FEA] Dialer - Add Speed Dial || The system shall allow the user to assign a speed dial number to a given phone
number or contact address book
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4145 4145] - [FEA] Dialer - Remove Speed Dial || The system shall allow the user to delete a speed dial number assigned to a
given number or contact
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4146 4146] - [FEA] Dialer - View Speed Dial || The system shall allow the user to view the assigned speed dial numbers
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4147 4147] - [FEA] Dialer - User Speed Dial || Press and hold a numeric key pad number will dial the associated number (except
for o and 1)
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4148 4148] - [FEA] Dialer - Predictive Contact completion || The system shall allow the user the ability to place a call by pressing a
reduced number of keys
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4151 4151] - [FEA] Dialer - Easily save last called number / missed calls / received calls || The terminal shall offer the possibility to save the last called/missed
call/received call phone number. This applies to create a new contact and to
modify an existing one
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8145 8145] - [FEA] Multi-party calls || The system shall be able to place a call to multiple recipients. The user may
identify the recipients by either manually entering the phone numbers or
leveraging off the user's contact address book
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8146 8146] - [FEA] Multiple Call Management || Terminal should support the following functions at least among Multiple Call
specified to 3GPP.
<Start>
<Display>
<Disconect>
<Select>
<Hold>
<Retrieve>
<Split>
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8147 8147] - [FEA] Joining multi-party call lines || The system shall allow the joining of calls to form a multi-party call from
active call(s) and call(s) on hold. The user is also able to split from a
multi-party call
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8148 8148] - [FEA] Emergency Calls without dedicated number || The system shall allow an emergency call w/o a dedicated number . The User
Interface shall provide a specific way to make an emergency call without having
to dial the number
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8165 8165] - [FEA] Multiple Call Management: Display current status || Terminal shall display current status (on line, holding) for each line.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8166 8166] - [FEA] Multiple Call Management: Disconnect each call || Terminal shall be possible to disconnect each call of multi party call.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8168 8168] - [FEA] Multiple Call Management: Disconnect all || Terminal shall be possible to disconnect entire multi party conversation call
at one time.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8169 8169] - [FEA] Multiple Call Management: Disconnect all once one on hold || Terminal shall be possible to disconnect all calls at one time in the situation
that one call is activated and another is held.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8170 8170] - [FEA] Multiple Call Management: Disconnect all once all on hold || Terminal shall be possible to disconnect a call of multi party call during
holding all lines
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8172 8172] - [FEA] Multiple Call Management: Start || Terminal shall provide user with the menu which can choose another call from
option menu.
User can also select number from call log and contacts.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8173 8173] - [FEA] Multiple Call Management: Hold || Terminal shall be possible to hold entire multi party conversation at one time.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8176 8176] - [FEA] Fixed Dialing Number limited numbers || The handset SHALL prevent any call attempts by the user to numbers that do not
exist in the Fixed Dialling List.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8177 8177] - [FEA] Fixed Dialing Number Emergency dialing || Regardless of the state of Restricted Dialing, Emergency calls SHALL be
allowed.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8142 8142] - [FEA] Display Cost of Call || The system shall display the call cost while in a call
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8143 8143] - [FEA] Display Remaining Call Balance || The system SHALL display the users remaing pre-paid minute balance while in a
call
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8144 8144] - [FEA] Call Forwarding || The system shall be able to redirect incoming calls to a different telephone
number. The forwarded line should ring once, to remind the user that Call
forwarding is on.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8149 8149] - [FEA] Fixed Dialing Numbers limited from SIM || When a SIM card s inserted which has restricted Dialing 'enabled', the device
SHALL reject the SIM and display a suitable error message. The device SHALL be
disabled, except for the ability to make emergency calls.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8150 8150] - [FEA] Fixed Dialing Number (FDN) feature || The device SHALL provide a feature which limits Mobile Originated Calls,
Supplementary Service Requests and MO SMS transactions to a list of
numbers.Regardless of the state of Restricted Dialing, Emergency calls SHALL be
allowed
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8152 8152] - [FEA] Error message in Call Baring || While the setting of Call Barring is activated, UE shall display the message
that user can understand "during call barring," when the call origination is
rejected.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8153 8153] - [FEA] Reject calls without caller id || The terminal shall support a function to automatically reject incoming calls
with no caller ID.

This feature shall be activated/de-activated manually.

Initially, this feature shall be deactivated.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8154 8154] - [FEA] Active creation of data entry received calls || If a customer receives a call whose number is not stored in phone book, a
dialog will automatically be invoked asking if the number should be stored in
the phonebook.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5434 5434] - [FEA] Dialer application ringtone MIDI support || Dialer should support ringing tones in MIDI format as provided by the
underlying multimedia framework.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5435 5435] - [FEA] Ringing tone assignment with a contact || The device should support a ringing tone to be assigned to a specific contact.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2658 2658] - [FEA] Dialer application call statistics || Dialer application should support call statistics of
• Duration of call
• Cost of call
• Remaining ACM balance (TBD)
|| XXX
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8174 8174] - [FEA] Multiple Call Management: Retrieve || Terminal shall be possible to retrieve all held calls at one time.
|| XXX
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8167 8167] - [FEA] Multiple Call Management: Display name or number || Terminal shall show contact's name or number of all the lines
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2661 2661] - [FEA] Dialer application ringing tones || Dialer should support user changeable ringing tones in formats supported by the
multimedia functionality of the underlying framework.

The device shall have a set default ringing tone. User should be able to change
the default ringing tone.
|| xxx
|-
| xxx || xxx
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5700 5700] - [FEA] Control Panel - Set ringtone || User shall be provided setting to set and change ringtones
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=8175 8175] - [FEA] Fixed Dialing Number editing || The device SHALL provide a 'Restricted Dialing' menu, which allows the user, to
'enable' and 'disable' Restricted dialing, and to edit and maintain a
'Restricted' dialing list.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5688 5688] - [FEA] Control Panel - Bar all incoming calls || User shall be provided settting to bar all incoming calls.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5689 5689] - [FEA] Control Panel - Bar all incoming roaming calls || User shall be provided settting to bar all incoming calls when roaming.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5690 5690] - [FEA] Control Panel - Bar all outgoing international calls || User shall be provided settting to bar all outgoing international calls.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5691 5691] - [FEA] Control Panel - Bar all outgoing international calls except to home network || User shall be provided settting to bar all outgoing international calls except
to the home network
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5692 5692] - [FEA] Control Panel - Unconditional call forwarding || User shall be provided settting to forward all calls unconditionally.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5693 5693] - [FEA] Control Panel - Busy call forwarding || User shall be provided setting to forward all calls when busy.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5694 5694] - [FEA] Control Panel - Unanswered call forwarding || User shall be provided settting to forward all calls when unanswered.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5695 5695] - [FEA] Control Panel - Unreachable call forwarding || User shall be provided settting to forward all calls when unreachable.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5696 5696] - [FEA] Control Panel - Hide caller ID || User shall be provided setting to hide the caller ID of his device once making
a call.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5697 5697] - [FEA] Control Panel - Setting 3G/2G preference || User shall be provided setting to set preference between 3G & 2G, 3G only or 2G
only.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5698 5698] - [FEA] Control Panel - Disable contact nag || User shall be provided setting to disable prompt to add contact from a call.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5699 5699] - [FEA] Control Panel - Setting speed dial numbers || User shall be provided setting to create/read/update/delete speed dial numbers
|| xxx
|-
|}

== Feature Not To Be Tested ==
Not testable features can be found using this query: [http://bugs.meego.com/buglist.cgi?action=wrap&bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&classification=MeeGo%20Features&deadlinefrom=&deadlineto=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field0-0-0=noop&longdesc=&longdesc_type=allwordssubstr&product=MeeGo%20Handset%20Features&short_desc=&short_desc_type=allwordssubstr&type0-0-0=noop&value0-0-0=&version=1.1&version=1.2&votes=&=&component=Dialer&cf_testability=No Features not to be tested]

== Strategy and Approach ==
Dialer is tested in different test sets. Test sets containing dialer related test cases are
* Sanity Test Set
** Contains few basic dialer test cases that Dialer application is part of SW image, can be opened and basic call can be made
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable dialer feature
* Extended Feature Test Set
** Contains bunch of well selected dialer test cases to verify that delivered features (Functional) forming component are working
* System Functional Test Set
** Contains interaction and negative test cases were Dialer is used together with other components that are part of system
* System Performance Test Set
** Contains only Response Time part

[[Quality/TestSetGuideline|Test Set Guideline]]

== Handset UX QA Testing Frequency ==

There are articles on [[Quality/TestSetGuideline|Overall test sets and definitions]] and [[Release_Engineering/Milestones|official milestones and definitons]]

Next picture illustrates test execution frequency for Handset UX QA team and is aligned with MM milestones. Please, click on picture and select full resolution.

[[File:MeeGoReleaseTimeline_Test_Execution.JPG|600px]]

== Hardware Platforms ==
Supported hardware info: http://meego.com/devices/handset/handset-supported-hardware

== QA Contact ==
* [mailto:mika.m.ikonen@nokia.com Mika Ikonen]

[[Category:QA]]
[[Category:Meego-1.2]]

Quality/MeeGo1.2HandSetUXTestPlanforConnectivityUI

2011-04-27T11:58:18Z

Amigadave: categorise, wikify section headings and table formatting

== Component Summary ==
This test plan is for MeeGo 1.2 HandSet UX Connectivity UI.

== Feature To Be Tested ==
All testable features coming to MeeGo 1.2 HandSet UX Connectivity UI features will be covered in this test plan.

* are summarized as below:

{| class="wikitable"
|+ Connectivity UI Features to be tested
|-
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=9251 9251] - [FEA] [I18N]The Connectivity UI app shall be internationalized according to the dependencies listed in Core Master 5068.||
* Unicode support
* All translatable strings are externalized
* UI adaptability to longer and shorter strings than English
* Ability to accept, display, sort, search, copy, paste, and print accented and double-byte characters
* No concatenation of translatable strings
* Support for the POR languages: en_US, en_GB, fr, de, es, it, fi, sv, pl, ru,nl, pt_BR, ja, ko, zh_TW, zh_CN
|| xxx
|-
|-
| xxx || xxx || xxx
|-
|}

== Feature Not To Be Tested ==
List of features that are not tested as part of MeeGo 1.2 HandSet UX are:

There are no features that are not tested.

== Strategy and Approach ==
SMS is tested in different test sets. Test sets containing SMS related test cases are
* Sanity Test Set
** Contains few basic SMS test cases that SMS application is part of SW image, can be opened and basic SMS sending/receiving can be made
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable SMS feature
* Extended Feature Test Set
** Contains bunch of well selected SMS test cases to verify that delivered features (Functional) forming component are working
* System Functional Test Set
** Contains interaction and negative test cases were SMS is used together with other components that are part of system
* System Performance Test Set
** Contains only Response Time part

[[Quality/TestSetGuideline|Test Set Guideline]]

== Handset UX QA Testing Frequency ==

There are articles on [[Quality/TestSetGuideline|Overall test sets and definitions]] and [[Release_Engineering/Milestones|official milestones and definitons]]

Next picture illustrates test execution frequency for Handset UX QA team and is aligned with MM milestones. Please, click on picture and select full resolution.

[[File:MeeGoReleaseTimeline_Test_Execution.JPG|600px]]

== Hardware Platforms ==
Supported hardware info: http://meego.com/devices/handset/handset-supported-hardware

== QA Contact ==
* [mailto:mika.m.ikonen@nokia.com Mika Ikonen]

[[Category:QA]]
[[Category:Meego-1.2]]

Quality/1.1HandsetUXVkbTestPlan

2011-04-27T11:46:58Z

Amigadave: categorise, cut topevel heading, wikify table formatting

==Component Summary==

This test plan is for MeeGo 1.1 HandSet UX Virtual keyboard (VKB).

The goal of Virtual Keyboard is to support multi language key input for different handset applications.

==Feature to be Tested==
All testable features coming to MeeGo 1.1 HandSet UX virtual keyboard will be covered in this test plan.

{| class="wikitable"
|+ VKB features to be tested
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2952 2952] - [FEA] Virtual KeyBoard integration with Meego reference apps. || VKB integrated with MeeGo referenece apps || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2677 2677] - [FEA] Virtual KeyBoard with support for alpha numeric and multi language support || A Virtual keyboard is required for touch based handsets.Virtual keyboard to support alpha and numeric and multiple languages. || xxx
|}

==Feature not to be Tested==
there aren't features not to be tested

==Test Strategy and Approach==
In general, the Virtual Keyboard test applies Black-Box test methods and refers to feature implementations to guide test design. Virtual keyboard application will be tested from different levels below:
* GUI testing
** Cover UI testing
** Better interaction with touch screen
** Common UI operation
** Launch with other applications(DUI and GTK application)
** i18n

* Functional testing
** Work with different input method
** Portrait/landscape
** Visual efforts
** Special symbol input support;

* Usage model testing
** VKB work with other applications

* Stress testing
** Quickly and continuously operation
** Work under high workload, UI repeat actions

==Test Design==
===VKB UI design ===
* '''Test Method'''
** Integration check for Virtual Keyboard
** Functinality check for Virtual Keyboard on layout, key functions, auto show/hide and so on
** Negative/stress check on Virtual Keyboard basically
** Usage model test for VKB
* '''Test Points'''
** Virtual Keyboard Integration
*** The binaries/libraries and relevant configure packages are integrated
*** Basic functionalities: VKB launch, Key press/release...
** Virtual Keyboard Functionality
*** VKB hild/show in DUI and GTK appliations
*** Every Key functions: press/release/hold and map correctness with h/w keyboard
*** Combined Keys support
*** Change/update/configure VKB layout (if the interfaces exposed to users)
*** Basically, user-concerned checking for power/performance when using virtual keyboard
*** Basically checking touch-friendly when using virtual keyboard
** Virtual Keyboard Negative/Stress Test
*** Continousely or quickly use of VKB
*** Illegal Key combination

===Virtual Keyboard in all lauguages===
* '''Test Method'''
** Test the support mechanism for other languages and integrated layout
** Negative test
* '''Test Points'''
** interface to load other languages keyboard layout
** integrate other languages keyboard layout by default (russian, japanese, korean, chinese tranditional...).

==Test Environment==
===Hardware Platforms===
* N900, AAVA and MRST CDK

===Tools===
* SMS,Fennec,Setting,IM,Email (testing VKB input support by these applications)

==QA Contact==
* [mailto:yi.fu@intel.com Fu Yi]

[[Category:QA]]
[[Category:Meego-1.1]]

Quality/1.1HandsetUXEmailTestPlan

2011-04-27T11:42:53Z

Amigadave: categorise, cut toplevel heading, wikify table formatting

==Component Summary==
* '''Email Client '''
This test plan is for MeeGo 1.1 HandSet UX Email application.

The email client depends on QT messaging framework. The Qt Messaging Framework, QMF, consists of a C++ library and daemon server process that can be used to build email clients, and more generally software that interacts with email and mail servers.

==Feature to be Tested==
All testable features coming to MeeGo 1.1 HandSet UX Email will be covered in this test plan.

{| class="wikitable"
|+ Email Features to be tested
|-
!|Feature Name
!|Feature Description
!|Vertical
!|Priority
!|Comments
|-
|POP3/IMAP/SMTP protocol support
|
* Account setting support POP3/IMAP/SMTP protocol
* Receive mail from POP3/IMAP email account
* Send mail by SMTP
|Handset
|P1
|The design input: UI design 17 Aug 2010 version and feature bugs: [http://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=meego-1.1-handset-email-features&sharer_id=402 Meego 1.1 Email features]
|-
|Email operation
| Check popular email operation support
* Send email
* Receive email
* Reply email
* Replay all
* Compose email
* Forward email
* Email cc/bcc
* Email sort
* Email search
|Handset
|P1
|The design input: UI design 17 Aug 2010 version and feature bugs: [http://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=meego-1.1-handset-email-features&sharer_id=402 Meego 1.1 Email features]
|-
|Email full view
|
* View received email
|Handset
|P1
|The design input: UI design 17 Aug 2010 version and feature bugs: [http://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=meego-1.1-handset-email-features&sharer_id=402 Meego 1.1 Email features]
|-
|Email client generate UI
|
* Check UI layout of application, buttons, icons and menus should fit main screen.
* In different context menus, check strings, check box should display well.
* Launch and exit the app for many times
|Handset
|P1
|The design input: UI design 17 Aug 2010 version and feature bugs: [http://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=meego-1.1-handset-email-features&sharer_id=402 Meego 1.1 Email features]
|-
|Email attachment support
|
* Single attachment.
* Multi attachment.
* Different attachment format, like photo,text,video,web page,binary file...
|Handset
|P1
|The design input: UI design 17 Aug 2010 version and feature bugs: [http://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=meego-1.1-handset-email-features&sharer_id=402 Meego 1.1 Email features]
|-
|TBD: address book/contact management
|
TBD
|
|
|The design input: UI design 17 Aug 2010 version and feature bugs: [http://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=meego-1.1-handset-email-features&sharer_id=402 Meego 1.1 Email features]
|-
|I18N & L10N
|
* I18N: all text strings in email should be internationalized
|Handset
|P1
|The design input: UI design 17 Aug 2010 version and feature bugs: [http://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=meego-1.1-handset-email-features&sharer_id=402 Meego 1.1 Email features]
|-
|}

==Feature not to be Tested==

{| class="wikitable"
|+ List of features that are not tested in this test plan
|-
!|Feature Name
!|Feature Description
!|Vertical
!|Priority
!|Comments
|-
|Email backend service features
|
* Backend service featuers
|
|
|
*The email backend service features test will be covered by email backend service test.
*The backend feautures in featurezilla: [http://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=meego-1.1-handset-email-backend-features&sharer_id=402 Email backend features]
|-
|Email features don't be supported in meego 1.1 release
|
* Landscape and portrait mode support
* Touch screen and gesture support
* Email Signature vCard
* Add 'CC' and 'BCC' fields action
* Attach vCard action
* Message view screen - hypertext 3
* Message view screen - hypertext 2
* Message downloading options 5
* Message downloading options 4
* Message downloading options 3
* Message downloading options 2
* Message downloading options
* Email easy archiving / sorting
* Email advanced search
* Email simple search
|
|
|
*Not meego 1.1 Email feautures in featurezilla: [http://bugs.meego.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=meego-1.1-handset-email-no-test-features&sharer_id=402 Not meego 1.1 Email feautures]
|-
|}

==Test Strategy and Approach==
In general, the email client test applies Black-Box test methods and refers to feature implementations to guide test design. Email client application will be tested from different levels below:
* GUI testing
** Cover UI testing
** Better interaction with touch screen
** Common UI operation
** i18n

* Functional testing
** Email account setup
** POP3/IMAP/SMTP email protocol support
** Email send/receive/replay/replay all/compose/forward/cc/bcc/attachment/view
** Messaging list
** Html/text email format support
** Email sort
** Move/delete/save email
** Search email
** Different email account settings like signature,email mail content and size limitation, push mail setting

* Stress testing
** Launch application multi times
** Send/receive big attchment
** Receive large amount of email
** Repeat send/receive in short time

* Negative Test
** Wrong email account setting
** Long email subject
** Special character in email subject
** Send email to invalid email address
** Network disconnect during send/receive email

==Test Design==
===Email Settings ===
* Check email settings in setting application

===Email Account Setup===
* Add email account
** Setup IMAP
** Setup POP
** Setup SMTP
* Edit email account
* Remove email account
* Enable email account
* Disable email account
* Add multi email account
* Setup default sending account
* Setup receive email interval
* Setup email size limitation
* Enable push mail
* Setup email signature

===Receive email ===
* Receive email from one account
** Receive from IMAP
** Receive from POP
* Receive email from multi account
** Receive email from all account
* Switch email account to receive email from different account one by one
* Receive large size email
* Receive from invalid email account

===Read email ===
* Browse Message list
** Email folders
*** Email folder view, switch to list view and open folder
*** Check email folders sync with email server
*** Add/remove/edit email folder
*** Move email between different email folders
** Email list view
*** Check menus of list view
*** List panel scrolling
**** Check message list pane scrolling
**** Check behaviour message list fits one page (no scroll bars etc)
**** Check behaviour if number of messages requires multiple pages to display – check scroll bars
**** Check empty email list behaviour
*** List pane – Message information in list view
**** Check subject is correctly displayed
**** Check truncation of long subjects
**** Check multiple senders are displayed as comma separated list (whatever a multiple sender is)
**** Check that attachment icon is present when the message has an attachment and not displayed when no attachment is present
**** Check that the first line of message is displayed correctly
**** Check that first line is truncated as required
**** Check behaviour if first line of message is blank
**** Check behaviour on empty message (no subject/no email content)
**** Check indicator to show message priority (TBD)
*** Switch between full message view and message list
**** Check that a single tap transitions to the correct message view
**** Check that a Long-Tap on a message opens the contextual action panel with the correct actions
**** Check multiple senders are displayed as comma separated list (whatever a multiple sender is)
**** Check that attachment icon is present when the message has an attachment and not displayed when no attachment is present
**** Check that the first line of message is displayed correctly
**** Check that first line is truncated as required
**** Check behaviour if first line of message is blank
**** Check behaviour on empty message (no subject/no email conte
*** Full message view
**** Check the email content display correct (HTML/text)
**** Check backward/forward button behavior
*** Conversation view
**** Check the menus
**** Check threaded conversation
* Switch email account
** Check the account name for the currently selected is displayed correctly (is it truncated)
** Check that the number of unread messages is displayed correctly next to the account name for the currently selected account when there are no unread messages
** Check list of accounts is present in pull-down when the selection menu is tapped
** Check correct behaviour if no accounts have been configured
** Check behaviour if there are too many account to fit on one screen
** Check that each item in the account list is displayed with the number of unread messages for that account
** Check behaviour for long account names in pull down that do not allow room for unread message count
** Check that the list view is switched to the new account when a new account is selected from the list
** Check that the new account name appears in the selection menu
** Check that the folder view reflects the new account
* Contextual menu - CAP
** Check that the contextual panel contains the following items – reply, forward, discard)
** Check that the contextual menu contains reply all when the message contains CC recipients and doesn't when the message doesn't not contain cc recipients
** Check that the contextual menu contains “move” menu item only appears if there are more than one folder
** Check that taping on each of the menu items in the contextual menu produces the transition to the correct flow
** Check how to close the contextual menu without selecting one of the menu items
* Sort
** In the browse mail view check that taping the sort button transitions to the sort pop-up panel
** Check that cancel on the sort pop-up takes you back to the message view
** Check that sort works for date ascending
** Check that sort works for date descending
** Check that sort works for subject ascending
** Check that sort works for subject descending
** Check that sort works for “from” ascending
** Check that sort works for “from” descending
** Check if there are any indication of the sort order
* Search
** Search messages with keyword

===Reply email ===
* Compose
** Check that taping the CAP reply option transitions to the compose message view
** Check that the “to” field is filed in correctly
** Check that the address field can be edited
** Check that the “from field” is correctly filled in
** Check that the account can be changed if other accounts exist
** Check that the subject field is correctly filled in (added re: but not more than one)
** Check that the subject field can be edited
** Check that the message in correctly filled in in the message body with the correct “reply” style
** Check that the message can be edited
* Message options
** check that the message options (bcc/cc attach etc) all work
* Send
** Check that taping the send options causes the message to be sent
** Check that “progress” indication is visible when message is sent
** Check that the correct notification that the message has been sent is displayed if the message is successfully submitted
** Check that correct error behaviour is performed in the send fails
** Check that any attachments from the original message are not present in the new message

===Reply all ===
* Check features as per reply
* Check that the to field and all cc's are correctly filled in

===Forward ===
* Check that tap on the contextual menu “forward” menu item transitions to the forward flow
* “keep” attachment pop-up
** Check that if the original messages contains attachments the the “keep” attachment pop-up is displayed and is not displayed if the message did not contain any attachments
** Check that if you select keep attachments they are present on the forwarded message
** Check that if you select don't keep then the attachments are not present on the forwarded message
** Check that if the cancel is selected then the view returns to TBD
* Compose
** Check that the to field is selected on entry and that it is editable as per normal to field behaviour
** Check that the subject is present and correct – with a single fwd:
** Check that the subject field is editable
** Check that the from fiend is correct using the currently active account
** Check that the from field can be changed if other accounts are set up and is not actionable if no other account is available
** Check that the message is present and is editable
** check that if attachments were kept they are present in the new message and behave as expected (see attachment handling)
* Send
** Check send behaviour is ok –( see send tests)

===Message discard ===
* Check that selecting delete does delete the message – what does that mean move to WB or actually
delete
* Check that cancel returns to the message view
* Check support batch operation

===Move message ===
* check that taping on the move icon on the CAP transitions to the folder view pop-up
* check that the folder view list all the folders for the account
* Check that the list is scrollable if the list of folders exceeds one screen view – and not if it does not
* Check that taping on a folder moves the message to the specified folder
* Check that taping on the cancel transitions back to the message list view

===Message actions (TBD) ===
* Check that long tap on an email address in a message body transitions to a CAP if the address is not already in the address book. With the following options (add new contact, save exiting contact, new email message)
* Check that long tap on an email address in a message body transitions to a CAP if the address is already in the address book. With the following options save exiting contact, new email message)

===Compose ===
* Check that single tap on compose button in list view transitions to the compose view
* Header fieds
** Check that the to field is empty and is selected for input when transition is complete
** Check to field processing (see other section)
** Check that the from field is pre populated with the current account
** Check that the from field can be changed to another account if present and is not actionable if no other account is specified
** Check that the message body is empty (assume no signature file)
** Check that the subject field is empty and editable
* CC / BCC
** Check that tap on cc/bcc icon transitions to the cc pop-up panel
** Check that selecting the cc field and apply transitions to the message compose view with the cc field has focus and is actionable (see to field tests)
** continue tap on the bbc/cc menu again and check that the pop up panel now shows ”to” and “bcc” select bbc and check message view now shows bcc
** continue tap on the bbc/cc menu again and check that the pop up panel now shows “to” and “cc” select “to” and check message view inow shows “to” field
** In “to” state check that selecting “cc” followed by cancel transition to compose view with “to” still selected
* Priority
** Check that single tap on priority transitions to the priority pop-up – check that selecting “high” followed by apply transitions to the message view with the correct priority set in the “header area” - repeat with normal and low
** check that selecting a different priority but then selecting cancel transitions to the message view without changing the priority of the message
* Sending
** Check that taping send causes the message to be sent (see send tests)
** Check that after the message is sent the user is returned to the previous list view

===Close/save message ===
* Check that single tap on close message in the compose view transitions to a “save/discard” pop-up
* Check that suspecting discard transitions to the original list view – check no message saved
* Check that suspecting cancel returns to the original message compose view
* Check that suspecting save transitions to the original list view
* Check that a message appears for a short while saying that the message has been saved
* Check that the message has been saved in the draft folder (If draft folder setuped)

===Attachments ===
* In the compose window tap the attachment icon check that it transitions to the “attach” pop-up panel
* Attachment type selector
** Check that the correct attachments type are offered
** Check that Image, document,contact,book, audio , video and appointment file types all appear correctly
** Ensure that types that are supported by more then one application only appear once in the list (e.g. text supported by notes and writer)
** Check that the type list is scrollable if the list is longer than the view and not scrollable if it fits on one view
* File picker
** check that the suspecting a particular attachment type followed by next transitions to the file picker pop-up
** Check that if cancel is selected then there is a transition back to the message compose view
** Check that the file picker lists all the files of the selected type found in the XXXX folder – check that the icon for the file type and the file name including extension
** Check that suspecting a file and attach transitions to the message view with the attached indicated
** Check that selecting cancel returns to the message compose view
** Check that suspecting back transitions back to the “type” pop-up

===Address book (TBD) ===
* Integration with address book

==Test Environment==
===Hardware Platforms===
* N900, AAVA and MRST CDK

==QA Contact==
* [mailto:yi.fu@intel.com Fu Yi]

[[Category:QA]]
[[Category:Meego-1.1]]

Quality/MeeGo1.1 Handset UX Social Networking TestPlan

2011-04-27T11:38:40Z

Amigadave: categorise, cut toplevel heading, wikify table formatting

==Component Summary==
This test plan is for MeeGo 1.1 HandSet Social networking application.

* '''Social Networking''' is an application that allows the user to fetch web services by setting up corresponding user accounts.

==Feature to be Tested==
{| class="wikitable"
!| Feature Name
!| Detailed Feature Description
!| Comments
|-
| Social Networking
* [http://bugs.meego.com/show_bug.cgi?id=5875 Bug 5875] - [FEA] Need to add social networking to MeeGo
||
* Social networking main window UI, layout and button response check
* Launch/close social networking application
* Set up social networking accounts (last.fm and twitter)
* last.fm context menu (View on Last.fm, Remove from timeline)
* Status update and Refresh
* Settings for last.fm and twitter.com
* Individual update for last.fm and twitter.com
* Post new twitter status
* Twitter context menu (Reply, Retweet, View on twitter.com, Remove from timeline)
||
* No detailed social networking feature request in featurezilla.
* Twitter web service is blocked in China.
|}

==Feature not to be Tested==
{| class="wikitable"
!|Feature Name
!|Feature Description
!|Comments
|-
|
|
|
|-
|}
* Translation for other languages except Chinese Simplified will not be covered in Handset UX Social Networking Test Plan.

==Test Strategy and Approach==
'''''Test Strategy'''''
* '''Test from UI''': to check social networking window layout, theme work correctly from UI. E.g, check if social networking application is able to be launched to home screen with full screen; if text message shows completely in both portrait and landscape modes etc.
* '''Usage Model test''': to check if last.fm and twitter.com web services could work fine from user perspective.

'''''Test Type and Approach''''' 

Social Networking component is tested in different test sets: 
* Sanity Test Set
** Contains BAT test cases of Core UX components.
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable feature of Core UX components.
* Extended Feature Test Set
** Contains bunch of well selected test cases of Core UX components to deeply verify functionality of every delivered features.
* System Functional Test Set
** Contains test cases of Core UX components that interacting and collaborating with other components to support a system usage.

[[Quality/TestSetGuideline|Test Set Guideline]]

==Test Design==

===Social Networking===
* '''Test Points'''
** Check Social networking UI, layout, theme and button response.
** check if social networking application could be launched and closed in full screen mode and live thumbnail mode.
** Check if social networking accounts (last.fm and twitter) can be configured
** Check if last.fm context menu (View on Last.fm, Remove from timeline) works
** Check if status update and Refresh works
** Check if settings for last.fm and twitter.com work
** Check if support individual update for last.fm and twitter.com
** Check if support to post new twitter status
** Check if Twitter context menu (Reply, Retweet, View on twitter.com, Remove from timeline) work

===L10n Supporting===
* '''Test Points''': to check if following items in target locale could be displayed correctly
** Application name and icon
** Button label and its icon
** Window title
** Text message
** Date, time format

==Risk and Dependency==
* No detailed social networking feature request in featurezilla.
* Twitter web service is blocked in China.

==Test Environment==
===Hardware Platforms===
* Aava DV1 and DV2
* Moorestown QS CDK with NEC PMIC

===Tools===
* bluetooth devices, wlan devices, network simulators, sim simulators, wireless AP

==QA Contact==
* [mailto:cathy.li@intel.com Cathy Li]

[[Category:QA]]
[[Category:Meego-1.1]]

Quality/MeeGo1.1 Handset Media TestPlan

2011-04-27T11:36:58Z

Amigadave: categorise, wikify table formatting, cut toplevel heading

==Component Summary==
Media subsystem plays an important role in Handset usage model. The media software stack in MeeGo is divided into 3 layers briefly. Upper level applications include Music/Photo/Video/camera application (camera application don't cover in MeeGo 1.1 release). Middleware libraries include audio server(Pulseaudio), audio library(ALSA), audio/video decoder library (Gstreamer), Gstreamer plugin, QT-mobility, Tracker etc. Low level includes kernel modules or drivers such as Intel SST audio driver, V4l2 etc.

Our testing for handset 1.1 releases focus on upper layer application. And take advantage of shell command or script to validate the middleware or driver status just for bug root cause purpose.

The relevant media format & codecs tested is focusing on the free license file format & codecs. For example: ogg format, theora video, vorbis audio, bmp, jpg, png, gif, wav etc.

==Feature to be Tested==
{| class="wikitable"
!|Feature Name
!|Feature Description
!|Vertical
!|Priority
!|Comments
|-
|Audio Player
|* Audio playback
* Audio play control
* Artist/Album/Song Navigation & Playback
* Alphabetic scrolling
* Playlist generation
* Play Queue generation
* Audio search
* Shuffle and repeat
* Usability testing
* Stability testing
* Negative testing
* I18N
|Handset
|P1
|The design input: [http://bugs.meego.com/buglist.cgi?classification=MeeGo%20Features&query_format=advanced&component=Audio%20Player&product=MeeGo%20Handset%20Features UI design 27 Jul 2010 version and feature bugs]
|-
|Photo Viewer
|* Basic photo viewer functionality
* Photo album organization
* Photo search
* Photo mainipulation via popup menu
* Photo Orientation
* Thumbnail
* Stability testing
* Negative testing
* I18N
|Handset
|P1
|The design input: [http://bugs.meego.com/buglist.cgi?classification=MeeGo%20Features&query_format=advanced&component=Photo%20viewer&product=MeeGo%20Handset%20Features UI design 28 Jul 2010 version and feature bugs]
|-
|Video Player
|* Basic video playback
* Video play control
* Alphabetic scrolling
* Video file mainipulation via popup menu
* Video files filtering & search
* Switch between different category
* Stability testing
* Negative testing
* I18N
|Handset
|P1
|The design input: [http://bugs.meego.com/buglist.cgi?classification=MeeGo%20Features&query_format=advanced&component=Video%20player&product=MeeGo%20Handset%20Features UI design 28 Jul 2010 version and feature bugs]
|}

==Features not to be tested==
Low level drivers will be not tested unless we need to perform the bug isolation.
middleware level like media framework(gstreamer) or tracker, qt-mobility, pulseaudio testing will not cover in this test plan.

==Dependency and Risks==
* Pulseaudio is buggy right now. Probably it will blocks the audio/video testing.
See Bug 150 - pulseaudio not work on CDK & Aava
* Video playback is not working also:
See Bug 5712 - Video playback is not working

==Test Strategy and Approach==
* UI testing
We will cover the media features via Music/Photo/Video application testing. Most of media usage models will be covered by this type of testing.
* User experience testing
Make sure user have comfortable usage experience like there no stuttering and no frame drop during video playback, no scratchy when playback audio and etc. There is no dedicate cases designed for it specially, it will be covered by normal usage testing.
* Negative testing
We will test boundary, negative input value and error input. Also some negative scenarios will be covered, such as playback non-media files or un-supported media file.
* Stability testing
Media is one type of resource intensive application (memory, cpu load) and user may put long time on one application like watch movie. So we test media apps' stability under long time run to make sure there is no crash etc.
* I18N testing
Test focus is for I18N mechanism in media application. Generally, we set another language environment (ex. Chinese Simplified) instead of default English environment and check the change of media application. Notes: only Chinese Simplified Translation will be covered by QA, for other languages, they will be covered by other teams.
* Performance testing
Performance testing will be covered by performance test separately.
* Others
For some low level testing such as pulseaudio, we may use pulseaudio compatible sample applications to cover the police config setting for typical usage models.

==Test Design==
====Audio====
* Audio playback
** Audio play/pause
** Audio mute/unmute
** Back to previous song
** Skip to next song
** Repeat playback
** Shuffle playback
* Artist/Album/Song Navigation & Playback
** Select given artist and browse the all albums within it
** Select given album and browse the all songs within it
** Playback all songs within one artist
** Playback all songs within one album
** Playback one song
* Alphabetic scrolling
** Scrolling to a given character head in My Music view
** Scrolling to a givne character head in playlist view
* Playlist manipulation
** Create one new playlist
** Delete one playlist
** Add all songs within one artist to a given playlist
** Add all songs wihtin one Album to a given playlist
** Add one song to a given playlist
** Playback a given playlist
* Audio search
** Search Artists/Albums/Songs by a given string
** All results/Artists/Albums/Songs tab view switch
** Playback the selected item from search result
** Add the selected item from search result into a given playlist
* Play Queue manipulation
** Switch to PlayQueue view
** Add a given song/album/artist to PlayQueue
** Check PlayQueue status display like show current song title in bottom bar
* Usability testing
** navigate the photos and listening music
** navigate the browsers and listening music
* Stability testing
** Playback the audio for a long time
** Browse great number of audio files
** Change the playback state randomly
* Negative testing
** Playback non-audio files
** Playback un-supported files
* I18N testing
** Switch language between Simplified Chinese and English

====Photo====
* Basic photo viewer functionality check
** Photo thumbnail
** View a given photo
** Photo slide show
** Photo navigation (Previous, Next)
* Photo format support (It should support common used free codec photo formats)
** JPEG
** BMP
** PNG
** GIF
* Photo album organization
** Organize photo album taken in similar time
** Organize photo album taken in similar place
* Photo search
** Search a photo by a given string
** Search an album by a given string
** Search result view switch between photo and album
* Photo mainipulation via popup menu
** Slide show
** Tag
** Copy
** Rotate CW
** Rotate CCW
** Delete
* Photo share
** email
** sms
** Facebook
** Picasa
** Bluetooth
** Flickr
* Photo Orientation
** Portrait
** Landscape
* Stability testing
** Slide show the photo files for a long time
** Browse great number of photo files
** view large photo file
* Negative testing
** View non-picture files
** View un-supported picture files
* I18N testing
** Switch language between Simplified Chinese and English

====Video====
In MeeGo 1.1 release, video player test points includes:
* Basic video playback check
* Video control bar functionality check
* Alphabetic scrolling
* Video file mainipulation via popup menu
* Video files filtering
* Video file search
* Video snapshot browsing
* Snapshot view switch between "My Movies", "Films" and "TV Shows"
* Stability testing
** Playback a long video file
** Browse great number of video files
** Change the playback state randomly
* Negative testing
** Playback non-video files
** Playback un-supported video files
* I18N testing
** Switch language between Simplified Chinese and English

==Test Environment==
===Hardware Platforms===
* Aava Koski EV2(Qual Sample) with Maxim PMIC (Firmware:2.46.4)
* Moorestown CDK with NEC PMIC (Firmware: IFWI 2.43, Kboot 0.10)

==QA Contact==
[mailto:shuang.wan@intel.com Wan Shuang]
 [mailto:jessica.ji@intel.com Jessica Ji]

==Developers==
* Video player
** [mailto:Halley.Zhao@intel.com Halley Zhao] and [mailto:huan.zheng@intel.com Huan Zheng]
* Audio
** Audio Player [mailto:forrest.zhao@intel.com Forrest Zhao]
* Photo viewer
** [mailto:long.bu@intel.com Bu Long], [mailto:ziv.chang@intel.com Ziv Chang]

[[Category:QA]]
[[Category:Meego-1.1]]

Quality/MeeGo1.1 Handset CoreUX TestPlan

2011-04-27T11:31:20Z

Amigadave: categorise, wikify table formatting, cut toplevel heading

==Component Summary==
This test plan is for MeeGo 1.1 HandSet Core UX. MeeGo handset '''Core UX''' is composed of whole '''home screen''' with '''MeeGo Touch Framework (MTF)''' (a full set of widgets and window manager), '''theme style and engine''', as well as '''system UI'''.

* '''Home Screen ''' is an application that allows the user to start an application, switch between applications, and interact with system UI. All interactive operations between users and MeeGo functionality is handled by Home Screen.
* '''MeeGo Touch Framework ''' is a widget and interaction framework that provides a collection of touch centric widgets as well as an overall platform navigation model.
* '''Theme''' provides device orientation, object hierarchy and mode styling, which is required by any MTF application.
* '''System UI''' supports run time status (connectivity, battery status, volume status), date&time and notifications appearing on top bar of home screen.

==Feature to be Tested==
{| class="wikitable"
!| Feature Name
!| Detailed Feature Description
!| Comments
|-
| Home:
* Feature [http://bugs.meego.com/show_bug.cgi?id=2680 2680] - [FEA] Meego touch framework
||
* Home screen main page UI, layout and button response check
* Application launcher UI UI, layout and button response check
* Open/close application launcher
* Launch/close application from application launcher
* Switch between running applications with home screen
* Gestures and Touch Interactions (Tap, Long press, Drag, Flick, Double tap, Pinch)
* Security setting (lock/unlock screen)
* System notification handle and interaction with home screen or running applications
|| All sub-features depend on *Core OS features*. These test cases covered several feature points from UX.
|-
| Theme:
* Feature [http://bugs.meego.com/show_bug.cgi?id=2685 2685] - [FEA] MeeGo Theme and style engine
||
* Orientation (Portrait, Landscape, 90/180/270 degrees clockwise)
* Home default theme
* Key applications (Dialer, SMS, Settings, Browser, Photo, Music, Video, Contacts) default theme
||
|-
| System UI ||
* Run time status (connectivity, battery status), date&time, notifications appearing on system UI check
* Open/Close System UI drop down menu
* Connectivity (Wifi, bluetooth, 3G, GPS, Airplane) On/Off check
* Volume status and value adjustment (TBD)
* Invoke Settings application
|| No feature request or UI design wireframe for system UI
|}

==Feature not to be Tested==
{| class="wikitable"
!|Feature Name
!|Feature Description
!|Comments
|-
|
|
|
|-
|}
* Translation for other languages except Chinese Simplified will not be covered in Handset Core UX Test Plan.

==Test Strategy and Approach==
'''''Test Strategy'''''
* '''Test from UI''': to check home screen, application launcher, system UI layout, theme and functionalities work correctly from UI. E.g, check if application is able to be launched to home screen with full screen; if could switch application to home screen by clicking home button; if correct runtime status (battery, networking) appears on system UI etc.
* '''Usage Model test''': to check if running application, home screen, system UI could work fine from user perspective.

'''''Test Type and Approach'''''

Core UX components are tested in different test sets:
* Sanity Test Set
** Contains BAT test cases of Core UX components.
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable feature of Core UX components.
* Extended Feature Test Set
** Contains bunch of well selected test cases of Core UX components to deeply verify functionality of every delivered features.
* System Functional Test Set
** Contains test cases of Core UX components that interacting and collaborating with other components to support a system usage.

[[Quality/TestSetGuideline|Test Set Guideline]]

==Test Design==

===Home Screen===
* '''Test Points'''
** Check home screen, application launcher, system UI layout.
** Open/close application launcher
** Launch/close application from application launcher or quick launch bar
** Switch between running applications with home screen
** Gestures and Touch Interactions (Tap, Long press, Drag, Flick, Double tap, Pinch)
** Security setting (lock/unlock screen)
** System notification handle and interaction with home screen or running applications

===Theme===
* '''Test Points'''
** Check home and key applications default theme
** Update theme to check if it could take effect
** Check orientation effect (Portrait, Landscape, 90/180/270 degrees clockwise)

===System UI===
* '''Test Points'''
** Check System UI layout. For instance, if correct date/time appears.
** Check if drop down menu is shown by dragging system UI, and be able to close.
** Check toggle switch On/Off button could enable/disable Gps, WiFi, 3G, Bluetooth, Airplane connectivity.
** Check if corresponding connectivity status appears on system UI when enable Gps, WiFi, 3G, Bluetooth, Airplane.
** Check whether correct battery status displays when charging and not charging.
** Check if notification appears on system UI.
** Check if setting could be invoked by tapping settings button.
** Check if volume value could be adjusted (TBD).

===L10n Supporting===
* '''Test Points''': to check if following items in target locale could be displayed correctly
** Application name and icon
** Button label and its icon
** Window title
** Text message
** Date, time, number format
** Help message
** Embedded link

==Risk and Dependency==
* Lack of home screen feature request. All MTF sub-features depend on *Core OS features*. These test cases covered several feature points from UX.
* Lack of system UI feature request or UI design wireframe.

==Test Environment==
===Hardware Platforms===
* Aava DV1 and DV2
* Moorestown QS CDK with NEC PMIC

===Tools===
* bluetooth devices, wlan devices, network simulators, sim simulators, wireless AP

==QA Contact==
* [mailto:cathy.li@intel.com Cathy Li]

[[Category:QA]]
[[Category:Meego-1.1]]

Quality/MeeGo1.1 HandSet UX PIM TestPlan

2011-04-27T11:29:57Z

Amigadave: categorise, wikify table formatting, cut toplevel heading

==Component Summary==
*Client of device data synchronization
*Clock and alarms

==Feature to be Tested==
{| class="wikitable"
|+ SyncUI features to be tested
|-
!|Component
!|Feature Summary
!|Feature Description
!|Vertical
!|Importance
!|Comments
|-
|Data Sync
|Create configuration for preset HTTP SyncML servers
|
|Handset
|High
|
|-
|Data Sync
|Create configuration for other network sync servers
|
|Handset
|High
|
|-
|Data Sync
|Detect and pair SyncML-supported BT device
|
|Handset
|High
|
|-
|Data Sync
|Sync PIM data with active HTTP SyncML server
|
|Handset
|High
|
|-
|Data Sync
|Sync PIM data with paired BT device
|
|Handset
|High
|
|-
|Data Sync
|GUI layout and navigation
|
|Handset
|High
|
|-
|Data Sync
|Interruption handling
|
|Handset
|High
|
|-
|Data Sync
|L10N
|
|Handset
|High
|
|-
|Clock
|[http://bugs.meego.com/show_bug.cgi?id=3062 Feature 3062]Clock application
|A clock application should be provided to show current time and date, and
provide alarm clock functionality.
|Handset
|High
|
|-
|}

==Feature not to be Tested==
{| class="wikitable"
!|Feature Name
!|Feature Description
!|Comments
|-
|
|
|
|-
|}

==Test Strategy and Approach==
PIM components are tested with below general test strategies:
* Isolate logical function testing from GUI testing
* Focus on features new implemented or customized for MeeGo system
* Besides of UseCase based test methods, implementation based methods are also used to reveal implementation specific faults.
PIM components are tested in different test sets:
* Sanity Test Set
** Contains BAT test cases of PIM components.
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable feature of PIM components.
* Extended Feature Test Set
** Contains bunch of well selected test cases of PIM components to deeply verify functionality of every delivered features.
* System Functional Test Set
** Contains test cases of PIM components that interacting and collaborating with other components to support a system usage.

[[Quality/TestSetGuideline|Test Set Guideline]]

==Test Design==
=== Create configuration for preset HTTP SyncML servers ===

{| class="wikitable"
|+ Test points
|-
! Preset HTTP SyncML servers
! PIM data type
! Account
|- style="vertical-align: top;"
|
* Funambol
* Goosync
* Memotoo
* Mobical
* Orale
* Ovi
* ScheduleWorld
* SyncEvolution
* ZYB
* Synthesis
|
* vCard 2.1, 3.0
* vEvent/vCalendar 1.0, 2.0
* vNote 1.1
* vTodo 1.0, 2.0
|
* login ID
* password
|}

=== Create configuration for other network sync servers ===
* '''Test Points'''
** PIM data location
** Server protocol
** Basic account information

=== Detect and pair SyncML-Supported BT device ===
* '''Test Points'''
** BT device status: Idle/Paired
** BT device capability: SyncML supported/dis-supported

=== Sync PIM data with active HTTP SyncML server ===
* '''Test Points'''
** Sync mode
*** Copy a complete database to the server and restore it from the server later.
*** Delete, modify, or add an item locally, then make the same change on the server.
*** Delete, modify, or add items on the server (or by synchronizing with another client), then make the same change locally.
*** Conflict resolution (where two clients modify the same item, then sync with the server) is handled by the server, but SyncEvolution has support which ensures that no data is lost by creating duplicates.
** Common test points of each PIM data type
*** With a reminder
*** Access level and priority
*** Different/same timezone
*** Crossing Sprint/Autumn Saving Time
*** Last day of month & last day of year
*** Special and Multi-Byte characters from
{| class="wikitable"
! Special characters form
! Multi-Byte characters form
|- style="vertical-align: top;"
|
* Accented Characters: çèéêëìíîïàáâãäåõöôóòùúûüñý
* Euro Sign: €€€€€
* Numbers: ½¼
* Omega Characters: ƒ†‡¶£¤¥§©®
* Special Characters: ~`!@#$%^&()_+=-{}|\][:”’;<>?/.,
* New Line character (↵)
|
* Chinese Characters:
** U+5317 U+4EAC Beijing
* Japanese Characters:
** U+3042 Hiragana Letter A
** U+3044 Hiragana Letter I
** U+3046 Hiragana Letter U
** U+3048 Hiragana Letter E
** U+304A Hiragana Letter O
* Korean Characters:
** U+1100 Latin characters k/g
** U+1105 Latin characters r/l
|}
** Test points specific to each PIM data type
{| class="wikitable"
! All-Day Events
! Repeating Events
! Meetings
! Contacts
! Tasks
|- style="vertical-align: top;"
|
* Single/multi-days All-Day event
|
* Everyday/Every other day/Weekly/Fornightly/
* Monthly/yearly by day, first/Nth/Last occurrence
* With/without boundary
* Repeat combination
* Repeating event plus custom repeat
* Repeating event with exceptions
|
* Create Entry as owner with Attendees from Server
* Accept Entry as Invitee from Device
|
* Addresses: Street, City, Country, Postal Code
* Phone numbers: country code, area code, and actual number
* Emails
* URLs
|
* Task complete status
|}

=== Sync PIM data with paired BT device ===
* '''Test Points'''
** Copy a complete database to the BT device and restore it from the BT device later.
** Delete, modify, or add an item locally, then make the same change on the BT device.
** Delete, modify, or add items on the BT device (or by synchronizing with another client), then make the same change locally.
** Conflict resolution handling

=== GUI layout and navigation ===
* '''Test Points'''
** Widget/Windows appearance, behaviours and event signals of controls in GUI windows.
** GUI navigation within and cross windows.
** Shortcut/Function keys handling
** Keypad and TouchScreen interaction
** Screen orientations and rotation
*** Portrait orientation
*** Landscape orientation
*** Orientation rotations during UI interactions
** VKB interaction
** SyncUI UIs
*** SyncUI Setup main UI
*** Account configure UI for preset services
*** Manual account configure UI for non-preset services
*** Account details UI
*** Sync data details UI

=== Interruption handling===
* '''Test Points'''
** Popup and interaction of all polite and urgent notification windows are not blocked by application window.
** Application should keep function after during or backing from interruption events:
*** Accounts setup and data sync.
*** Active sync tasks should keep work in background.

=== L10N Supporting ===
* '''Test Points'''
** Target system locale: combination of Language, Territory and Encode
** Keyboard input of each target locale can be handled
** Both message and non-message application resources of each target locale can displayed correctly
*** Help information
*** Images
*** Text messages
*** Fonts (family/size)
*** Date, time, and number formatting
*** Keyboard shortcut/function keys
*** Edit operations on texts: Copy/Paste/Cut/Selection/Rsesize/Curse positioning.

=== Clock application ===
* '''Test Points'''
** View Date & Time on HomeScreen
** Modify date, time, and timezone.
** Add, modify and remove one-time and reoccurrence alarms.
** Dismiss, snooze or mute sounding alarms.
** Configure alarm sound.

== Hardware Platforms ==
* N900, AAVA and MRST CDK

== QA Contact ==
* Qin Mu (qin.mu@intel.com)

[[Category:QA]]
[[Category:Meego-1.1]]

Quality/MeeGo1.1HandSetUXTestPlanforShortMessageService

2011-04-27T11:25:54Z

Amigadave: categorise, wikify table formatting, wikify section headings

== Component Summary ==
This test plan is for MeeGo 1.1 HandSet UX Short Message Service (SMS). SMS depends on ofono (for telephony services), SMS history (ofono SMS history plugin) and libseaside (for contacts data).

== Feature To Be Tested ==
All testable features coming to MeeGo 1.1 HandSet UX SMS features will be covered in this test plan. Note! Also SMS setting features are covered in this test plan.

{| class="wikitable"
|+ SMS Features to be tested
|-
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2655 2655] - [FEA] SMS application message handling functionality || SMS should support following message handling functionality
* Open message
* Forward message
* Reply to message
* Extract phone number from SMS header and text
* Call back to SMS sender
* Extract URL from SMS text body
* Send Multi-page messages
* Automatic storage of last edited message in drafts
* Sending to multiple recipients by selecting recipients from address book & multiple phone numbers entries
* Display number of characters in the SMS while it is being composed.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2629 2629] - [FEA] Short Message Service (SMS) application || A short message service application (SMS) is required to send and receive
cellular short text messages.

SMS should support numeric key entry to enter a recipient phone number and
integration to a Contacts application to select a recipient.

SMS should support message history of sent and received message.

SMS should support message notifications of success of the message delivery to
the recipient.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3019 3019] - [FEA] SMS sending to multiple recipients || SMS should support of sending to multiple recipients by selecting recipients
from address book & multiple phone numbers entries. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4159 4159] - [FEA] SMS - SMS Message Indication || The device shall support SMS Message indication to match an existing contact.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3015 3015] - [FEA] SMS pick phone number from message || SMS should support to extract a phone number from SMS header and text to
provide a quick way to call back to the sender or other indicated number.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3022 3022] - [FEA] SMS delivery notifications ||SMS should support message notifications of success of the message delivery to
the recipient.
|| xxx
|-
| Feature http://bugs.meego.com/show_bug.cgi?id=3020 3020] - [FEA] SMS composing a message || SMS should support composing a message with characters supported by the current
cellular network and the language localisation of the device.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2656 2656] - [FEA] SMS Cell Broadcast ||SMS should support broadcast messages (advertising, public information, etc.)
as specified for Cell Broadcast service (SMS-CB) in 3GPP GSM 03.41
specification.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3016 3016] - [FEA] SMS pick URL from message ||SMS should support to extract an URL from SMS text body and provide actions to
utilise the URL in other applications, e.g. to launch the Browser.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3013 3013] - [FEA] SMS message forward || SMS should support forwarding a message.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3014 3014] - [FEA] SMS message reply ||SMS should support replying to a received message.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4154 4154] - [FEA] SMS - Recieve an SMS ||The system shall be able to receive a newly delivered SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4155 4155] - [FEA] SMS - Send an SMS || The user shall be able to send an SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4158 4158] - [FEA] SMS - Save an SMS || The user shall be able to save an SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3021 3021] - [FEA] SMS display number of characters once composing || SMS should support of displaying number of characters inputted and left to fit
to a single message while it is being composed.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3023 3023] - [FEA] SMS message history || SMS should support message history of sent and received message.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4153 4153] - [FEA] SMS - Create an SMS || The user shall be able to create a message for SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4157 4157] - [FEA] SMS - View an SMS || The user shall be able to view an SMS
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4156 4156] - [FEA] SMS - Delete an SMS || The User shall be able to delete an SMS message.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3017 3017] - [FEA] SMS multi-page messages || SMS should support to send messages that exceed the number of characters
supported by the current cellular network in a single message (e.g. GSM 160
characters) by providing the means to send such a message splitted to multiple
messages (multi-page messages).
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3018 3018] - [FEA] SMS autostore message in creation || SMS should support storing last edited message automatically as a draft in a
provided folder.
|| xxx
|-
| xxx || xxx || xxx
|-
|}

== Feature Not To Be Tested ==
List of features that are not tested as part of MeeGo 1.1 HandSet UX are:

There are no features that are not tested.

== Strategy and Approach ==
SMS is tested in different test sets. Test sets containing SMS related test cases are
* Sanity Test Set
** Contains few basic SMS test cases that SMS application is part of SW image, can be opened and basic SMS sending/receiving can be made
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable SMS feature
* Extended Feature Test Set
** Contains bunch of well selected SMS test cases to verify that delivered features (Functional) forming component are working
* System Functional Test Set
** Contains interaction and negative test cases were SMS is used together with other components that are part of system
* System Performance Test Set
** Contains only Response Time part

[[Quality/TestSetGuideline|Test Set Guideline]]

== Hardware Platforms ==
* N900, AAVA and MRST CDK

== QA Contact ==
* [mailto:mika.m.ikonen@nokia.com Mika Ikonen]

[[Category:QA]]
[[Category:Meego-1.1]]

Quality/MeeGo1.1HandSetUXTestPlanforMozillaFennecBrowser

2011-04-27T11:22:36Z

Amigadave: categorise, wikify section headings, wikify table formatting

== Component Summary ==
This test plan is for MeeGo 1.1 HandSet UX Mozilla Fennec Browser. Firefox Mobile is the Browser built for the way you use the web on your mobile device.

== Feature To Be Tested ==
All testable features coming to MeeGo 1.1 HandSet UX Mozilla Fennec Browser will be covered in this test plan.

* Mozilla Fennec browser Features to be tested are summarized as below:

{| class="wikitable"
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2633 2633] - [FEA] Mozilla Fennec Browser || A Mozilla Fennec Browser is required to surf full web content in a mobile. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3032 3032] - [FEA] Browser HTML support || Browser should support full HTML4 and have partial support for HTML5. The browser SHALL support the HTML 4.01 strict document type. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2952 2952] - [FEA] Browser CSS support || Browser should support full CSS Level 2.1 and have partial support for CSS 3. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3034 3034] - [FEA] Browser JavaScript support || Browser should support full JavaScript 1.8 ECMAScript 3 and have partial support for ECMAScript 5. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3035 3035] - [FEA] Browser DOM support || Browser should support full DOM Level 1 and 2 and have partial support for DOM Level 3. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3036 3036] - [FEA] Browser XML support || Browser should support XML 1.0. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3037 3037] - [FEA] Browser XHTML support || Browser should support XHTML 1.0. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3038 3038] - [FEA] Browser XSLT and XPath || Browser should support XSLT and XPath. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3039 3039] - [FEA] Browser MathML support|| Browser should support MathML. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3040 3040] - FEA] Browser RDF support || Browser should support RDF. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3041 3041] - [FEA] Browser Flash support || Browser should support of installing the latest Adobe Flash (current 10.1) player as a plug-in to execute embedded Flash content on web pages. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3069 3069] - [FEA] Browser add-ons || Browser should support installing and running common Firefox add-ons. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3098 3098] - [FEA] Browser quick search and access with Awesome Bar || Browser should support the Awesome Bar to enable the fastest look-ups. Once typing, the Awesome Bar should display frequently or recently visited or bookmarked websites. Awesome Bar should support of entering an URL or search term and send your search directly to installed search engine add-ons, such as Google or Wikipedia. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3099 3099] - [FEA] Browser access to URL || Browser should support of entering an Uniform Resource Locator (URL) of a web service to surf to that site. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3100 3100] - [FEA] Browser bookmarks || Browser should support of storing and managing web pages as bookmarks. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3101 3101] - [FEA] Browser favicon support || Browser should support of fetching and storing web page favorites icons (favicon) provided by web pages as visual identifier of the URL and bookmarks. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3102 3102] - [FEA] Browser privacy & security settings || Browser should provide settings for user to manage passwords storing, allowing cookies, loading images, running JavaScripts and installing add-ons. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3103 3103] - [FEA] Browser remember web passwords || Browser should provide support to remember web site passwords and pre-fill those to the web page once re-visited. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3128 3128] - [FEA] Browser web page orientation || Browser should support of rendering the content optimised both on landscape and portrait modes depending on the orientation of the device (if device orientation supported by the device). || Dropped from the 1.1 release
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3129 3129] - [FEA] Browser web page zoom || Browser should support of zooming in and out of the web content. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3130 3130] - [FEA] Browser autocomplete forms || Browser should support of storing web form fields data, such as passwords and email address, and autocomplete information once revisiting such web site || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3131 3131] - [FEA] Browser Add-ons updates || Browser should support of automatically updating installed Add-ons. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4102 4102] - [FEA] Browser - Icons and Indicators in Full Screen Mode || In full Screen Mode, all icons and visual indicators SHALL be deleted. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4103 4103] - [FEA] Browser - Loading in progress indicator || During navigation, the loading phases in progress (text, images, etc.) SHALL be indicated by an animated item (animated icon) which SHALL appear immediately. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4104 4104] - [FEA] Browser - Download in progress indicator || The device SHALL provide continous progress feedback during objects download so the user knows the download is still in progress. Remaining time or % in progress SHALL be indicated || Dropped from the 1.1 release
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4107 4107] - [FEA] Browser - Functionality key mapping: Back or erase || If the device is BUTTON DRIVEN, back and erase SHALL be mapped to the back or erase soft key. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4116 4116] - [FEA] Browser - Bookmark: default name || The name of the bookmark has to be automatically filled with the title of the page and the url with the address of the page. It SHALL be possible to rename the bookmark. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4117 4117] - [FEA] Browser - New Pages and Tabs || Browser must provide mechanism to open new pages and tabs using a touch function within the browser toolbar. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4121 4121] - [FEA] Browser - Images support: recommended height || The browser SHOULD support and display images whose height is equal or higher than the device screen height. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4122 4122] - [FEA] Browser - Horizontal scrolling || The browser SHALL support the horizontal scrolling if the width of the image is larger than the screen width. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4123 4123] - [FEA] Browser - Image alt text support || The browser SHALL support the alt text attribute for images. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4124 4124] - [FEA] Browser - Multiple objects displaying || The browser SHALL be able to display several different objects (links, images, text) on the same line || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4125 4125] - [FEA] Browser - Clickable image || The browser SHALL support images as a link. The border of a linked image SHALL be able to be defined in the CSS file || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4126 4126] - [FEA] Browser - Long links display || Links longer than the width of the browser window SHALL be displayed on several lines. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4127 4127] - [FEA] Browser - Videos and CSS Layering || The browser SHALL support the display of HTML elements on top of an embedded video object using standard CSS layering (position and z-index properties). || Dropped from the 1.1 release
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4128 4128] - [FEA] Browser - Access Architecture || It SHALL be possible to access XHTML+CSS content with the following access architectures: Standard Internet architecture (HTTP over TCP/IP), Standard internet architecture with an explicit HTTP proxy || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4129 4129] - [FEA] Browser - Cookies || Browser SHALL support cookies || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4130 4130] - [FEA] Browser - Deletion of cookies || he user SHALL be able to delete his cookies || Dropped from the 1.1 release
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4131 4131] - [FEA] Browser - Security (HTTPs) support || Browser support Hypertext Transfer Protocol Secure (HTTPS) which is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encrypted communication and secure identification of a network web server || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5679 5679] - FEA] Control Panel - WiFi on-off switching || User shall be able to turn on and off the WiFi radio at anytime. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5680 5680] - [FEA] Control Panel - WiFi list networks || User shall be provided a list of available WiFi networks in range. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5681 5681] - [FEA] Control Panel - WiFi connect || User shall be able to connect and use a WiFi network of any supported type. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5682 5682] - [FEA] Control Panel - WiFi prompt passphrase || User shall be prompted for WiFi passphrase if required || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5683 5683] - [FEA] Control Panel - WiFi connect hidden networks || User shall be able to specify and connect to a "hidden" network, including specifying SSID and necessary security parameters as supported by the system. || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5684 5684] - [FEA] Control Panel - WiFi display MAC || User shall be provided means to discover the wifi MAC address || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5685 5685] - [FEA] Control Panel - WiFi IP config || User shall be provided means to specify usage DHCP or static IP for defined networks || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5686 5686] - [FEA] Control Panel - WiFi custom DNS || User shall be provided means to specify custom DNS for defined networks || xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5687 5687] - [FEA] Control Panel - Remember WiFi networks || The system shall store visited WiFi networks and the necessary parameters to reconnect once available again. User shall be provided means to remove such a defined network from the list. || xxx
|-
|}

== Feature Not To Be Tested ==
List of features that are not tested as part of MeeGo 1.1 HandSet UX are:

<add here correct query from fearutezilla>

== Strategy and Approach ==
Mozilla Fennec Browser is tested in different test sets. Test sets containing Mozilla Fennec Browser (MFB) related test cases are
* Sanity Test Set
** Contains few basic MFB test cases that MFB application is part of SW image, can be opened and basic browsing can be made
* Basic Feature Test Set
** Contains basic feature UI (Functional) test cases for every testable MFB feature
* Extended Feature Test Set
** Contains bunch of well selected MFB test cases to verify that delivered features (Functional) forming component are working
* System Functional Test Set
** Contains interaction and negative test cases were MFB is used together with other components that are part of system
* System Performance Test Set
** Contains only Response Time part

[[Quality/TestSetGuideline|Test Set Guideline]]

Note! Nokia Browser team will also perform extensive UI application test set for MFB to ensure that all relevant MFB related bugs are detected and reported. This will be done for both N900 and AAVA HW's.

== Hardware Platforms ==
* N900, AAVA and MRST CDK

== QA Contact ==
* [mailto:petri.jylha@nokia.com Petri Jylhä]

[[Category:QA]]
[[Category:Meego-1.1]]

Quality/MeeGo1.1HandSetUXTestPlanforInstantMessaging

2011-04-27T11:07:02Z

Amigadave: categorise, wikify section headings, wikify table formatting

== Component Summary ==
This test plan is for MeeGo 1.1 HandSet UX Instant Messaging. IM depends on ofono (for telephony services), IM history (ofono IM history plugin) and libseaside (for contacts data).

== Feature To Be Tested ==
All testable features coming to MeeGo 1.1 HandSet UX Instant Messaging will be covered in this test plan.

* IM Features to be tested are summarized as below:

{| class="wikitable"
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=3068 3068] - [FEA] Instant Messaging (IM) application || An instant messaging application should be provided to exchange instant
messages with other users using common Internet IM services, such as Gtalk.
|| -

|}

== Feature Not To Be Tested ==
List of features that are not tested as part of MeeGo 1.1 HandSet UX are:

There is no features that are not tested.

== Strategy and Approach ==
IM is tested in different test sets. Test sets containing IM related test cases are
* Sanity Test Set
** Contains basic IM test cases that IM application is part of SW image, can be opened and basic IM usage is possible
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable IM feature
* Extended Feature Test Set
** Contains bunch of well selected IM test cases to verify that delivered features (Functional) forming component are working
* System Functional Test Set
** Contains interaction and negative test cases were IM is used together with other components that are part of system
* System Performance Test Set
** Contains only Response Time part

[[Quality/TestSetGuideline|Test Set Guideline]]

== Hardware Platforms ==
* N900, AAVA and MRST CDK

== QA Contact ==
* [mailto:mika.m.ikonen@nokia.com Mika Ikonen]

[[Category:QA]]
[[Category:Meego-1.1]]

Quality/MeeGo1.1HandSetUXTestPlanforDialer

2011-04-27T11:05:39Z

Amigadave: categorise, wikify table formatting, cut toplevel heading, wikify section headings

== Component Summary ==
This test plan is for MeeGo 1.1 HandSet UX Dialer application. Dialer is a simple Voice Call Dialer/Manager. It depends on ofono (for telephony services), call history (ofono call history plign) and libseaside (for contacts data).

== Feature To Be Tested ==
All testable features coming to MeeGo 1.1 HandSet UX Dialer will be covered in this test plan. Note! Also telephony setting features are covered in this test plan.

* Dialer Features to be tested are summarized as below:

{| class="wikitable"
!| Feature Name
!| Description
!| Comments
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2630 2630] - [FEA] Dialer application || A phone dialing application (Dialer) is required to make and receive voice
calls.

Dialer should support integrated dialpad and integration to a Contacts
application.

Dialer should support call history with dialed, received and missed calls.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2657 2657] - [FEA] Dialer application extended call handling functionality || Dialer should support the following features
* User Determined User Busy
* Call hold/retrieve
* Call waiting
* Multiple calls
* Explicit Call Transfer (ECT)
* Call Completion to Busy Subscriber (CCBS)
* USSD Service
* Multiparty call
* Private conversation during multi-party call
* Split multiparty call
* Mute call
* Auto redial
* Send DTMF tones
* Volume up/down
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2658 2658] - [FEA] Dialer application call statistics || Dialer application should support call statistics of
* Duration of call
* Cost of call
* Remaining ACM balance (TBD)
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4143 4143] - [FEA] Dialer - Call from Call History || The system shall allow the user to initiate a call from a phone number in the
call history.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=5435 5435] - [FEA] Ringing tone assignment with a contact || The device should support a ringing tone to be assigned to a specific contact.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2660 2660] - [FEA] Dialer application Call Line Identification || Dialer should support Call Line Identification (CLIP+CLIR) GSM Supplementary
Service.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2795 2795] - [FEA] Dialer application Call hold and retrieve || Dialer should support to put the call on hold and retrieve it back from hold.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2796 2796] - [FEA] Dialer application Call waiting || Dialer should support Call waiting functionality
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2797 2797] - [FEA] Dialer application support for Multiple calls || Dialer should support handling Multiple calls at the same time. Minimum 2 calls
at the same time should be supported (one on hold, one on line).
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2809 2809] - [FEA] Dialer application mute incoming call ringtone || Dialer application should support to be able to mute incoming call ringing
tone.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2811 2811] - [FEA] Dialer application DTMF support || Dialer should support sending Dual-Tone Multi-Frequency (DTMF) tones to the
network in order to interact with provided network services, such as service
numbers and conference centers.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4133 4133] - [FEA]Dialer - One Click Viewing || The system shall provide one click viewing access while in a call to the
following functions: mute, contacts, call history, loud speaker, hold, and home
screen.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4134 4134] - [FEA] Dialer - Dialer - Make a Call || The user shall be able to make a call.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4135 4135] - [FEA] Dialer - Receive Call || The system shall be able to receive calls from a connected device.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4136 4136] - [FEA] Dialer - End Call || The system shall be able to end an active call by selecting end or by pressing
the hangup button
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4137 4137] - [FEA] Dialer - Voice Mail indicator || The system shall notify the user that there is a Voice Mail waiting
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4138 4138] - [FEA] Dialer - Display Name or Number || The system presents a call screen that shows the Name or number, if the number
matches a contact address book entry, the name is shown, otherwise the number.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4139 4139] - [FEA] Dialer - Display Contact's Photo || The system presents a call screen that shall display the contact's photo if it
matches an address book entry.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4140 4140] - [FEA] Dialer - Display Call Duration || The system shall display the duration while in a call
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4149 4149] - [FEA] Dialer - Sinlge key voicemail access || Dial to voicemail with a single key press.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4150 4150] - [FEA] Dialer - Call selected Service Number || Makes voice call to selected service number
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4152 4152] - [FEA] Dialer - Phonebook access || The terminal shall allow the user to browse the local phonebook while being in
a call.
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=2659 2659] - [FEA] Dialer application voice mail support || Dialer should support voice mail services
* Dial voice mailbox number stored in the SIM phonebook
* An indication for Voice Message Waiting (CPHS only)
|| xxx
|-
| Feature [http://bugs.meego.com/show_bug.cgi?id=4142 4142] - [FEA] Dialer - View Call History || The system shall be able to display the history of placed (outgoing and
rejected) and received (missed and answered) calls. Should list date of call,
time of call, duration of call, type of call ( placed or received) and total
number of calls
|| xxx
|-
| xxx || xxx || xxx
|}

== Feature Not To Be Tested ==
List of features that are not tested as part of MeeGo 1.1 HandSet UX are:

* Feature [http://bugs.meego.com/show_bug.cgi?id=2806 2806] - [FEA] Dialer application Multiparty call - Will be moved to release 1.2
* Feature [http://bugs.meego.com/show_bug.cgi?id=5434 5434] - [FEA] Dialer application ringtone MIDI support - Will be moved to release 1.2
* Feature [http://bugs.meego.com/show_bug.cgi?id=2805 2805] - [FEA] Dialer application support for Unstructured Supplementary Services Data (USSD) - Will be removed

== Strategy and Approach ==
Dialer is tested in different test sets. Test sets containing dialer related test cases are
* Sanity Test Set
** Contains few basic dialer test cases that Dialer application is part of SW image, can be opened and basic call can be made
* Basic Feature Test Set
** Contains basic feature (Functional) test cases for every testable dialer feature
* Extended Feature Test Set
** Contains bunch of well selected dialer test cases to verify that delivered features (Functional) forming component are working
* System Functional Test Set
** Contains interaction and negative test cases were Dialer is used together with other components that are part of system
* System Performance Test Set
** Contains only Response Time part

[[Quality/TestSetGuideline|Test Set Guideline]]

== Hardware Platforms ==
* N900, AAVA and MRST CDK

== QA Contact ==
* [mailto:mika.m.ikonen@nokia.com Mika Ikonen]

[[Category:QA]]
[[Category:Meego-1.1]]

Main Page/compspec

2011-04-27T10:53:22Z

Amigadave: redirect

#REDIRECT [[Image:MeeGo-Compliance-Spec-1.0.99.4.pdf]]

Devices/ExoPC

2011-04-27T10:50:20Z

Amigadave: add link

ExoPCs were given out at the [[Local MeeGo Networks/MeeGo Network Finland/MeeGo Summit FI|MeeGo Summit.fi in Apr 2011]].

== MeeGo Summit.fi Machines : Update Repos ==
The MeeGo Summit.fi machines were pre-installed with MeeGo 1.1 using a trunk-daily build of 1.1.90.2.20110209.4 (see /etc/zypp/repos/core.repo on the device); this is no longer available.

In the absence of a more stable repo an alternative is to track the latest package set by setting
baseurl=http://download.meego.com/trunk-daily/builds/trunk/latest/repos/oss/ia32/packages/
in the core.repo file.

Then:
zypper ref

(If anyone is brave enough to run ''zypper up'' and potentially need to reinstall then please say how this works.)

I tried that against the latest weekly repo at that time (http://repo.meego.com/MeeGo/builds/1.1.90/1.1.99.2.20110412.6/repos/oss/ia32/packages/) and first it hung on updating libc. After a reboot it ran through, but after one more reboot the Tablet UX didn't come back up anymore. Didn't investigate it further. I'll most likely use these instructions: http://meego.com/downloads/releases/1.2/meego-tablet-developer-preview and the image for aforementioned weekly.

--[[User:Dm8tbr|Dm8tbr]] 04:30, 18 April 2011 (UTC)

== Connecting Qt Creator to the Device ==
Go to Tools->Options; then Projects section, MeeGo Device Configurations tab.

Note that the meego user seems to need sudo rights to be able to run the remote execution:
cat <<EOF > /etc/sudoers.d/su-meego
meego ALL=(ALL) NOPASSWD: ALL
EOF
chmod 440 /etc/sudoers.d/su-meego

sed -i -e's/##includedir/#includedir/ /etc/sudoers

Also, for some reason, /usr/local and /usr/local/bin end up as root:root, mode 770. Fix this with:
sudo chmod 755 /usr/local
sudo chmod 755 /usr/local/bin
This looks like it's due to Qt Creator packaging
== Old Installation Notes ==

'''Warning:''' both the handset and netbook images running on the ExoPC have some problems as
of 1/30/2011. See below.
'''Warning:''' as with any other device, if you incorrectly reflash the bootloader and/or kernel, you may '''brick''' your system.

Sometimes the unit won't boot when a USB mouse is plugged in. An external keyboard doesn't cause the same problems. A mouse can be attached as soon as the MeeGo splashscreen appears. This might be a power problem that would be resolved by a USB hub with an external supply.

Installing the Handset image before the Netbook saves a bit of trouble if both are desired.

The version of parted that is invoked by the MeeGo installers [http://bugs.meego.com/show_bug.cgi?id=12945 will not resize an NTFS partition], so if you want to preserve Windows, use another partitioning tool before booting the MeeGo USB stick. [http://www.sysresccd.org/Main_Page systemrescuecd] worked fine.

The installation described here shrank the Windows partition to the (recommended minimum) 20 GB, then created an extended (logical) partition in the remaining space with a 2 GB swap partition and two primary (Is this right?) partitions of equal size in the remaining space.

Windows may come up and say that the partition table has been corrupted and that it will repair it ;-). The result is that the boot flag is set for the Win System partition, which prevents the extlinux bootloader from starting. To fix the problem, boot once more from the handy systemrescuecd stick and clear the duplicate boot flag from the System partition. Presto: your MeeGo install is again accessible.

== Installation ==

[[File:systemrescuecd_gparted_ExoPC.jpg|750px|frameless|Result of successful partitioning for triple-boot. Booting Windows may cause it to set the "boot" flag on its System partition as shown here and prevent extlinux from loading. Boot again with the systemrescuecd stick to clear the duplicate flag.]]

The ExoPC has an unlocked bootloader, so installation is relatively simple. First [http://meego.com/devices/netbook/installing-meego-your-netbook prepare a USB stick] with the image of your choice. After holding the power button for 4 seconds to start the boot process, touch the "Setup" soft button in the upper-righthand corner of the screen and disable "Quiet Boot." Boot again and touch the "BBS" soft button to manually select your USB drive as the boot device.

The netbook image does not create a useful /boot/extlinux/extlinux.conf file. One way of solving the problem is to install the handset image first, mount the handset image from the netbook image and just copy over the extlinux.conf file. Copy the entry for the handset image over to the end of the extlinux.conf file and change the details in order to create a file that works for all the images, then copy back to the handset image.

Don't forget to run "zypper update" from a terminal window as soon as your image is installed.

Warning: always unmount the USB filesystem before pulling the Flash drive out of the slot.

== Handset-specific notes ==

Touchscreen works great in the as-installed image. WiFi does not. A symptom of the problem is that both the ath9k (correct) and ath3K (wrong) kernel modules are autoloaded at boot time. Edit /etc/modprobe.d/blacklist.conf and add "blacklist ath3k" and then reboot. Unfortunately, WiFi still doesn't come up even though "lsmod" shows the same drivers as on netbook image, whose WiFi works great. "dmesg" says "ADDRCONF(NETDEV_UP): wlan0: link is not ready.

Before WiFi is working the easiest ways to get files onto the handset images are either from a mounted USB stick filesystem or by mounting the MeeGo netbook filesystem read-only and copying. In order to accomplish the latter, type "fdisk -l" to list the existing partitions. Create the directory where the netbook filesystem will be mounted, e.g. "mkdir -p /netbook". Then, assuming your netbook partition is /dev/sdaX and the filesystem type is ext3, enter "mount -t ext3 -o ro /dev/sdaX /netbook". Then "ls /netbook" will display the files on the netbook partition.

== Netbook-specific notes ==

WiFi works great with the as-installed netbook image.

As installed, the netbook image [http://bugs.meego.com/show_bug.cgi?id=9524 does not have a working touchscreen]. The system responds to a screen touch by darkening slightly and moving the cursor to the upper-lefthand corner. The needed driver, hid_egalax, is not autoloaded. Manually loading the driver with "modprobe -i hid_egalax" makes the touchscreen fully functional about half the time. Other times the behavior seems to be unaffected by the driver load.

=== Acknowledgements ===

Hat-tip to Bill Pearson of Intel for recommending the ExoPC.

[[Category:Hardware]]

IVI-LenovoS10-3t

2011-04-27T10:40:50Z

Amigadave: categorise, cut toplevel heading, reformat with <pre>

The Lenovo S10-t is a very versatile device for Meego development as is has both a 10 inch touchscreen and a keyboard. This makes it an idea candidate for UX prototyping. Installing [[In-vehicle|Meego IVI]] on the Lenovo S10-3t does require some extra work after installation.

== Installing IVI Image ==

=== Download Image ===
Select an ia32 IVI image from the Meego repo
*Weekly Images: http://repo.meego.com/MeeGo/builds/trunk/
*Release Images: http://repo.meego.com/MeeGo/releases/

=== Install Image ===
Use the standard [http://meego.com/devices/netbook/installing-meego-your-netbook|Netbook Installation] instructions using the image you selected from above. The procedure is exactly the same.

== Fixing X.org Issues ==

=== Touch Screen ===

==== Touch Coordinates Flipped Over Y-Axis ====
The official Russellville hardware requires that that Y axis be flipped for it's touch screen. This fix breaks the default calibration for the Lenovo S10-3t. To fix this issue add this to <code>/etc/X11/xorg.conf</code> or a file in <code>/etc/X11/xorg.conf.d</code>

Section "InputClass"
Identifier "evtouch touchscreen tsc2007"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "evtouch"
Option "MinX" "80"
Option "MinY" "80"
Option "MaxX" "4095
Option "MaxY" "4095"
EndSection

==== Multi Screen Configuration ====

The Lenovo S10-3t has VGA out that can clone what is being displayed on the Lenovo touchscreen or provide an additional screen. The Intel graphics driver does not support "Zaphod Style" multi-head where each screen is assigned it's own X Display and it's own set of input devices. The Intel driver only supports "Merged FB" mode where the screen is interacted with as one large desktop. You will needs to re-calibrate your touch screen if you want the 2nd monitor to the left of the Lenovo touchscreen.

To create a 2nd display from the VGA port add this to your <code>/etc/X11/xorg.conf</code>

<pre>
Section "Device"
Identifier "IntelGraphics"
Driver "intel"
Option "monitor-LVDS1" "Internal"
Option "monitor-VGA1" "External"
EndSection

Section "Monitor"
Identifier "External"
EndSection

Section "Monitor"
Identifier "Internal"
EndSection

Section "Screen"
Identifier "Left"
Device "IntelGraphics"
Monitor "External"
DefaultDepth 24
SubSection "Display"
Modes "1024x600"
EndSubSection
EndSection

Section "Screen"
Identifier "Right"
Device "IntelGraphics"
Monitor "Internal"
DefaultDepth 24
SubSection "Display"
Modes "1024x600"
EndSubSection
EndSection

Section "ServerFlags"
Option "DefaultServerLayout" "MultiHead"
EndSection

Section "ServerLayout"
Identifier "MultiHead"
Screen 0 "Right" Absolute 0 0
Screen 1 "Left" Absolute 1024 0
Option "MergedFB" "true"
Option "Clone" "false"
EndSection
</pre>

[[Category:IVI]]

In-vehicle/Roadmap/API

2011-04-27T10:35:00Z

Amigadave: categorise

== Automotive API ==

To enable applications and software functionality specific to a vehicle context the MeeGo IVI software stack needs to implement an API that allows applications to access vehicle data and execute operations. The MeeGo IVI software stack essentially extends MeeGo Core and consequently the IVI APIs are extensions of the MeeGo Core APIs.

[[File:MeeGo-IVI-Stack.png|800px|MeeGo IVI Stack]]

The API most likely will have multiple layers abstracting applications from the underlying specifics of the vehicle architecture. The latter will definitely differ from make to make and most likely within model lines of the same make and also between generations of the same model of a particular make.

The API layer provides vehicle data in a generalized form through methods such as getVehicleSpeed(), getFuelLevel(), getAverageFuelConsumption() etc. as well as executing function such as setRadioTuner(band, frequency), turnOnHeadlights(), lockDoor(doors), etc. An application can make use of these APIs directly.

Another layer of abstraction is the application framework layer that combines operations across multiple MeeGo APIs. An example could be a function providing range information based on the fuel level, the average consumption and the current vehicle position.

== API Requirements ==

=== Functionality ===

The idea of the API is to treat vehicle data that can be retrieved and vehicle functions controlled through these APIs in an abstract manner. The implementation details of the API functionality e.g. where to get a particular piece of data from such as the fuel level or to execute a particular function e.g. closing a window are treated by underlying software layer and are transparent to the API. The developer using the API should not need to have any prior knowledge about the vehicle itself for instance what make and model it is.

Since not all vehicles will implement all of the APIs it is necessary that software using the API has methods to determine during runtime what APIs are actually implemented. The most straight-forward way is that an API returns a specific value when it is not implemented e.g. API_NOT_DEFINED. A calling software module would simply invoke the API and react accordingly if the API returns API_NOT_DEFINED. However, that may not be the most efficient way since dependent on what API functionality is available software modules may want to configure themselves differently. The most obvious case would be an application that changes its appearance in the UX according to the available functionality. Hence, it is desirable that the API implements reflection that allows querying its functionality during runtime. That can be achieved via API registration or other mechanisms.

If an API is implemented it must adhere to the API specification:
* Parameters are required to have the specified types and must accept values within the specified range.
* Return values must be of the specified type and only return values within the specified range.
* Only the specified exceptions (if exceptions are used at all by the API) must be thrown.

=== Security ===

Some APIs will require access control to restrict execution to calling software modules with the correct privileges. MeeGo IVI should rely on the security mechanisms provided by MeeGo and extend them where necessary.

== API Functional Groups and Functions ==

This section list proposed APIs and places them into functional groups.

[[Category:IVI]]

In-vehicle/Roadmap/AudioManagement

2011-04-27T10:33:39Z

Amigadave: categorise

Policies for routing and prioritizing various audio sources inside a vehicle to provide entertainment on the one hand and to avoid driver distraction and bring important information to the driver's attention on the other are an integral piece of in-vehicle infotainment systems.

At a course grain level, we will have up to 7.2 speakers. In conjunction with this, we have to cater for dedicated audio jacks on for instance front and rear arm rests. We add to this complexity with the need to integrate BT head sets.
In terms of input, we can have a number of Mics for the obvious need, but also to support advanced echo cancelation - take the scenario of a cabrio from rest to 180mk/hr and the wind break noise, we need to get to a scenario where one could take a hands free call with minimum interference.

If we can picture the deployment scenario of the multitude of channels from above, then we extend this with the concept of zones. Zones are roughly equivalent to passengers. As such we need a policy control framework for controlling dynamic management of these zones. For instance, ramping down radio for incoming HFP call and the inverse when the call terminates.

In general, this area can be broken up into two coarse grained areas; audio processing itself and audio policy management.

In terms of processing, we need to cater for a DSP view of the world and an optimized opcode view of the world. In today's deployment, a multitude of filters will be applied to the channels to improve sound quality and reduce cost, for example where one wants to use cheaper speakers. We have to cater for a variety of audio re-sampling scenarios. Build in echo cancelation etc...

From a policy management perspective, we need a flexible framework to handle needs for ramping, corking, and mixing. So, along with the HFP mentioned above, we need to cater for all those gongs and bells you experience today when you fail to belt-up, lights on with door open etc...

From a MeeGo Architecture perspective, we have today PulseAudio as our server, Alsa underneath, Gstreamer from a framework perspective, and from a policy perspective we have a very interesting addition with the Policy Framework: http://conference2010.meego.com/session/policy-framework-flexible-way-orchestrate-multiple-functionalities-meego-devices So, PulseAudio, Gstreamer and Policy framework experts would be greatly appreciated.

== Design Proposal ==

Highlight the key components here - for example, PA, GST, Policy Framework, ALSA - and show the interations for the architecturally signification use cases
Sequence diagrams and component diagrams to go in this section - focus on IVI, highlight the deficiencies and potential required patches etc..

[http://meego.com/users/jalics Laci Jalics] has created an [[:File:Audio_arch1.pdf|architecture diagram]] to capture the hardware and software architecture related to audio routing and control.

=== Use Cases ===

Use Cases will be broken out into this section to give a clear overview of what Automotive Audio Management requires.

[[File:AudioControl.gif]]

Add Brief Description of Audio Control - Very simply usescases, just sat in front of my car radio and identified these.

[[File:AudioProcessing.gif]]

Add description for Automotive Audio processing.
One of the key areas to cover here is Audio Policy control - i.e. mixing, ramping down radio when inbound hands free

== Open Question ==

Where is IIR and/or FIR filtering best handled - GStreamer or Pulse?
GStreamer has some implementations, is that the most appropriate place?

== References ==

[[File:Meego-policy-framework-developer-guide.pdf|MeeGo Policy Framework Developer Guide]]

== PA hands-on ==

'''Audio zones'''

The simplest form of audio zone division within the car environment would be:

-Zone 1: front for driver. Navit audio streaming to front speakers. Speakers are attached to standard Line-Out from main automotive connector.

-Zone 2: rear for passenger(s). Movie player (Totem) audio streaming to rear headphones. These are USB headphones attached to one of 4 USB connectors.

Agenda is to use basic Meego 1.1 release on Russellvile platform and explore how far would one get with just a basic configuration changes – no new packets and no code change. So here is manual configuration for "back seat":

1. Firstly check what audio devices are available (with USB headphones attached):

$aplay -l

... Card 0 ... HDA

... Card 2 ...USB headset

2. Secondly set volume levels high for both using alsamixer tool:

$alsamixer -c 0

$alsamixer -c 2

3. Start Totem to play some audio.

4. Bring PA command application:

$ pacmd

-once started you will get prompt like: >>>

-see what sinks are available (see index for sink associated with device)

>>>list-sink

-probably will get index 1 and index 2 for HDA (card 0) and USB headset (card 2) respectively

-now check for inputs attached to sinks with:

>>>list-sink-inputs

-for example will get that sink 1 (HDA) has attached input with index 6 (can be any number) that would be Totem player.

-now you want to move that input to another sink. In example above sink 1 is HDA and sink 2 is USB headphones. Move input of sink 1 (that would be Totem with index 6) to sink 2:

>>>move-sink-input 6 2

-if you want to move it back to original sink 1 (HDA)

>>>move-sink-input 6 1

[[Category:IVI]]

In-vehicle/Roadmap/AutomotiveNetworking

2011-04-27T10:33:11Z

Amigadave: categorise, cut toplevel heading

This article describes applications that do automotive networking.

== nobdy ==
One application that provides an application API to access vehicle data and even control certain things in the vehicle is [http://wiki.openice.org/index.php?title=Nobdy nobdy]. nobdy works by exposing a dbus interface to applications for access to common vehicle services often found in modern vehicles. Through this API, applications can gain access to controls like door locking and extract information such as velocity, fuel economy, etc. The vehicle service API is very much a work in progress and may be extended to meet future needs.

nobdy also exposes a lower level API where applications can "subscribe" to specific bus messages.

nobdy provides a 3rd party plugin API so that OEMs can create vehicle-specific "providers" for their vehicles. This also puts the burden of security on the OEM to protect sensitive bus messages.

nobdy is listed as a feature in MeeGo IVI: [https://bugs.meego.com/show_bug.cgi?id=8822 FEA #8822]

[[Category:IVI]]

In-vehicle/Roadmap/FeatureScope

2011-04-27T10:32:04Z

Amigadave: categorise

This topic provides an outline of requirements for a head unit. The requirements are derived from a real life development project for in-vehicle infotainment platform. ''This is still work in progress--the content will be added gradually.''

Some of the requirements below will be fulfilled outside of the MeeGo IVI based software. For example, the implementation of CAN network interface and early audio functions most probably falls into this category. The decisions about implementation of specific requirements in MeeGo IVI software will be made assuming a specific [[In-vehicle/Roadmap/SystemArchitecture|system architecture]].

__TOC__

== Constraints ==
=== Performance ===
# After power-on, the head unit displays a static splash screen within 200 ms.
# After power-on, the head unit displays an animated splash screen (pre-defined, fixed) within 200 ms and at the frame rate above 4 fps.
# After power-on, the head unit is able to play early audio (e.g. chimes and gongs--minimal set, best suited type, simple) within max. 1 s.
# After power-on, the head unit plays FM radio, resuming the last station before shut-down, within max. 2 s.
# After power-on, the head unit plays compressed audio from a connected media device (e.g. MP3 from USB stick), resuming the last track played before shut-down, within max. 2 s.
# After power-on, the head unit displays the rear view camera output within max. 2 s.
# After power-on, the head unit accepts first user input (e.g. HMI menu, screen, volume control) within max. 2 s.
# After power-on, the head unit displays the Navigation map and starts the route guidance, resuming the previous route, within max. 5 s.
# Head unit reacts to user input via HMI (touch screen events, button or switch presses) within max. 100 ms. Head unit displays interim response (e.g. sand glass) for all requests that cannot be completed within this time
# Head unit performs voice recognition for a single word against G2P vocabulary within max. 200 ms measured from the end of utterance (silence detection) to recognition result available (e.g. HMI display update or resulting voice prompt output).
# Head unit performs hand writing recognition against Chinese standard 2000 character set within max. 200 ms measured from end of entry to recognition result available (e.g. HMI display update or resulting voice prompt output).
# Head unit exhibits the refresh rate of min 15 fps for the navigation map in any scaling.
# Head unit exhibits a graphics rendering frame rate (for HMI animations and Navigation maps) of min. 15 fps.

== Audio ==
=== Audio_Codecs_Playback ===

=== Audio_Processing_And_Management ===
# up to 4 audio zones
# audio enhancements
# any source to 4 sinks

=== Audio_Generation ===
# chimes and gongs
# calibration to interior

=== Audio_Recording ===
# voice
# radio
# podcasts

=== Audio_Volume_Control ===
# vehicle speed dependent
# volume level through shutdown cycle

== Connectivity ==
=== Wireless_Interfaces ===
==== Wireless_Infrared_IRDA ====
==== Wireless_WiFi_Connection ====
# access point
# client

==== Wireless_Bluetooth_Connection_and_Telephony ====
==== Wireless_Cellular_Mobile_Telephony ====
==== Wireless_BT_Hands-free_Telephony ====
# profiles
# Acoustic Echo Cancellation / Noise Reduction (AEC / NR)
# single and dual microphone

=== Wired_Interfaces ===
==== USB_Connection_to_CE_Devices ====
==== Removable_SD_Card_Connections ====

=== Internet_Access_and_Browser ===
# internet radio
# podcasts
# applications (e.g. google maps)
# social networks

=== Phone_Functionality ===
# internal phone book
# VoIP

=== Terminal_Mode_Functionality ===
=== Microsoft_Plays_From_Device ===

== Configuration ==
=== Personalization ===
# user profiles

== Driver_Assistance ==
# camera input processing
# electronic horizon

== Diagnostics ==

== HMI ==
=== User_Inputs_Support ===
==== UI_Devices_Support ====
==== UI_Touch_Sreen_Hand_Writing_Detection ====
==== UI_Speech_Recognition_Function ====
=== Multiple_HMI_Languages ===
=== Software_Support ===
=== Users_Manual_Integrated ===
=== Graphics_Functions ===

== Media ==
=== Media_Player_and_Browser_Requirements ===
# number of player instances
# playlists
# ripping

=== Storage_Media_Support ===

== Navigation ==
=== Navigation_Engine ===
=== Map_Function ===
# database
# 2D/3D representation

=== Real_Time_Traffic_Information ===
=== Speech_Support_for_Navigation ===
=== Positioning_Capabilities ===
=== Points_of_Interestes_POIs ===
=== Destination_Import ===

== Network ==
=== CAN_Network_Interface ===
=== MOST_Network_Interface ===
=== Ethernet_Network_Interface ===
# DLNA
# AVB

=== Serial_Network_Interfaces ===
# UART
# LIN

=== Gateway ===

== Power ==
=== Power_Management_Master ===
=== Power_Modes ===
=== Wakeup_Conditions ===
=== Monitor_Voltage_Ranges ===

== Telematics and Data Services ==
=== Emergency_and_Breakdown_Call ===
=== JAVA_Telematics_Client ===
=== Remote_Diagnostics ===
=== Vehicle_Tracking ===

== Radio and Video Broadcast Tuner ==
=== Radio_Broadcast_Reception ===
==== Radio_AM_FM_Broadcast_Reception ====
==== Radio_SDARS_Broadcast_Reception ====
==== Radio_HD_Broadcast_Reception ====
==== Radio_DAB_Broadcast_Reception ====
==== Radio_DRM_Broadcast_Reception ====
==== Broadcast_Sources_Pause_Resume ====
# time shift

==== Radio_Further_Traffic_and_Data_Services ====
=== Video_Broadcast_Reception ===

== Video ==
=== Video_Playback_Formats_and_Codecs ===
# containers
# codecs
# resolutions
# frame rates

=== Video_Decoding_Performance ===

== Voice ==
=== Voice_Tag_Processing ===
=== Voice_Recognition_Capabilties ===
=== Voice_Output_Functionality ===

== Software Services ==
=== Software_Architectural_Requirements ===
=== Software_Update ===
=== Office_Applications ===
=== Security_Features ===
# user privacy
# data storage security
# data access authorization

=== Gaming_Features ===
# pre-installed
# nomadic device

[[Category:IVI]]

In-vehicle/Roadmap/SystemArchitecture

2011-04-27T10:29:40Z

Amigadave: categorise

== Vehicle Context ==

In context of in-vehicle infotainment, the terms 'head unit', 'radio', 'module', and 'ECU (Electronics Control Unit)' are used interchangeably and refer to a individual device. This device is typically developed and manufactured by an independent supplier and delivered to the vehicle manufacturer for assembly. MeeGo IVI targets head units with a specific feature set that integrates a multitude of rich and integrated functions for audio, video, navigation, etc. Head unit is tightly integrated with other devices in the vehicle [http://conference2010.meego.com/sites/all/files/sessions/meego_conference_2010_ivi.pdf].

[[File:IVI_Vehicle_Context.png|800px|Vehicle context]]

== Head Unit Architecture ==

Inside a head unit, there a typically multiple processors responsible for different functions. One of them will run an instance of MeeGo IVI. As an example, the diagram below illustrates how different audio functions can be deployed within a head unit [http://wiki.meego.com/images/Audio_arch1.pdf].

[[File:IVI_Headunit_Audio.png|800px|Audio functions]]

[[Category:IVI]]

In-vehicle/Roadmap/UX

2011-04-27T10:28:03Z

Amigadave: categorise

== User Experience ==

Add your ideas, prototype screenshots, etc. for IVI UX's here.

=== Scope ===

In the IVI area (and especially in automotive industry), HMI is considered to be a means for branding and differentiating. This applies not only to the software, but also to the specific input and output devices used to interact with the user. Due to safety aspects, voice input plays an important role. Due to multi-user support (e.g. front and rear seat passengers), multiple displays (possibly with multiple HMI instances) as well multiple audio zones must be supported.

One of the first steps is to agree on some configuration of input/output devices that the IVI vertical would aim to support. On the one hand it should be fairly rich to support at least some of interesting use cases. On the other hand it should be relatively inexpensive and easy to realize with commodity hardware.

=== Supported I/O Devices ===

''This is a proposal that needs to be further discussed in the [[In-vehicle/working-group|WG]].''

MeeGo IVI UX should provide integrated support for the devices listed below and ordered from higher to lower priority. In some cases, there are existing peripherals that can be used to implement and test such devices.

# output to main display
# input from a pointer device (mouse or touch screen)
# output of main stereo audio (analog or digital--think vehicle speakers)
# input from a rotary knob (rotate one step to left/right events, up/down/left/right button press events, enter/escape button press events, optional button press events)
#* Contour ShuttleXpress (see [http://retail.contourdesign.com/?/products/22 here]) can be used with [[In-vehicle/IVIHome_Guide|IVI Home]] application
# input from a [mono] microphone (especially for voice commands)
#* Lenovo Ideapad has a built-in microphone
# output of auxiliary stereo audio (at least one channel; analog or digital--think head phones)
# output to auxiliary display (one or many)
#* Lenovo Ideapad has a VGA port
#* Russellville has independent LVDS and SDVO ports

[[Category:IVI]]

In-vehicle/working-group

2011-04-27T10:23:48Z

Amigadave: categorise, wikify lists

== Meetings ==
Tuesdays at 1700 UTC.

== Next Meeting ==
Tuesday 4/5/2011, 1700 UTC

''' Agenda '''
* TBD

== Meeting Minutes ==

PDF Files of the minutes of past meetings.

=== 2010 ===

* 2010-11-02: [[File:2010-11-02-MeeGoIVIWGroupMeeting.pdf]] (first meeting)
* 2010-11-09: [[File:2010-11-09-MeeGoIVIWGroupMeeting.pdf]]
* 2010-11-16: No meeting.
* 2010-11-23: [[File:2010-11-23-MeeGoIVIWGroupMeeting.pdf]]
* 2010-11-30: [[File:2010-11-30-MeeGoIVIWGroupMeeting.pdf]]
* 2010-12-07: No meeting.
* 2010-12-14: [[File:2010-12-14-MeeGoIVIWGroupMeeting.pdf]]
* 2010-12-21: [[File:2010-12-21-MeeGoIVIWGroupMeeting.pdf]] (last meeting in 2010)

=== 2011 ===

* 2011-01-11: [[File:2011-01-11-MeeGoIVIWGroupMeeting.pdf]] (first meeting in 2011)
* 2011-01-18: No meeting.
* 2011-01-25: [[File:2011-01-25-MeeGoIVIWGroupMeeting.pdf]]
* 2011-02-01: [[File:2011-02-01-MeeGoIVIWGroupMeeting.pdf]]
* 2011-02-08: [[File:2011-02-08-MeeGoIVIWGroupMeeting.pdf]]
* 2011-02-15: [[File:2011-02-15-MeeGoIVIWGroupMeeting.pdf]]
* 2011-02-22: [[File:2011-02-22-MeeGoIVIWGroupMeeting.pdf]]
* 2011-03-01: No meeting.
* 2011-03-08: [[File:2011-03-08-MeeGoIVIWGroupMeeting.pdf]]
* 2011-03-15: [[File:2011-03-15-MeeGoIVIWGroupMeeting.pdf]]
* 2011-03-22: [[File:2011-03-22-MeeGoIVIWGroupMeeting.pdf]]
* 2011-03-29: [[File:2011-03-29-MeeGoIVIWGroupMeeting.pdf]]
* 2011-04-05: [[File:2011-04-05-MeeGoIVIWGroupMeeting.pdf]]
* 2011-04-12: No meeting.
* 2011-04-19: [[File:2011-04-19-MeeGoIVIWGroupMeeting.pdf]]

[[Category:IVI]]

In-vehicle/Roadmap

2011-04-27T10:16:20Z

Amigadave: /* MeeGo 1.2 Target Features */ categorise, use https URI for bugzilla

== High-level Roadmap ==

The big picture:
* [[In-vehicle/Roadmap/FeatureScope|Feature Scope]]
* [[In-vehicle/Roadmap/SystemArchitecture|System Architecture]]

Details on Roadmap items:
* [[In-vehicle/Roadmap/AutomotiveNetworking|Automotive Networking]]
* [[In-vehicle/Roadmap/AudioManagement|Audio management]]
* [[In-vehicle/Roadmap/UX|User Experience]]
* [[In-vehicle/Roadmap/API|API]]
* App Store Demonstration
* CE Device connectivity
* Navigation
* Auto UX
* BSP/ARM-support

To help the discussion of the road map content, there is a separate overview of the [[In-vehicle/Roadmap/FeatureScope|potential feature scope]] for In-Vehicle Infotainment.

== Feature list from Bugzilla ==
Feature suggestions and planning is tracked in the MeeGo bugzilla system.

[https://bugs.meego.com/enter_bug.cgi?product=MeeGo%20IVI%20Features Submit new MeeGo IVI feature suggestions]

New feature suggestions need design and development resources to be committed before they become "ACCEPTED".

[https://bugs.meego.com/report.cgi?x_axis_field=bug_status&y_axis_field=version&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&rep_platform=Automotive&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Current status of features suggested or planned for MeeGo IVI]

== MeeGo 1.2 Target Features ==
The MeeGo 1.2 development milestones are:
* November 1, 2010 MeeGo 1.2 merge window open
* January 20, 2011 MeeGo 1.2 Feature freeze (Alpha finish, Beta start)
* March 20, 2011 MeeGo 1.2 Release Candidate start
* April 29, 2011 MeeGo 1.2 Release branch created
* May 19, 2011 MeeGo 1.2.0 Final Release

The new features planned for the MeeGo IVI 1.2 release are:
* Terminal Mode from Nokia [https://bugs.meego.com/show_bug.cgi?id=8704 Feature 8704]
* Integration of EMGD graphics [https://bugs.meego.com/show_bug.cgi?id=6863 Feature 6863] [http://bugs.meego.com/show_bug.cgi?id=8815 Feature 8815]
* Integration of TopCliff/Crown Bay drivers [https://bugs.meego.com/show_bug.cgi?id=6862 Feature 6862]
* Integration of Northville/ML7213/OKI IVI IOH drivers [https://bugs.meego.com/show_bug.cgi?id=12050 Feature 12050]
* Integration of Northville/ST ConneXt drivers [https://bugs.meego.com/show_bug.cgi?id=6865 Feature 6865]
* Updating IVI Home screen with new layout for the task launch menus and porting from QT to QML.
* Updating sample apps (browser, contacts, video player, photo player, music player, settings) from MeeGo Touch Framework based (MTF) to QML based.

[[Category:IVI]]

In-vehicle/IVIHome Guide

2011-04-27T10:11:42Z

Amigadave: categorise, wikify table formatting, add <code>

MeeGo IVI provides a "IVIHome" application that is the default MeeGo IVI homescreen when the system boots. This section provides information about the design and use of the MeeGo "IVIHome" screen and taskbar.

== IVIHome Design Objectives ==

The primary objectives in designing the IVI Home Screen were:
# Provide a sample taskbar that utilizes a scrollwheel, Text to Speech and Speech Recognition so that it can be operated without distracting driver by requiring them to look at the display or a keyboard. During system development the IVIHome and taskbar application may still be operated via touchscreen or mouse.
# Provide an "automotive" look and feel with a rounded taskbar to reflect the scrollwheel use and the ability to switch the taskbar from left side to right side of the display, presuming the display is in the automotive center console and the steering wheel could be on the left or right.

== IVIHome Use ==

Navigating the IVIHome taskbar may be done via touchscreen, scrollwheel, and Speech Recognition of voice commands with the help of Text to Speech (TTS).

Touchscreen support
* IVIHome has full touchscreen support for platforms with working touchscreen hardware and drivers
* IVIHome can also be navigated using a mouse and the user can use the mouse wheel to scroll through the menu.
Scrollwheel Support
*Currently only the Contour ShuttleXpress is supported since the key mapping is hard-coded.
*Currently only the IVIHome screen and taskbar support the ShuttleXpress. The application support has not been implemented yet.
*The ShuttleXpress controller has 5 dedicated mouse buttons and knob that turns left/right, all of these buttons simulate key presses on a hardware button in a car and currently only works when you are at the IVIHome screen, they are not yet supported in any of the applications.
*Just plug in the ShuttleXpress and it will recognize the device automatically (may have to reboot the system or restart by “pkill ivihome”)
* The buttons are mapped to the following functions:
**Button1 – BACK, this takes you back to the previous menu or closes the menu completely.
**Button2 – HOME, this will always open up the navigation menu if the menu is closed, or return you back to the home menu if you are in a sub menu.
**Button3 – SELECT/OPEN, this will open the highlighted menu or application, it is the same as clicking on the application.
**Knob Left – UP, use this to navigate through the menu in UP direction.
**Knob Right – DOWN, use this to navigate through the menu in DOWN direction.
Text-to-Speech(TTS)
*Supported by IVIHome menu navigation
*When you navigate the scroll menu list, it will use Festival to say the current menu item, you should hear “Navigation, Communication”, etc as you browse through the menu.
*Text to speech is turned on by default, however, if you use TTS with speech recognition on a system with a mic too close to the speakers, they might interfere.
*You can turn TTS on/off by editing the configuration file in <code>/usr/share/ivihome/settings.xml</code> and change <texttospeech>on<texttospeech> to off, then restart ivihome by executing “pkill ivihome”
Speech recognition (IVIHome menu voice commands)
*Speech recognition is supported by IVIHome. Speech recognition in applications needs to be added.
*IVIHome speech recognition does not support continuous speech, it only recognizes voice commands for the IVIhome menu as shown below
*To turn on speech recognition, click on the microphone icon on the taskbar, to turn it off, click again.
*The following tables list the supported voice commands (you can also look in <code>/usr/share/ivihome/data/ivihome.jsgf</code>):

{| class="wikitable"
|+ Menu Navigation Commands
|-
!Voice Command
!Resulting action
|-
|"Home"
|Opens the home menu if the menu is closed, or returns to the home menu, same as the clicking HOME button on ShuttleXpress
|-
|"Back"
|goes back to the last menu, same as clicking the BACK button on ShuttleXpress
|-
|"Cancel"
|closes the menu completely
|-
|"Next"
|moves to the next menu item in the list, same as turning the knob to the RIGHT on the ShuttleXpress
|-
|"Previous"
|moves to the last menu item in the list, same as turning the knob to the LEFT on the ShuttleXpress
|-
|"Next Window"
|switches to the next opened application window on the taskbar
|-
|"Previous Window"
|switches to the previous opened application window on the taskbar
|-
|"Close Window"
|closes the current application window, exiting the app
|}

You can directly name any Catagory listed in the Root Menu or specific applications shown in each Catagory Menu.

{| class="wikitable"
|+ Named Category and Application Commands
|-
!Catagory Command
!Recognized Application Commands
|-
|"Navigation"
|
|-
|"Driver Assistance"
|
|-
|"Communication"
|"Web", "Phone", "Connect"
|-
|"Media"
|"Photos", "Video", "Music"
|-
|"Other"
|"Activities", "Tools", "More Apps"
|}

Voice commands may be used to skip menu navigation and go directly to specific applications
{| class="wikitable"
|+ Application commands
|-
!Voice Command
!Resulting action
|-
|"Open Navigation"
|opens the Navit application
|-
|"Open Dialer"
|opens the handsfree dialer application
|-
|"Open Contacts"
|opens the MeeGo contacts application
|-
|"Open Web"
|opens the Fennec browser
|-
|"Open Browser"
|opens the Fennec browser
|-
|"Open Photo"
|opens the the MeeGo photo application
|-
|"Open Music"
|opens the MeeGo music application
|-
|"Open Video"
|opens the MeeGo video application
|-
|"Open Setting"
|opens the the MeeGo control panel application
|}

The list of applications for each of the above application commands are defined in the <code>/usr/share/ivihome/settings.xml</code> file. You can edit this file to change the application that is launched by the voice commands. You cannot change the vocabulary list directly, it needs to be re-generated. If you want to add more voice commands, you’ll have to add the command in the dictionary and re-generate the language model (grammar) and dictionary and implement the logic in the application.

[[Category:IVI]]

In-vehicle/IVI for users and developers

2011-04-27T10:02:22Z

Amigadave: categorise

== Users ==

List of MeeGo compatible [[Devices]]

=== Installation ===

*Instructions for [[ARM|N900 / ARM based devices]]
*Instructions for [[IVI-LenovoS10-3t|Lenovo S10-3t]]

=== Advanced Topics ===

==== Car PC Hobbyist Challenge ====

#Hardware support
#* Intel ITX motherboards: Most widely spread in the existing community
#Installation
#* Power - How much? How to switch it on?
#* Placement - Where are the components located?, Heating/Cooling
#Interfacing with system
#* startup solutions
#* Volume control
#* Touchscreen navigating/button placement
#Capabilities/Functions
#* Large Music libraries
#* Navigation
#* phone syncing

== Developers ==

[[Developer Guide]]

*Instructions for [[ARM|N900 / ARM based devices]]
*Instructions for [[IVI-LenovoS10-3t|Lenovo S10-3t]]

{{Developer pages}}

== Resource ==
*[http://www.mp3car.com/vbulletin/meego-vehicle/ MP3Car Forum MeeGo section]

[[Category:IVI]]

In-vehicle

2011-04-27T10:01:49Z

Amigadave: /* Resources */ better link, categorise

= In-vehicle Infotainment (IVI) =

MeeGo IVI is setting the new standard for in-vehicle infotainment in cars, buses, airplanes, etc. MeeGo IVI is a Free and Open-Source Software (FOSS) OS distribution integrating the MeeGo Core for embedded systems leveraging and extending functionality known from mobile computers and handsets into vehicles. Building on the MeeGo OS Base and the MeeGo OS Middleware the MeeGo IVI software stack enables rich Internet and multimedia experiences to consumers while traveling.

== Organization ==

The MeeGo IVI organization is composed of a Working Group and a Project Team. The Working Group is responsible for the definition of the roadmap and the MeeGo IVI Project Team executes the implementation through the partnering organizations using the best practices of open-source development. Through the collaboration of organizations and companies covering automotive, computer hardware, communications, and software industries this partnership enables jump-starting product development for rapid delivery allowing adopters to concentrate on their core competencies while benefiting from this extensive know-how and the open-source assets.

For a graphical representation of the organizational structure: [[Media:MeeGo_IVI_OrgStruct.pdf]]

=== Working Group ===

The Working Group is composed from the following members and roles:

* Working Group Chair
** Represents and promotes the Working Group.
** Leads strategic discussions on requirements, direction, policies.
** Commitment: full-time role.
** Current Working Group Chair: '''[http://meego.com/users/RudolfStreif Rudi Streif (Linux Foundation)]'''

* Working Group Representative (the number is not limited, others participants to be invited)
** Represents his/her organization in the Working Group.
** Collects, organizes, prioritizes, and contributes requirements from his/her organization.
** Commitment: 20% - 50% dependent on how actively the organization wants to contribute requirements.
** Current Working Group Representatives:
*** Intel: '''[http://meego.com/users/jahoffmann Joel Hoffmann]'''
*** Nokia: '''[http://meego.com/users/alistair Alistair Adams]'''
*** Pelagicore: '''[http://meego.com/users/mikael Mikael Soderberg]'''
*** Visteon: '''[http://meego.com/users/PavelKonopelko Pavel Konopelko]'''

* Product Manager (cross-function across Working Group and Project Team)
** Unifies and prioritizes overall requirements set.
** Owns the roadmap.
** Leads the Project Team and defines the release schedule together with the Project Manager.
** Accountable to the Working Group for delivery of agreed upon requirements.
** Commitment: full-time role.
** Full job description: [[Media:MeeGo_IVI_PDM.pdf]]
** Current Product Manager:

* Program Manager (cross-functional across Working Group and Project Team)
** Works the Lead Architects and Lead Designers on effort estimates and schedules.
** Leads the Project Team together with the Project Manager.
** Accountable to the Working Group for deliverables and schedule.
** Commitment: full-time role.
** Full job description: [[Media:MeeGo_IVI_PJM.pdf]]
** Current Program Manager: '''[http://meego.com/users/joel Joel Clark (Intel)]'''

The Working Group meets regularly. Information on current and past meetings can be found on [[in-vehicle/working-group|IVI Working Group]].

=== Project Team ===

The Project Team has members with various roles that are subject to change according to the requirements of the current projects. The number of members and roles in the Project Team is not limited and grow as the team gains momentum and takes on larger tasks.

* Lead Architect
** Defines technical architecture to meet the requirements n terms of functionality, performance, etc.
** Defines interfaces between modules and components together with other Lead Architects within the same and/or other Project Teams.
** Performs feasibility studies and provides feedback to product manager on technical challenges, difficulties, “show stoppers”.
** Commitment: > 50% dependent on sub-project complexity.
** Current Lead Architect: '''[http://meego.com/users/tomcounihan Tom Counihan (Intel)]'''

* Lead Designer (multiple roles)
** Responsible for the detailed implementation design of the architecture.
** Estimates the effort necessary for implementation.
** Leads implementation team comprised of engineering resources of his/her organization.
** Commitment: full-time role.
** Current Lead Designers
***
***

* QA Lead (multiple roles)
** Transforms requirements into functionality test plans.
** Develops interface and compliance test procedures according to the architecture.
** Implements black box and white box test tools through the resources of his/her organization.
** Executes test plans and provides test reports.
** Commitment: full-time role.
** Current QA Leads:
***
***

* Release Manager
** Coordinates bug tracking, build and release with the design and QA leads.
** Develops and manages build tools.
** Leads build and release engineering team.
** Commitment: full-time role.
** Current Release Manager: '''[http://meego.com/users/jeremiah Jeremiah Foster (Pelagicore)]'''

* Engineers for Development and QA (many roles)
** Implement and test the required functionality.
** Qualification varies with sub-project.
** Commitment: full-time role.

== Roadmap ==

The roadmap is always under discussion. But the important thing it that it is open and transparent - and you can contribute. The path to contribution begins on the MeeGo IVI mailing list. This list is the central communication point with all the MeeGo IVI stakeholders participating. Through this list you can contribute ideas, code, and other resources. You will also receive support and advice as well as pointers to other resources on this list, this is where the community comes together.

The roadmap pages are the central collaboration point on laying out the future of MeeGo IVI. Here architecture details, system diagrams, use cases, etc. are shared.

[[In-vehicle/Roadmap|View the Roadmap]]

Before any new feature is committed to the Roadmap, a feature request is created in http://bugs.meego.com.

[https://bugs.meego.com/enter_bug.cgi?product=MeeGo%20IVI%20Features Submit new MeeGo IVI feature request ]

For a Feature Request to become part of the MeeGo IVI release plan, it needs to clearly define the engineering requirements and have resources working on development.

More details on the long term direction and short term Release plan may be found in the [[In-vehicle/Roadmap|IVI roadmap]].

=== MeeGo IVI Weekly Builds ===
Automated weekly MeeGo IVI repository and image builds are available on meego.com for testing and development baselining. Each build has a build version and date in its path. [[Release Engineering/Release Versioning|MeeGo Release Versioning]] explains the build version numbering scheme. For example '''1.1.80.xx''' is a 1.2 Alpha build, '''1.1.90.xx''' is a 1.2 Beta build, '''1.1.99.x''' is a 1.2 Release Candidate, and '''1.2.1''' is the first release update after the final 1.2 release.

[http://repo.meego.com/MeeGo/builds/trunk/ MeeGo weekly build repositories]

IVI live .iso images are found under the ''IVI'' link. A list of every package included a live image is found in the same directory as the image. RPM packages are found under the ''oss'' and ''non-oss'' links.

'''MeeGo IVI 1.2 Feature Status'''

[https://bugs.meego.com/report.cgi?x_axis_field=bug_status&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&version=1.2&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&rep_platform=Automotive&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Featurezilla status report of MeeGo 1.2 IVI features]

[[In-vehicle/IVIHome Guide|Guide for the IVI Home Screen]]

;February 12, 2011
:IVI Home Screen Changes
::The ''IVIHome'' screen has been updated to reduce the number of choices in the main menu. Instead of a dozen or so choices in the main menu and two to three choices in sub-menus, now there are five to six choices in the main menu and about the same in sub-menus. We changed this to make menu choices easier and quicker. The IVI home screen has been designed to support driver interaction with the minimal amount of distraction. This is enhanced by the use of scrollwheel, Text to Speech and Speech Recognition, removing the need to look at or touch the display.
:Nokia Terminal Mode
::Packages implementing the client side of Nokia Terminal Mode have been included in the build repositories. There are two packages(libqterminalmode and qterminalmodeclient) which must be installed from the ''oss'' repositories in order to try this code. These packages interact with phonesets that support the server side of Nokia Terminal Mode. Nokia has developer kit phone sets that implement the server side of terminal mode. [http://www.terminalmode.org/en/developer/developer-offering/ Terminal Mode Developer Offering] has more information about the software and how to get developer kits
:WiFi Tethering
::MeeGo IVI now includes the capability to act as a WiFi Access Point enabling data sharing between tethered WiFi devices [https://bugs.meego.com/show_bug.cgi?id=7696 MeeGo WiFi Tethering Feature]
:EMGD
::The Embedded Media Graphics Driver (EMGD) is now integrated with all IA32 builds and provides support for the Power-VR graphics core in Intel IVI platforms. The driver package is named <nowiki> "emgd-bin...."</nowiki> and can be found in the <nowiki>"non-oss"</nowiki> repository. This driver is considered ENGINEERING SAMPLE quality with NO guaranteed response to issues. Anyone planning to use this driver in product should obtain production quality support from the EMGD team via http://edc.intel.com

;March 8, 2011
:EMGD
::The Intel EMGD graphics driver has had continued updates including the addition of support for hardware accelerated video decode.
:ML7213 platform
::kernel driver support for the Oki Semiconductor ML7213 IVI IOH chipset has been added. This chipset is used on the Intel Stephenville/Crossville IVI platform. This platform is in very early sampling now to select customers of the Intel Embedded Computing Group.

===MeeGo IVI 1.2 Release Supported Platforms===

;IA32
{| border="1"
! Image name
! Platform name
! Intel chipset
! I/O Hub name
! drivers included
! status
|-
|meego-ivi-ia32
|Congatec IVI Kit (Russellville)
|Intel Atom Z5xx Series and Intel System Controller Hub US15Wx (eMenlow)
|Timberdale
|GPIO, DMA, SPI, I2C, UART, USB, IDE, Audio, KS8842 GigE, EMGD, Video-in, SDHC, TSC2007, I2S, SDHC, ADV7180, BT, Radio
|No known driver issues
|-
|meego-ivi-ia32
|Crown Bay
|Intel Atom E6xx Series for Embedded (Tunnel Creek)
|Intel Platform Controller Hub EG20T (Top Cliff)
|GPIO, DMA, SPI, I2C, UART, USB, SATA, Audio, GigE, EMGD, PHUB, CAN
|No known driver issues
|-
|meego-ivi-ia32
|Stephenville/Crossville
|Intel Atom E6xx Series for Embedded (Tunnel Creek)
|Oki Semiconductors ML7213 IVI IOH
|GPIO, DMA, SPI, I2C, UART, USB, SATA, Audio, EMGD, SD/SDIO/MMC, USB-OTG, TDM, sDVO
|No known driver issues
|}

===MeeGo IVI Trunk Prototype Platforms===

;IA32
{| border="1"
! Image name
! Platform name
! Intel chipset
! I/O Hub name
! drivers included
! status
|-
|meego-ivi-ia32-conx
|Stephenville/Northville/Crossville
|Intel® Atom™ Processor E6xx Series for Embedded (Tunnel Creek)
|ST Microelectronics ConneXt STA2x11
|GPIO, DMA, SPI, I2C, UART, USB, SATA, Audio, GigE, EMGD, Video-in, MMC, CAN, USB-OTG, MSP, BT, FM-Radio
|in development, several issues open
|}

;ARM
:Jeremiah Foster and Jan-Simon Moeller are working on updates to enable automated weekly builds of MeeGo IVI images for the Beagleboard-XM.
:The suggested reference platform is the Beagleboard xM. The [[ARM/OMAP4_Panda|PandaBoard]] and [[ARM/Snowball|Snowball]] most likely will be supported in the future.
{| border="1"
! Image name
! Platform name
! chipset
! status
|-
| meego-ivi-armv7l
| Beagleboard xM
| OMAP 3
| Not yet smoke tested. No QA
|-
| meego-ivi-armv7l
| Tegra2
| ARM v7 rev 0
| Not yet smoke tested. No QA
|-
|}

=== Releases ===
* [http://meego.com/downloads/releases/1.0/meego-v1.0-in-vehicle-infotainment-ivi MeeGo IVI 1.0]
* [http://meego.com/downloads/releases/1.1/meego-v1.1-in-vehicle-infotainment-ivi MeeGo IVI 1.1]

== Resources ==
* IRC irc.freenode.org #meego-ivi
* Mailing list sign-up: http://lists.meego.com/listinfo/meego-ivi
* Mailing list archive: http://lists.meego.com/pipermail/meego-ivi/
* [[In-vehicle/IVI for users and developers|IVI for users and developers]]
* [[IVITopic|Topics]]

[[Category:IVI]]

IVI

2011-04-27T10:00:43Z

Amigadave: change redirect to point to In-vehicle

#REDIRECT [[In-vehicle]]

Devices/ExoPC

2011-04-27T09:55:31Z

Amigadave: categorise

ExoPCs were given out at the MeeGo Summit.fi in Apr 2011.

== MeeGo Summit.fi Machines : Update Repos ==
The MeeGo Summit.fi machines were pre-installed with MeeGo 1.1 using a trunk-daily build of 1.1.90.2.20110209.4 (see /etc/zypp/repos/core.repo on the device); this is no longer available.

In the absence of a more stable repo an alternative is to track the latest package set by setting
baseurl=http://download.meego.com/trunk-daily/builds/trunk/latest/repos/oss/ia32/packages/
in the core.repo file.

Then:
zypper ref

(If anyone is brave enough to run ''zypper up'' and potentially need to reinstall then please say how this works.)

I tried that against the latest weekly repo at that time (http://repo.meego.com/MeeGo/builds/1.1.90/1.1.99.2.20110412.6/repos/oss/ia32/packages/) and first it hung on updating libc. After a reboot it ran through, but after one more reboot the Tablet UX didn't come back up anymore. Didn't investigate it further. I'll most likely use these instructions: http://meego.com/downloads/releases/1.2/meego-tablet-developer-preview and the image for aforementioned weekly.

--[[User:Dm8tbr|Dm8tbr]] 04:30, 18 April 2011 (UTC)

== Connecting Qt Creator to the Device ==
Go to Tools->Options; then Projects section, MeeGo Device Configurations tab.

Note that the meego user seems to need sudo rights to be able to run the remote execution:
cat <<EOF > /etc/sudoers.d/su-meego
meego ALL=(ALL) NOPASSWD: ALL
EOF
chmod 440 /etc/sudoers.d/su-meego

sed -i -e's/##includedir/#includedir/ /etc/sudoers

Also, for some reason, /usr/local and /usr/local/bin end up as root:root, mode 770. Fix this with:
sudo chmod 755 /usr/local
sudo chmod 755 /usr/local/bin
This looks like it's due to Qt Creator packaging
== Old Installation Notes ==

'''Warning:''' both the handset and netbook images running on the ExoPC have some problems as
of 1/30/2011. See below.
'''Warning:''' as with any other device, if you incorrectly reflash the bootloader and/or kernel, you may '''brick''' your system.

Sometimes the unit won't boot when a USB mouse is plugged in. An external keyboard doesn't cause the same problems. A mouse can be attached as soon as the MeeGo splashscreen appears. This might be a power problem that would be resolved by a USB hub with an external supply.

Installing the Handset image before the Netbook saves a bit of trouble if both are desired.

The version of parted that is invoked by the MeeGo installers [http://bugs.meego.com/show_bug.cgi?id=12945 will not resize an NTFS partition], so if you want to preserve Windows, use another partitioning tool before booting the MeeGo USB stick. [http://www.sysresccd.org/Main_Page systemrescuecd] worked fine.

The installation described here shrank the Windows partition to the (recommended minimum) 20 GB, then created an extended (logical) partition in the remaining space with a 2 GB swap partition and two primary (Is this right?) partitions of equal size in the remaining space.

Windows may come up and say that the partition table has been corrupted and that it will repair it ;-). The result is that the boot flag is set for the Win System partition, which prevents the extlinux bootloader from starting. To fix the problem, boot once more from the handy systemrescuecd stick and clear the duplicate boot flag from the System partition. Presto: your MeeGo install is again accessible.

== Installation ==

[[File:systemrescuecd_gparted_ExoPC.jpg|750px|frameless|Result of successful partitioning for triple-boot. Booting Windows may cause it to set the "boot" flag on its System partition as shown here and prevent extlinux from loading. Boot again with the systemrescuecd stick to clear the duplicate flag.]]

The ExoPC has an unlocked bootloader, so installation is relatively simple. First [http://meego.com/devices/netbook/installing-meego-your-netbook prepare a USB stick] with the image of your choice. After holding the power button for 4 seconds to start the boot process, touch the "Setup" soft button in the upper-righthand corner of the screen and disable "Quiet Boot." Boot again and touch the "BBS" soft button to manually select your USB drive as the boot device.

The netbook image does not create a useful /boot/extlinux/extlinux.conf file. One way of solving the problem is to install the handset image first, mount the handset image from the netbook image and just copy over the extlinux.conf file. Copy the entry for the handset image over to the end of the extlinux.conf file and change the details in order to create a file that works for all the images, then copy back to the handset image.

Don't forget to run "zypper update" from a terminal window as soon as your image is installed.

Warning: always unmount the USB filesystem before pulling the Flash drive out of the slot.

== Handset-specific notes ==

Touchscreen works great in the as-installed image. WiFi does not. A symptom of the problem is that both the ath9k (correct) and ath3K (wrong) kernel modules are autoloaded at boot time. Edit /etc/modprobe.d/blacklist.conf and add "blacklist ath3k" and then reboot. Unfortunately, WiFi still doesn't come up even though "lsmod" shows the same drivers as on netbook image, whose WiFi works great. "dmesg" says "ADDRCONF(NETDEV_UP): wlan0: link is not ready.

Before WiFi is working the easiest ways to get files onto the handset images are either from a mounted USB stick filesystem or by mounting the MeeGo netbook filesystem read-only and copying. In order to accomplish the latter, type "fdisk -l" to list the existing partitions. Create the directory where the netbook filesystem will be mounted, e.g. "mkdir -p /netbook". Then, assuming your netbook partition is /dev/sdaX and the filesystem type is ext3, enter "mount -t ext3 -o ro /dev/sdaX /netbook". Then "ls /netbook" will display the files on the netbook partition.

== Netbook-specific notes ==

WiFi works great with the as-installed netbook image.

As installed, the netbook image [http://bugs.meego.com/show_bug.cgi?id=9524 does not have a working touchscreen]. The system responds to a screen touch by darkening slightly and moving the cursor to the upper-lefthand corner. The needed driver, hid_egalax, is not autoloaded. Manually loading the driver with "modprobe -i hid_egalax" makes the touchscreen fully functional about half the time. Other times the behavior seems to be unaffected by the driver load.

=== Acknowledgements ===

Hat-tip to Bill Pearson of Intel for recommending the ExoPC.

[[Category:Hardware]]

In-vehicle

2011-04-27T09:43:51Z

Amigadave: /* MeeGo IVI Weekly Builds */ wikify link

= In-vehicle Infotainment (IVI) =

MeeGo IVI is setting the new standard for in-vehicle infotainment in cars, buses, airplanes, etc. MeeGo IVI is a Free and Open-Source Software (FOSS) OS distribution integrating the MeeGo Core for embedded systems leveraging and extending functionality known from mobile computers and handsets into vehicles. Building on the MeeGo OS Base and the MeeGo OS Middleware the MeeGo IVI software stack enables rich Internet and multimedia experiences to consumers while traveling.

== Organization ==

The MeeGo IVI organization is composed of a Working Group and a Project Team. The Working Group is responsible for the definition of the roadmap and the MeeGo IVI Project Team executes the implementation through the partnering organizations using the best practices of open-source development. Through the collaboration of organizations and companies covering automotive, computer hardware, communications, and software industries this partnership enables jump-starting product development for rapid delivery allowing adopters to concentrate on their core competencies while benefiting from this extensive know-how and the open-source assets.

For a graphical representation of the organizational structure: [[Media:MeeGo_IVI_OrgStruct.pdf]]

=== Working Group ===

The Working Group is composed from the following members and roles:

* Working Group Chair
** Represents and promotes the Working Group.
** Leads strategic discussions on requirements, direction, policies.
** Commitment: full-time role.
** Current Working Group Chair: '''[http://meego.com/users/RudolfStreif Rudi Streif (Linux Foundation)]'''

* Working Group Representative (the number is not limited, others participants to be invited)
** Represents his/her organization in the Working Group.
** Collects, organizes, prioritizes, and contributes requirements from his/her organization.
** Commitment: 20% - 50% dependent on how actively the organization wants to contribute requirements.
** Current Working Group Representatives:
*** Intel: '''[http://meego.com/users/jahoffmann Joel Hoffmann]'''
*** Nokia: '''[http://meego.com/users/alistair Alistair Adams]'''
*** Pelagicore: '''[http://meego.com/users/mikael Mikael Soderberg]'''
*** Visteon: '''[http://meego.com/users/PavelKonopelko Pavel Konopelko]'''

* Product Manager (cross-function across Working Group and Project Team)
** Unifies and prioritizes overall requirements set.
** Owns the roadmap.
** Leads the Project Team and defines the release schedule together with the Project Manager.
** Accountable to the Working Group for delivery of agreed upon requirements.
** Commitment: full-time role.
** Full job description: [[Media:MeeGo_IVI_PDM.pdf]]
** Current Product Manager:

* Program Manager (cross-functional across Working Group and Project Team)
** Works the Lead Architects and Lead Designers on effort estimates and schedules.
** Leads the Project Team together with the Project Manager.
** Accountable to the Working Group for deliverables and schedule.
** Commitment: full-time role.
** Full job description: [[Media:MeeGo_IVI_PJM.pdf]]
** Current Program Manager: '''[http://meego.com/users/joel Joel Clark (Intel)]'''

The Working Group meets regularly. Information on current and past meetings can be found on [[in-vehicle/working-group|IVI Working Group]].

=== Project Team ===

The Project Team has members with various roles that are subject to change according to the requirements of the current projects. The number of members and roles in the Project Team is not limited and grow as the team gains momentum and takes on larger tasks.

* Lead Architect
** Defines technical architecture to meet the requirements n terms of functionality, performance, etc.
** Defines interfaces between modules and components together with other Lead Architects within the same and/or other Project Teams.
** Performs feasibility studies and provides feedback to product manager on technical challenges, difficulties, “show stoppers”.
** Commitment: > 50% dependent on sub-project complexity.
** Current Lead Architect: '''[http://meego.com/users/tomcounihan Tom Counihan (Intel)]'''

* Lead Designer (multiple roles)
** Responsible for the detailed implementation design of the architecture.
** Estimates the effort necessary for implementation.
** Leads implementation team comprised of engineering resources of his/her organization.
** Commitment: full-time role.
** Current Lead Designers
***
***

* QA Lead (multiple roles)
** Transforms requirements into functionality test plans.
** Develops interface and compliance test procedures according to the architecture.
** Implements black box and white box test tools through the resources of his/her organization.
** Executes test plans and provides test reports.
** Commitment: full-time role.
** Current QA Leads:
***
***

* Release Manager
** Coordinates bug tracking, build and release with the design and QA leads.
** Develops and manages build tools.
** Leads build and release engineering team.
** Commitment: full-time role.
** Current Release Manager: '''[http://meego.com/users/jeremiah Jeremiah Foster (Pelagicore)]'''

* Engineers for Development and QA (many roles)
** Implement and test the required functionality.
** Qualification varies with sub-project.
** Commitment: full-time role.

== Roadmap ==

The roadmap is always under discussion. But the important thing it that it is open and transparent - and you can contribute. The path to contribution begins on the MeeGo IVI mailing list. This list is the central communication point with all the MeeGo IVI stakeholders participating. Through this list you can contribute ideas, code, and other resources. You will also receive support and advice as well as pointers to other resources on this list, this is where the community comes together.

The roadmap pages are the central collaboration point on laying out the future of MeeGo IVI. Here architecture details, system diagrams, use cases, etc. are shared.

[[In-vehicle/Roadmap|View the Roadmap]]

Before any new feature is committed to the Roadmap, a feature request is created in http://bugs.meego.com.

[https://bugs.meego.com/enter_bug.cgi?product=MeeGo%20IVI%20Features Submit new MeeGo IVI feature request ]

For a Feature Request to become part of the MeeGo IVI release plan, it needs to clearly define the engineering requirements and have resources working on development.

More details on the long term direction and short term Release plan may be found in the [[In-vehicle/Roadmap|IVI roadmap]].

=== MeeGo IVI Weekly Builds ===
Automated weekly MeeGo IVI repository and image builds are available on meego.com for testing and development baselining. Each build has a build version and date in its path. [[Release Engineering/Release Versioning|MeeGo Release Versioning]] explains the build version numbering scheme. For example '''1.1.80.xx''' is a 1.2 Alpha build, '''1.1.90.xx''' is a 1.2 Beta build, '''1.1.99.x''' is a 1.2 Release Candidate, and '''1.2.1''' is the first release update after the final 1.2 release.

[http://repo.meego.com/MeeGo/builds/trunk/ MeeGo weekly build repositories]

IVI live .iso images are found under the ''IVI'' link. A list of every package included a live image is found in the same directory as the image. RPM packages are found under the ''oss'' and ''non-oss'' links.

'''MeeGo IVI 1.2 Feature Status'''

[https://bugs.meego.com/report.cgi?x_axis_field=bug_status&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=MeeGo+Features&version=1.2&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&rep_platform=Automotive&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Featurezilla status report of MeeGo 1.2 IVI features]

[[In-vehicle/IVIHome Guide|Guide for the IVI Home Screen]]

;February 12, 2011
:IVI Home Screen Changes
::The ''IVIHome'' screen has been updated to reduce the number of choices in the main menu. Instead of a dozen or so choices in the main menu and two to three choices in sub-menus, now there are five to six choices in the main menu and about the same in sub-menus. We changed this to make menu choices easier and quicker. The IVI home screen has been designed to support driver interaction with the minimal amount of distraction. This is enhanced by the use of scrollwheel, Text to Speech and Speech Recognition, removing the need to look at or touch the display.
:Nokia Terminal Mode
::Packages implementing the client side of Nokia Terminal Mode have been included in the build repositories. There are two packages(libqterminalmode and qterminalmodeclient) which must be installed from the ''oss'' repositories in order to try this code. These packages interact with phonesets that support the server side of Nokia Terminal Mode. Nokia has developer kit phone sets that implement the server side of terminal mode. [http://www.terminalmode.org/en/developer/developer-offering/ Terminal Mode Developer Offering] has more information about the software and how to get developer kits
:WiFi Tethering
::MeeGo IVI now includes the capability to act as a WiFi Access Point enabling data sharing between tethered WiFi devices [https://bugs.meego.com/show_bug.cgi?id=7696 MeeGo WiFi Tethering Feature]
:EMGD
::The Embedded Media Graphics Driver (EMGD) is now integrated with all IA32 builds and provides support for the Power-VR graphics core in Intel IVI platforms. The driver package is named <nowiki> "emgd-bin...."</nowiki> and can be found in the <nowiki>"non-oss"</nowiki> repository. This driver is considered ENGINEERING SAMPLE quality with NO guaranteed response to issues. Anyone planning to use this driver in product should obtain production quality support from the EMGD team via http://edc.intel.com

;March 8, 2011
:EMGD
::The Intel EMGD graphics driver has had continued updates including the addition of support for hardware accelerated video decode.
:ML7213 platform
::kernel driver support for the Oki Semiconductor ML7213 IVI IOH chipset has been added. This chipset is used on the Intel Stephenville/Crossville IVI platform. This platform is in very early sampling now to select customers of the Intel Embedded Computing Group.

===MeeGo IVI 1.2 Release Supported Platforms===

;IA32
{| border="1"
! Image name
! Platform name
! Intel chipset
! I/O Hub name
! drivers included
! status
|-
|meego-ivi-ia32
|Congatec IVI Kit (Russellville)
|Intel Atom Z5xx Series and Intel System Controller Hub US15Wx (eMenlow)
|Timberdale
|GPIO, DMA, SPI, I2C, UART, USB, IDE, Audio, KS8842 GigE, EMGD, Video-in, SDHC, TSC2007, I2S, SDHC, ADV7180, BT, Radio
|No known driver issues
|-
|meego-ivi-ia32
|Crown Bay
|Intel Atom E6xx Series for Embedded (Tunnel Creek)
|Intel Platform Controller Hub EG20T (Top Cliff)
|GPIO, DMA, SPI, I2C, UART, USB, SATA, Audio, GigE, EMGD, PHUB, CAN
|No known driver issues
|-
|meego-ivi-ia32
|Stephenville/Crossville
|Intel Atom E6xx Series for Embedded (Tunnel Creek)
|Oki Semiconductors ML7213 IVI IOH
|GPIO, DMA, SPI, I2C, UART, USB, SATA, Audio, EMGD, SD/SDIO/MMC, USB-OTG, TDM, sDVO
|No known driver issues
|}

===MeeGo IVI Trunk Prototype Platforms===

;IA32
{| border="1"
! Image name
! Platform name
! Intel chipset
! I/O Hub name
! drivers included
! status
|-
|meego-ivi-ia32-conx
|Stephenville/Northville/Crossville
|Intel® Atom™ Processor E6xx Series for Embedded (Tunnel Creek)
|ST Microelectronics ConneXt STA2x11
|GPIO, DMA, SPI, I2C, UART, USB, SATA, Audio, GigE, EMGD, Video-in, MMC, CAN, USB-OTG, MSP, BT, FM-Radio
|in development, several issues open
|}

;ARM
:Jeremiah Foster and Jan-Simon Moeller are working on updates to enable automated weekly builds of MeeGo IVI images for the Beagleboard-XM.
:The suggested reference platform is the Beagleboard xM. The [[ARM/OMAP4_Panda|PandaBoard]] and [[ARM/Snowball|Snowball]] most likely will be supported in the future.
{| border="1"
! Image name
! Platform name
! chipset
! status
|-
| meego-ivi-armv7l
| Beagleboard xM
| OMAP 3
| Not yet smoke tested. No QA
|-
| meego-ivi-armv7l
| Tegra2
| ARM v7 rev 0
| Not yet smoke tested. No QA
|-
|}

=== Releases ===
* [http://meego.com/downloads/releases/1.0/meego-v1.0-in-vehicle-infotainment-ivi MeeGo IVI 1.0]
* [http://meego.com/downloads/releases/1.1/meego-v1.1-in-vehicle-infotainment-ivi MeeGo IVI 1.1]

== Resources ==
* IRC irc.freenode.org #meego-ivi
* Mailing list sign-up: http://lists.meego.com/listinfo/meego-ivi
* Mailing list archive: http://lists.meego.com/pipermail/meego-ivi/
* [[IVI|IVI for users and developers]]
* [[IVITopic|Topics]]

IVIHome Guide

2011-04-27T09:42:49Z

Amigadave: moved IVIHome Guide to In-vehicle/IVIHome Guide: make a subpage of In-vehicle

#REDIRECT [[In-vehicle/IVIHome Guide]]

In-vehicle/IVIHome Guide

2011-04-27T09:42:49Z

Amigadave: moved IVIHome Guide to In-vehicle/IVIHome Guide: make a subpage of In-vehicle

MeeGo IVI provides a "IVIHome" application that is the default MeeGo IVI homescreen when the system boots. This section provides information about the design and use of the MeeGo "IVIHome" screen and taskbar.

== IVIHome Design Objectives ==

The primary objectives in designing the IVI Home Screen were:
# Provide a sample taskbar that utilizes a scrollwheel, Text to Speech and Speech Recognition so that it can be operated without distracting driver by requiring them to look at the display or a keyboard. During system development the IVIHome and taskbar application may still be operated via touchscreen or mouse.
# Provide an "automotive" look and feel with a rounded taskbar to reflect the scrollwheel use and the ability to switch the taskbar from left side to right side of the display, presuming the display is in the automotive center console and the steering wheel could be on the left or right.

== IVIHome Use ==

Navigating the IVIHome taskbar may be done via touchscreen, scrollwheel, and Speech Recognition of voice commands with the help of Text to Speech (TTS).

Touchscreen support
* IVIHome has full touchscreen support for platforms with working touchscreen hardware and drivers
* IVIHome can also be navigated using a mouse and the user can use the mouse wheel to scroll through the menu.
Scrollwheel Support
*Currently only the Contour ShuttleXpress is supported since the key mapping is hard-coded.
*Currently only the IVIHome screen and taskbar support the ShuttleXpress. The application support has not been implemented yet.
*The ShuttleXpress controller has 5 dedicated mouse buttons and knob that turns left/right, all of these buttons simulate key presses on a hardware button in a car and currently only works when you are at the IVIHome screen, they are not yet supported in any of the applications.
*Just plug in the ShuttleXpress and it will recognize the device automatically (may have to reboot the system or restart by “pkill ivihome”)
* The buttons are mapped to the following functions:
**Button1 – BACK, this takes you back to the previous menu or closes the menu completely.
**Button2 – HOME, this will always open up the navigation menu if the menu is closed, or return you back to the home menu if you are in a sub menu.
**Button3 – SELECT/OPEN, this will open the highlighted menu or application, it is the same as clicking on the application.
**Knob Left – UP, use this to navigate through the menu in UP direction.
**Knob Right – DOWN, use this to navigate through the menu in DOWN direction.
Text-to-Speech(TTS)
*Supported by IVIHome menu navigation
*When you navigate the scroll menu list, it will use Festival to say the current menu item, you should hear “Navigation, Communication”, etc as you browse through the menu.
*Text to speech is turned on by default, however, if you use TTS with speech recognition on a system with a mic too close to the speakers, they might interfere.
*You can turn TTS on/off by editing the configuration file in /usr/share/ivihome/settings.xml and change <texttospeech>on<texttospeech> to off, then restart ivihome by executing “pkill ivihome”
Speech recognition (IVIHome menu voice commands)
*Speech recognition is supported by IVIHome. Speech recognition in applications needs to be added.
*IVIHome speech recognition does not support continuous speech, it only recognizes voice commands for the IVIhome menu as shown below
*To turn on speech recognition, click on the microphone icon on the taskbar, to turn it off, click again.
*The following tables list the supported voice commands (you can also look in /usr/share/ivihome/data/ivihome.jsgf):
Menu Navigation Commands
{| border="1"
!Voice Command
!Resulting action
|-
|"Home"
|Opens the home menu if the menu is closed, or returns to the home menu, same as the clicking HOME button on ShuttleXpress
|-
|"Back"
|goes back to the last menu, same as clicking the BACK button on ShuttleXpress
|-
|"Cancel"
|closes the menu completely
|-
|"Next"
|moves to the next menu item in the list, same as turning the knob to the RIGHT on the ShuttleXpress
|-
|"Previous"
|moves to the last menu item in the list, same as turning the knob to the LEFT on the ShuttleXpress
|-
|"Next Window"
|switches to the next opened application window on the taskbar
|-
|"Previous Window"
|switches to the previous opened application window on the taskbar
|-
|"Close Window"
|closes the current application window, exiting the app
|}

Named Category and Application Commands

You can directly name any Catagory listed in the Root Menu or specific applications shown in each Catagory Menu.
{| border="1"
!Catagory Command
!Recognized Application Commands
|-
|"Navigation"
|
|-
|"Driver Assistance"
|
|-
|"Communication"
|"Web", "Phone", "Connect"
|-
|"Media"
|"Photos", "Video", "Music"
|-
|"Other"
|"Activities", "Tools", "More Apps"
|}

Application commands

Voice commands may be used to skip menu navigation and go directly to specific applications
{| border="1"
!Voice Command
!Resulting action
|-
|"Open Navigation"
|opens the Navit application
|-
|"Open Dialer"
|opens the handsfree dialer application
|-
|"Open Contacts"
|opens the MeeGo contacts application
|-
|"Open Web"
|opens the Fennec browser
|-
|"Open Browser"
|opens the Fennec browser
|-
|"Open Photo"
|opens the the MeeGo photo application
|-
|"Open Music"
|opens the MeeGo music application
|-
|"Open Video"
|opens the MeeGo video application
|-
|"Open Setting"
|opens the the MeeGo control panel application
|}

The list of applications for each of the above application commands are defined in the <code>/usr/share/ivihome/settings.xml</code> file. You can edit this file to change the application that is launched by the voice commands. You cannot change the vocabulary list directly, it needs to be re-generated. If you want to add more voice commands, you’ll have to add the command in the dictionary and re-generate the language model (grammar) and dictionary and implement the logic in the application.

Release Engineering/Plans/1.1

2011-04-27T09:39:41Z

Amigadave: categorise

== MeeGo 1.1 Release Plan ==

{| cellpadding="5" cellspacing="0" border="1"
! Iteration !! Dates !! MeeGo release focus !! Status URL !! Features Bugfixes Tasks
|-
| style="background-color:#ff9900" | 1.0.80.1
| 2010-05-06--2010-05-12
| Trunk opened for 1.1 development
|
|
|-
| style="background-color:#ff9900" | 1.0.80.2
| 2010-05-13--2010-05-19
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.2.20100518.1/ Download]
|
|-
| style="background-color:#ff9900" | 1.0.80.3
| 2010-05-20--2010-05-26
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.3.20100525.1/ Download]
|
|-
| style="background-color:#ff9900" | 1.0.80.4
| 2010-05-27--2010-06-02
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.4.20100601.1/ Download]
|
|-
| style="background-color:#ff9900" | 1.0.80.5
| 2010-06-03--2010-06-09
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.5.20100608.1/ Download]
|
|-
| style="background-color:#ff9900" | 1.0.80.6
| <s style="color: red">2010-06-10--2010-06-16</s> 2010-06-10--2010-06-17
| Due to critical problems in kernel release was delayed for one day
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.6.20100616.1/ Download]
|
|-
| style="background-color:#ff9900" | 1.0.80.7
| 2010-06-18--2010-06-23
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.7.20100622.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.80.7|Details]]
|-
| style="background-color:#ffff00" | 1.0.80.8
| 2010-06-24--2010-06-30
| Alpha: Most intrusive changes delivered. Handset "Day 1". Normal feature development continues.
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.8.20100629.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.80.8|Details]]
|-
| style="background-color:#ffff00" | 1.0.80.9
| 2010-07-01--2010-07-07
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.9.20100707.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.80.9|Details]]
|-
| style="background-color:#ffff00" | 1.0.80.10
| 2010-07-08--2010-07-14
| <s style="color: red">Transition to GCC 4.5 - delayed</s>
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.10.20100713.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.80.10|Details]]
|-
| style="background-color:#ffff00" | 1.0.80.11
| 2010-07-15--2010-07-21
| Transition to GCC 4.5 - done
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.11.20100720.1/ Core and Netbook] [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.11.20100720.2/ Handset (fixed)]
| [[Release_Engineering/Plans/1.1/1.0.80.11|Details]]
|-
| style="background-color:#ffff00" | 1.0.80.12
| 2010-07-22--2010-07-28
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.12.20100727.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.80.12|Details]]
|-
| style="background-color:#ffff00" | 1.0.80.13
| 2010-07-29--2010-08-04
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.13.20100803.2/ Download]
| [[Release_Engineering/Plans/1.1/1.0.80.13|Details]]
|-
| style="background-color:#ffff00" | 1.0.80.14
| 2010-08-05--2010-08-11
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.14.20100810.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.80.14|Details]]
|-
| style="background-color:#ffff00" | 1.0.80.15
| 2010-08-12--2010-08-18
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.15.20100817.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.80.15|Details]]
|-
| style="background-color:#ffff00" | 1.0.80.16
| 2010-08-19--2010-08-25
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.80/1.0.80.16.20100824.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.80.16|Details]]
|-
| style="background-color:#99cc00" | 1.0.90.0
| 2010-08-26--2010-09-01
| Feature freeze, Bugfixing for most of features, Possibility to integrate features that are late
| Released [http://repo.meego.com/MeeGo/builds/1.0.90/1.0.90.0.20100831.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.90.0|Details]]
|-
| style="background-color:#99cc00" | 1.0.90.1
| 2010-09-02--2010-09-08
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.90/1.0.90.1.20100907.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.90.1|Details]]
|-
| style="background-color:#99cc00" | 1.0.90.2
| 2010-09-09--2010-09-15
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.90/1.0.90.2.20100914.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.90.2|Details]]
|-
| style="background-color:#99cc00" | 1.0.90.3
| 2010-09-16--2010-09-22
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.90/1.0.90.3.20100921.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.90.3|Details]]
|-
| style="background-color:#99cc00" | 1.0.90.4
| 2010-09-23--2010-09-29
|
| Released [http://repo.meego.com/MeeGo/builds/1.0.90/1.0.90.4.20100928.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.90.4|Details]]
|-
| style="background-color:#00ff00" | 1.0.99.0
| 2010-09-30--2010-10-06
| Gamma: MeeGo 1.1 Release candidate 1: Branching for release critical bugfixes only (trunk re-opens for 1.2).
| Released [http://repo.meego.com/MeeGo/builds/1.0.99/1.0.99.0.20101005.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.99.0|Details]]
|-
| style="background-color:#00ff00" | 1.0.99.1
| 2010-10-07--2010-10-13
| MeeGo 1.1 Release candidate 2 (preparation of marketing materials)
| Released [http://repo.meego.com/MeeGo/builds/1.0.99/1.0.99.1.20101012.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.99.1|Details]]
|-
| style="background-color:#00ff00" | 1.0.99.2
| 2010-10-14--2010-10-20
| RTM: MeeGo 1.1 Release candidate 3 (release to marketing, prepare final announces)
| Released [http://repo.meego.com/MeeGo/builds/1.0.99/1.0.99.2.20101019.1/ Download]
| [[Release_Engineering/Plans/1.1/1.0.99.2|Details]]
|-
| style="background-color:#339966" | 1.1.0.0
| 2010-10-21--2010-10-27
| GA, RTW: MeeGo 1.1 Release for Core, Netbooks, Handsets, ... (General availability, release to web)
|
| [[Release_Engineering/Plans/1.1/1.1.0.0|Details]]
|-
| style="background-color:#339966" | 1.1.1
| 2010-11-26
| MeeGo 1.1 Update 1
| Released [http://repo.meego.com/MeeGo/updates/1.1/ Download]
| [http://meego.com/downloads/releases/updates Details]
|-
| style="background-color:#339966" | 1.1.2
| 2011-01-11
| MeeGo 1.1 Update 2
| Released [http://repo.meego.com/MeeGo/updates/1.1/ Download]
| [http://meego.com/downloads/releases/updates Details]
|-
| style="background-color:#339966" | 1.1.3
| 2011-02-28
| MeeGo 1.1 Update 3
| Released [http://repo.meego.com/MeeGo/updates/1.1/ Download]
| [http://meego.com/downloads/releases/updates Details]
|-
| style="background-color:#339966" | 1.1.4
| 2011-04-11
| MeeGo 1.1 Update 4
| Released [http://repo.meego.com/MeeGo/updates/1.1/ Download]
| [http://meego.com/downloads/releases/updates Details]
|}

== MeeGo 1.1 Features Status ==
{{#bugzilla:
|columns=id,status,to,severity,version,summary
|product=MeeGo Core OS Features,MeeGo Handset Features,MeeGo Netbook Features,MeeGo IVI Features
|version=1.1
|bar=status
|group=product
}}

[http://bugs.meego.com/report.cgi?x_axis_field=bug_status&y_axis_field=component&z_axis_field=product&query_format=report-table&classification=MeeGo+Features&product=MeeGo+Connected+TV+Features&product=MeeGo+Core+OS+Features&product=MeeGo+Handset+Features&product=MeeGo+IVI+Features&product=MeeGo+Netbook+Features&product=MeeGo+Tablet+Features&version=1.1&bug_severity=enhancement&format=table&action=wrap Detailed report in Featurezilla]

== MeeGo 1.1 Bugs Status ==
{{#bugzilla:
|columns=id,status,to,severity,version,summary
|product=MeeGo SDK,OS Base,OS Middleware,Handset User Experience,Netbook User Experience,Netbook IVI Experience
|version=1.1
|bar=status
|group=product
}}

[http://bugs.meego.com/report.cgi?x_axis_field=bug_status&y_axis_field=component&z_axis_field=product&query_format=report-table&classification=MeeGo+Platform&product=Automotive+User+Experience&product=Handset+User+Experience&product=MeeGo+SDK&product=Netbook+User+Experience&product=OS+Base&product=OS+Middleware&version=1.1&format=table&action=wrap Detailed report in Bugzilla]

[[Category:Release engineering]]
[[Category:Meego-1.1]]

Release Engineering/Plans/1.2

2011-04-27T09:38:52Z

Amigadave: categorise

== MeeGo 1.2 Release Plan ==

{| cellpadding="5" cellspacing="0" border="1"
! Iteration !! Iteration Start -- End Dates !! MeeGo Release Focus !! Status URL !! Features Bugfixes 
|-
| style="background-color:#ff9900" | 1.1.80.0
| 2010-09-30 -- 2010-10-06
| MM1: Trunk opened for 1.2 development on 2010-09-30.
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.0.20101005.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.0|Details]]
|-
| style="background-color:#ff9900" | 1.1.80.1
| 2010-10-07 -- 2010-10-13
|
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.1.20101012.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.1|Details]]
|-
| style="background-color:#ff9900" | 1.1.80.2
| 2010-10-14 -- 2010-10-20
|
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.2.20101019.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.2|Details]]
|-
| style="background-color:#ff9900" | 1.1.80.3
| 2010-10-21 -- 2010-10-27
|
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.3.20101026.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.3|Details]]
|-
| style="background-color:#ff9900" | 1.1.80.4
| 2010-10-28 -- 2010-11-03
|
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.4.20101102.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.4|Details]]
|-
| style="background-color:#ff9900" | 1.1.80.5
| 2010-11-04 -- 2010-11-10
|
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.5.20101109.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.5|Details]]
|-
| style="background-color:#ff9900" | 1.1.80.6
| 2010-11-11 -- 2010-11-17
|
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.6.20101116.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.6|Details]]
|-
| style="background-color:#ff9900" | 1.1.80.7
| 2010-11-18 -- 2010-11-24
|
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.7.20101123.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.7|Details]]
|-
| style="background-color:#ffff00" | 1.1.80.8
| 2010-11-25 -- 2010-12-01
| MM2: Most intrusive changes delivered. Normal feature development continues after 2010-12-01. i18n code scans begin.
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.8.20101130.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.8|Details]]
|-
| style="background-color:#ffff00" | 1.1.80.9
| 2010-12-02 -- 2010-12-08
|
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.9.20101207.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.9|Details]]
|-
| style="background-color:#ffff00" | 1.1.80.10
| 2010-12-09 -- 2010-12-15
|
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.10.20101214.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.10|Details]]
|-
| style="background-color:#ffff00" | 1.1.80.11
| 2010-12-16 -- 2010-12-22
| MM2.5: checkpoint for features delivery
|Released [http://archive.meego.com/MeeGo/builds/1.1.80/1.1.80.11.20101221.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.11|Details]]
|-
| style="background-color:#ffff00" | 1.1.80.12
| 2010-12-23 -- 2010-12-29
| Due to holidays in most of the countries, release has been skipped
|Skipped
| [[Release_Engineering/Plans/1.2/1.1.80.12|Details]]
|-
| style="background-color:#ffff00" | 1.1.80.13
| 2010-12-30 -- 2011-01-05
|
|Released [http://repo.meego.com/MeeGo/builds/1.1.80/1.1.80.13.20110105.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.13|Details]]
|-
| style="background-color:#ffff00" | 1.1.80.14
| 2011-01-06 -- 2011-01-12
|
|Released [http://repo.meego.com/MeeGo/builds/1.1.80/1.1.80.14.20110111.8/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.14|Details]]
|-
| style="background-color:#ffff00" | 1.1.80.15
| 2011-01-13 -- 2011-01-19
|
|Released [http://repo.meego.com/MeeGo/builds/1.1.80/1.1.80.15.20110118.5/ Download]
| [[Release_Engineering/Plans/1.2/1.1.80.15|Details]]
|-
| style="background-color:#99cc00" | 1.1.90.0
| 2011-01-20 -- 2011-01-26
| MM3: All planned features released, Bugfixing for most of features starts after 2011-01-26, Possibility to integrate features that are late
|Released [http://repo.meego.com/MeeGo/builds/1.1.80/1.1.90.0.20110125.3/ Download]
| [[Release_Engineering/Plans/1.2/1.1.90.0|Details]]
|-
| style="background-color:#99cc00" | 1.1.90.1
| 2011-01-27 -- 2011-02-02
|
|Released [http://repo.meego.com/MeeGo/builds/1.1.90/1.1.90.1.20110201.1/ Download]
| [[Release_Engineering/Plans/1.2/1.1.90.1|Details]]
|-
| style="background-color:#99cc00" | 1.1.90.2
| 2011-02-03 -- 2011-02-09
|
|Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.90.2.20110208.4/ Download]
| [[Release_Engineering/Plans/1.2/1.1.90.2|Details]]
|-
| style="background-color:#99cc00" | 1.1.90.3
| 2011-02-10 -- 2011-02-16
|
|Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.90.3.20110215.10/ Download]
| [[Release_Engineering/Plans/1.2/1.1.90.3|Details]]
|-
| style="background-color:#99cc00" | 1.1.90.4
| 2011-02-17 -- 2011-02-23
|
|Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.90.4.20110222.2/ Download]
| [[Release_Engineering/Plans/1.2/1.1.90.4|Details]]
|-
| style="background-color:#99cc00" | 1.1.90.5
| 2011-02-24 -- 2011-03-02
|
|Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.90.5.20110301.7/ Download]
| [[Release_Engineering/Plans/1.2/1.1.90.5|Details]]
|-
| style="background-color:#99cc00" | 1.1.90.6
| 2011-03-03 -- 2011-03-09
|
|Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.90.6.20110308.5/ Download]
| [[Release_Engineering/Plans/1.2/1.1.90.6|Details]]
|-
| style="background-color:#99cc00" | 1.1.90.7
| 2011-03-10 -- 2011-03-16
|
|Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.90.7.20110315.10/ Download]
| [[Release_Engineering/Plans/1.2/1.1.90.7|Details]]
|-
| style="background-color:#99cc00" | 1.1.90.8
| 2011-03-17 -- 2011-03-23
|
|Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.90.8.20110322.2/ Download]
| [[Release_Engineering/Plans/1.2/1.1.90.8|Details]]
|-
| style="background-color:#00ff00" | 1.1.99.0
| 2011-03-24 -- 2011-03-30
|
| |Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.99.0.20110329.5/ Download]
| [[Release_Engineering/Plans/1.2/1.1.99.0|Details]]
|-
| style="background-color:#00ff00" | 1.1.99.1
| 2011-03-31 -- 2011-04-06
|
| |Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.99.1.20110405.3/ Download]
| [[Release_Engineering/Plans/1.2/1.1.99.1|Details]]
|-
| style="background-color:#00ff00" | 1.1.99.2
| 2011-04-07 -- 2011-04-13
|
| |Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.99.2.20110412.6/ Download]
| [[Release_Engineering/Plans/1.2/1.1.99.2|Details]]
|-
| style="background-color:#00ff00" | 1.1.99.3
| 2011-04-14 -- 2011-04-20
|
| |Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.99.3.20110419.9/ Download]
| [[Release_Engineering/Plans/1.2/1.1.99.3|Details]]
|-
| style="background-color:#00ff00" | 1.1.99.4
| 2011-04-21 -- 2011-04-27
| MeeGo 1.2 Initial pre-release image available (4-26)
| Released [http://repo.meego.com/MeeGo/builds/trunk/1.1.99.4.20110426.4/ Download]
| [[Release_Engineering/Plans/1.2/1.1.99.4|Details]]
|-
| style="background-color:#00ff00" | 1.1.99.5
| 2011-04-28 -- 2011-05-04
| MeeGo 1.2 Branching for 1.2 (4-29)
|
| [[Release_Engineering/Plans/1.2/1.1.99.5|Details]]
|-
| style="background-color:#00ff00" | 1.1.99.6
| 2011-05-05 -- 2011-05-11
| MeeGo 1.2 Final release candidate (5-6), MeeGo 1.2 Signed Gold image (5-10)
|
| [[Release_Engineering/Plans/1.2/1.1.99.6|Details]]
|-
| style="background-color:#339966" | 1.1.99.7
| 2011-05-12 -- 2011-05-18
|
|
| [[Release_Engineering/Plans/1.2/1.1.99.7|Details]]
|-
| style="background-color:#339966" | 1.2.0.0
| 2011-05-19 -- 2011-05-25
| MeeGo 1.2 Release Day (5-19)
|
| [[Release_Engineering/Plans/1.2/1.2.0.0|Details]]
|}

== MeeGo 1.2 Features Status ==
{{#bugzilla:
|columns=id,status,to,severity,version,summary
|product=MeeGo Core OS Features,MeeGo Handset Features,MeeGo Netbook Features,MeeGo IVI Features
|version=1.2
|bar=status
|group=product
}}

[http://bugs.meego.com/report.cgi?x_axis_field=bug_status&y_axis_field=component&z_axis_field=product&query_format=report-table&classification=MeeGo+Features&product=MeeGo+Connected+TV+Features&product=MeeGo+Core+OS+Features&product=MeeGo+Handset+Features&product=MeeGo+IVI+Features&product=MeeGo+Netbook+Features&product=MeeGo+Tablet+Features&version=1.2&bug_severity=enhancement&format=table&action=wrap Detailed report in Featurezilla]

== MeeGo 1.2 Bugs Status ==
{{#bugzilla:
|columns=id,status,to,severity,version,summary
|product=MeeGo SDK,OS Base,OS Middleware,Handset User Experience,Netbook User Experience,Netbook IVI Experience
|version=1.2
|bar=status
|group=product
}}

[http://bugs.meego.com/report.cgi?x_axis_field=bug_status&y_axis_field=component&z_axis_field=product&query_format=report-table&classification=MeeGo+Platform&product=Automotive+User+Experience&product=Handset+User+Experience&product=MeeGo+SDK&product=Netbook+User+Experience&product=OS+Base&product=OS+Middleware&version=1.2&format=table&action=wrap Detailed report in Bugzilla]

[[Category:Release engineering]]
[[Category:Meego-1.2]]

Architecture/Documentation

2011-04-27T09:26:43Z

Amigadave: categorise, wikify section headings, wikify links

Here you can find more detailed documentation about MeeGo architecture domains and subsystems. This will contain links to all MeeGo subsystem documents once they are available. It will take time before everything is in place but we will publish documentation as soon as we can.

If you want to edit the architecture documentation discuss it first on the meego-architecture mailing list. We want to have good quality and consistent documentation about the subsystems.

== Domains and Subsystems ==

=== Core OS ===

==== Security ====

* [[Architecture/Documentation/Security/Accounts | Accounts]]
* [[Architecture/Documentation/Security/SSO | Single Sign On]]
* [[Architecture/Documentation/Security/Integrity_Protection_Framework | Integrity Protection Framework]]
* [[Architecture/Documentation/Security/Certificate Manager | Certificate Manager]]
* [[Architecture/Documentation/Security/SW_Distribution_Security | SW Distribution Security]]
* [[Architecture/Documentation/Security/Account_Control_Framework | Account Control Framework]]
* [[Architecture/Documentation/Security/Security_Adaptation |Security Adaptation]]

==== Data Management ====

* [[Architecture/Documentation/Data_Management/Content_Framework | Content Framework]]

==== SW Management ====

* [[Architecture/Documentation/SW_Management/Package_Manager | Package Manager]]

==== System ====

* [[Architecture/Documentation/System/System_Control | System Control]]
* [[Architecture/Documentation/System/Resource_Policy | Resource Policy]]
* [[Architecture/Documentation/System/Startup_Services | Startup Services]]
* [[Architecture/Documentation/System/Context_Framework | Context Framework]]
* [[Architecture/Documentation/System/Sensor_Framework | Sensor Framework]]
* [[Architecture/Documentation/System/Sensor_Adaptation | Sensor Adaptation]]
* [[Architecture/Documentation/System/Device_Mode_Adaptation | Device Mode Adaptation]]
* [[Architecture/Documentation/System/Haptics_and_Vibra_Adaptation | Haptics and Vibra Adaptation]]

==== Location ====

* [[Architecture/Documentation/Location/Location_Framework | Location Framework]]
* [[Architecture/Documentation/Location/Location_Adaptation | Location Adaptation]]

==== Kernel ====

==== PIM ====

* [[Project/mkcal|Calendar Engine]]
* [[Architecture/Documentation/PIM/Contacts_Engine | Contacts Engine]]
* [[Project/Email|Email Engine]]
* [[Buteo|Synchronization Framework]]
* [[Branta|Backup Framework]]
* [[Architecture/Documentation/PIM/OfficeTools | Office Tools]]

==== Multimedia ====

* [[Architecture/Documentation/Multimedia/GStreamer | GStreamer]]
* [[Architecture/Documentation/Multimedia/Pulse_Audio | PulseAudio]]
* [[Architecture/Documentation/Multimedia/Multimedia_upnp | UPnP]]
* [[Architecture/Documentation/Multimedia/Multimedia_Camera_Adaptation | Camera Adaptation]]
* [[Architecture/Documentation/Multimedia/Multimedia_Audio_Adaptation | Audio Adaptation]]
* [[Architecture/Documentation/Multimedia/Multimedia_Imaging_Video_Adaptation | Imaging and Video Adaptation]]

==== Essentials ====

* [[Architecture/Documentation/Essentials/Base_Essentials | Base Essentials]]

==== Communications ====

* [[Architecture/Documentation/Communications/Telephony_IM | Telephony and IM]]
* [[Architecture/Documentation/Communications/Cellular_Framework | Cellular Framework]]
* [[Architecture/Documentation/Communications/ConnMan | ConnMan]]
* [[Architecture/Documentation/Communications/Bluetooth | Bluetooth]]
* [[Architecture/Documentation/Communications/Cellular_Adaptation | Cellular Adaptation]]
* [[Architecture/Documentation/Communications/Connectivity_Adaptation | Connectivity Adaptation]]

==== Qt ====

* [[Architecture/Documentation/Qt/Qt | Qt]]
* [[Architecture/Documentation/Qt/Qt_Mobility | Qt Mobility]]
* [[Architecture/Documentation/Qt/Qt_WebKit | Qt WebKit]]

==== Graphics ====

* [[Architecture/Documentation/Graphics/OpenGLES | OpenGL ES]]
* [[Architecture/Documentation/Graphics/Font_Management | OpenGL ES]]
* [[Architecture/Documentation/Graphics/X11 | X11]]
* [[Architecture/Documentation/Graphics/Input_Adaptation | Input Adaptation]]
* [[Architecture/Documentation/Graphics/Display_Adaptation| Display and Graphics Adaptation]]

=== Handset UX ===

* TBD

== Developer Guides ==

* [[Media:Meego-policy-framework-developer-guide.pdf|MeeGo Policy Framework Developer Guide]]

== Templates ==

* [[Architecture/Documentation/Templates | Templates]]

[[Category:Architecture Documentation]]

MeeGo UX Components Chroot Tutorial

2011-04-26T13:43:25Z

Amigadave: categorise

== Overview ==
This tutorial will take the developer through the process of building from source the [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview|meego-ux-components package]] in a chroot development environment on Linux.

This tutorial is based on the [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview|MeeGo SDK 1.2 Preview (with Tablet)]] release.

This tutorial was created with a specific Tablet Build (04-01-2011) and has specific instructions related to that build. Specifically, a git checkout of a tag is required.

== Prerequisites ==
* Linux Only
* [[SDK/Docs/1.2/MeeGo_SDK_1.2_Preview_for_Linux| MeeGo SDK 1.2]] installed
* [[Developing_in_a_Meego_Environment|Install / Setup mic-chroot]]

== Steps ==

Step 1. Get the latest source of the meego-ux-components
<pre>
cd ~/meego.gitorious
git clone http://git.gitorious.org/meego-ux/meego-ux-components.git
</pre>

Step 2. Download the 4/1 version of the QEMU image:
<pre>
http://download.meego.com/trunk-daily/builds/1.1.90/1.1.99.1.20110401.1/images/meego-tablet-ia32-qemu/
</pre>

Step 3. Un-tar to get the .raw image

Step 4. Make a fs copy of the image:
<pre>
sudo mic-chroot -s ./chroot0405 -v
Downloads/meego-tablet-ia32-qemu-1.1.99.1.20110405.3.img
<exit the chroot>
</pre>

Step 5. mount --bind your source directory to a directory in the fs chroot
<pre>
sudo mount -B /home/dlawlor/meego.gitorious/meego-ux-components
meego-ux-components
</pre>

Step 5. start the chroot
<pre>
sudo mic-chroot ./chroot0401
</pre>

Step 6. Before building the sources, you need to git checkout a version
that will work with the 4/1 tablet image:
<pre>
git checkout 0.2.1
</pre>

Step 7. startmeego to get all the MeeGO services started:
<pre>
startmeego &
## Note - it will be helpful to edit the script
/usr/bin/startmeego-debug-tablet
## Change: Xephyr $DISP -screen 1024x600
## To: Xephyr $DISP -screen 1280x800
</pre>

Step 8. Start Qt Creator (in the mic-chroot terminal)
<pre>
qtcreator &
</pre>

Step 9: Install packages needed to build meego-ux-components
<pre>
zypper in libXdamage-devel
zypper in libXcomposite-devel
zypper in libX11-devel
zypper in kcalcore-devel
zypper in qt-mobility-devel
zypper in libqtopengl-devel
zypper in libcontentaction-devel
zypper in contextkit-devel
zypper in mlite
zypper in libexif-devel
</pre>

Step 10. Build and Install
<pre>
# In Qt Creator: Build->Build All

# from the chroot terminal (Until install / deploy step in Qt Creator is tested)
cd ../meego-ux-components-build-desktop #If shadow build was checked
make install
</pre>

Step 11. Run meego-ux-widgetgallery in a separate window
<pre>
qmlviewer /usr/share/meego-ux-widgetgallery/main.qml
</pre>

Step 12. Run meego-ux-widgetgallery in the Xephyr startmeego window
<pre>
export DISPLAY=:2
qmlviewer /usr/share/meego-ux-widgetgallery/main.qml

Step 13. Run meego-ux-widgetgallery directly from the MeeGo environment
# in the Xephyr Window, hit the Home (Windows) key
# Choose the App Viewer
# Click on Terminal
# run this command in the terminal window:
qmlviewer /usr/share/meego-ux-widgetgallery/main.qml
</pre>

Step 14. You can also copy an existing .desktop file and change the exec
statement to meego-ux-widgetgallery if you want to click on an icon to
start it.

== Todo ==
* Automate the creation / startup of the chroot - in the the above steps, design a script which can perform steps 2 - 5, 7, 9, 14
* Also document how to set up the SDK to run this application on a device.

[[Category:Tutorial]]

Maliit/Ideas/Supporting Non X11 Platforms

2011-04-26T12:30:41Z

Amigadave: categorise, cut toplevel heading

At the moment, the X11 platform is the only platform supported by the Input Method. This page describes the approaches that can be taken to support non-x11 platforms. When we are talking about non-X11 platforms the following feature may be affected:
* Input method's process host
* Self-compositing
* Hardware keyboard mapping
* D-Bus API input context connection

The ideas in this page basically built on using Wayland as the display server.

== Process host ==
For the host of the input method, basically there are two approaches that can be done, depending on the requirements of the system that we want to support, and we want to support both approach and can be easily switch between those.

=== In-process ===
This approach will bring the input method in the same process as the application. The memory consumed by input method is shared with the application. It also affects the startup time of the application.

==== Implementation details ====
* Instantiate the MIMPluginManager inside an input context plugin
* Have a widget to show the plugin UI, replacing the MIMApplication passthrough window
* Some tricks needed so the widget does not steal the focus of the text entry widget (which would cause the input method plugin UI to be hidden).

This approach would be feasible for these use cases:
* QtCreator support: developing Qt application will automatically use MeeGo Input Method when text entry is activated
* Symbian support: overriding Symbian's default input method and use MeeGo Input Method instead in Qt applications (might not work in legacy Avkon applications)
* single process Lighthouse/Wayland: The startup time and memory consumption are no longer relevant here as there would be a single instance of input method in a single process Lighthouse scenario.

===== D-Bus connection =====
When used in-process, even though if the platform supports GLib D-Bus API, there is no point of having the connection using D-Bus API. Here the MInputContext may need to be modified to do direct call to the input method plugin.

=== Out-of-process ===
This approach will still need the presence of compositor or be part of the compositor.

==== Implementation details ====
* Instantiate MIMPluginManager inside a Wayland compositor, preferably a QML based compositor.
* Have an option to use a QML element as the UI host of the plugin so total solution would be QML based widgets.

This approach would be feasible for multiprocess Lighthouse applications setup.

== Hardware keyboard mapping ==
Internally Wayland is still using xkb, but having a dedicated interface to manage the hardware keyboard would make sense.

[[Category:Maliit]]

Buteo/SyncML

2011-04-26T12:15:11Z

Amigadave: categorise

= Introduction =
This wiki document describes the Buteo SyncML stack class design. The SyncML stack was written in C++ and has a Qt like API. This document can be used by any application developer who wants to use the SyncML stack to create SyncML based application. For a complete class description and design, refer to the doxygen documentation

Code: http://meego.gitorious.org/meego-middleware/buteo-syncml/trees/master

= Class Design =
Following is the context diagram of SyncML stack w.r.t the dependencies it has on other components

[[File:SyncML_Dependency.JPG.jpg]]

Here is a list of external libraries SyncML Stack depends on.
* libqt4-dev (>= 4.5) - for Qt Core , Qt Network , Qt Xml Interfaces.
* xml2wbxml-dev - for xml2wbxml conversion
* libsqlite3-dev - for sqlite3 queries in dealing with changelog and other dbs
* libopenobex1-dev – for Obex Communication
* libqt4-sql-sqlite - Need this library for running and loading sqlite3 drivers in arm environment to run unit tests. This is not a direct dependency for compiling the code.
* sqlite3 – Core sqlite3 Library for sqlite3 commands. There is no compilation dependency , but is needed for running unit tests in scratchbox arm environment.

= Functional Description =
SyncML Stack has the following Important Components/Classes in the System.
External Interfaces used/set by the user of the stack.
* SyncAgent
* SyncAgentConfig
* HTTPTransport
* OBEXTransport

Callback Interface Implemented by the user of the Stack
* StoragePlugin

Internal Interfaces ( used internally in the stack)
* SessionHandler
* StorageHandler
* CommandHandler
* SyncMLMessageParser
* ResponseGenerator

The overall class diagram for the stack in the framework is depicted as shown below.

[[File:SyncML_-_class_diagram.png]]

The following Sections describe the functionality and interaction between each of these components in the overall system.

== SyncAgent ==
SyncAgent acts as an external interface to the Stack and is a single point of entry into the Stack. Anyone using the SyncAgent should create it in the run function of a thread, as SyncAgent further creates all the objects necessary as children of SyncAgent. Qt expects both the parent and child of a object in one thread of execution for Signal/slot Mechanism to work.

SyncAgent has the following important API exposed to the components outside the stack. The API is same for both client and server modes of the stack.
PrepareSync
StartSync
PauseSync
ResumeSync
AbortSync
GetLastError
GetLastSyncResults
GetLastSyncState

PrepareSync takes SyncAgentConfig Class as the input parameter and gives the configuration details to all the components of the system. PrepareSync is used to prepare the stack to handle further sync requests and as such this is a pre-requisite call for startSync in both client and server modes. PrepareSync returns a bool to indicate if the command was initiated and user should expect a callback when command has been completed.

StartSync is used to trigger the synchronization in case of client mode and in case of server mode this function triggers the transport to send data to stack for parsing. StartSync triggers the need to send/handle the SyncML requests by the stack.

PauseSync, resumeSync, abortSync are the APIs to control the synchronization process and such do their designated jobs. GetLastError, GetLastSyncResults, GetLastSyncStatus give the user information about the status and results of the last sync done in the stack. All the APIs of the SyncAgent are reentrant and but not thread safe.

== SyncAgentConfig ==
SyncAgentConfig is the class used to configure the sync details like sync url, sync account username, password, local and remote database uri’s, setting the transport ( http/obex ),setting the conflict resolution policy details ,setting operation mode of the stack ( client /server ) , enable or disable the stack logging etc., All other components in the stack use SyncAgentConfig to retrieve information about the present sync process using this object.

It has the following functions to set configuration details related to Sync
setTransport – sets the transport object to be used by the stack
setSyncMode – sets the SyncMode object for stack( slow-sync, two-way–sync ,one-way-sync)
setLocalDevice - set local database uri information
setRemoteDevice - set the remote database uri information
setAuthenticationType – set type of authentication ( no authentication, basic, md5 )
setUsername – set the sync account username to be used for sync
setPassword – set the sync account password to be used for sync
setDatabaseFilePath – set the db file path for storing persistent information
setConflictResolutionPolicy – set the polcify to use in case of conflicts during sync.
setOperationMode – set the client/server operation mode of stack
addSource - used to add more source databases ( like calendar etc.,) to sync.
setProtocolVersion – sets protocol version to operate on. Valid values are DS_1_2, DS_1_1 of SyncML as mentioned in the data structure ProtocolVersion.
setProtocolExtensions – used to set ProtocolExtensions needed as in the case of Sync with Series 60 phones.

In addition to these there are certain utility functions used to configure the logging capabilities of the stack. These are
enableLogging
disableLogging
enableLogLevel
disableLogLevel

The various loglevels that can be enabled are
LogLevel_Debug,
LogLevel_Warning,
LogLevel_Critical,
LogLevel_Fatal,
LogLevel_Info,
LogLevel_Trace,
LogLevel_Protocol

The user of the stack has two options to set the configuration of the stack
* One way is to use the SyncAgentConfig object directly and set the various properties
* The second way is to use the stack configuration file to set the default values for the stack object. The default values in the XML file can be overridden by using the SyncAgentConfig object. A sample XML file is as under
<?xml version="1.0" encoding="UTF-8"?>
<meego-syncml-conf xmlns="http://meego.org/meego-syncml-conf">
<dbpath>syncml.db</dbpath>
<local-device-name>MeegoDevice</local-device-name>
<agent-props>
<max-message-size>16384</max-message-size>
<max-changes-per-message>22</max-changes-per-message>
<conflict-resolution-policy>0</conflict-resolution-policy>
</agent-props>
<transport-props>
<bt-obex-mtu>1024</bt-obex-mtu>
<usb-obex-mtu>1024</usb-obex-mtu>
<http-number-of-resend-attempts>3</http-number-of-resend-attempts>
</transport-props>
</meego-syncml-conf>

== HTTPTransport ==
This is the transport Object that the user of the stack has to create and set in SyncAgentConfig. Stack uses this object to communicate to the remote end using http/https protocol as specified by the RemoteLocUri of this object.

Important public API in this object are
setRemoteLocURI – use to set the remote sync uri
setProxyConfig – use to set the proxy configuration
setWbXml – use to set the content type to WbXML

== OBEXTransport ==
This object needs to be set in case of communication over OBEX is preferred. OBEX connection can be established using BT address and service UID, or in the case of existing connection, using a file descriptor. Currently only OBEX over BT is supported. OBEX over USB is planned but not implemented at this time.

== StoragePlugin ==
StoragePlugin is a callback interface to the storageplugins of the framework for adding, removing a SyncItem (like an email or bookmark), and read or write data to it. The actual writing of data to an item is done via the SyncItem class methods.
Important Public API provided by the StoragePlugin class are :
generateSyncItem – used to generate an empty Sync Item
getSyncItem – used to get the SyncItem from the StoragePlugin
commitSyncItem – called after generateSyncItem to write the actual data
removeSyncItem – used to delete the SyncItem from the StoragePlugin
getAll – used to get all SyncItems from the StoragePlugin
getNew – used to get SyncItems created after specified timestamp
getModified – used to get SyncItems modified after specified timestamps

== SessionHandler ==
Session Handler is the most important class in the entire stack that co-ordinates activities between different components,delegates tasks to other components, maintains the state machine for the stack in both client and server mode. It interacts with transport to get and send data over the transport. It connects Transport and SyncMLMessageParser to handle incoming data. It co-ordinates between Transport and ResponseGenerator to send outgoing data. Whenever it receives signals from the Parser, it delegates the task of handling the SyncML Commands that are not related to SyncML session to Command Handler.

The high level logic of sending data to remote location has been divided between Session Handler and Response Generator. Based on current state of the synchronization session, Session Handler determines what needs to be sent to server. It uses Packages to form the response needed for a request made from remote side.
Packages are logical entities that comprise of data to be sent. A Package is a distinct part of SyncML message that handles dividing data into multiple messages by tracking the size of data inserted into SyncML message before being sent. Package tracks the state of the data sent and splits itself into multiple messages if the size of the message is more than that is supported by the remote device.
Packages generate SyncML XML documents by utilizing SyncMLCmdObjects. SyncMLCmdObjects are able to transform their data contents to XML. SyncMLCmdObjects are also able to form hierarchies and such represent the base objects needed for SyncML protocol information exchange.

SessionHandler in its hierarchy has two forms depending on the present Operating Mode. If the Operating Mode is client, specific jobs needed in this mode are handled by Client Session Handler. For example, initiating the sync process, forming init message and sending it across. If the Operating Mode is server, specific jobs needed in this mode are handled by Server Session Handler. For example, Server specific functionality like server state information, alert command handling etc., is taken care by this Class. Base class Session Handler takes care of all the functionality common between client and server like, reading the response of the requests made and delegating the task of understanding commands to command handler.

SessionHandler has the following important API.
* prepareSync - this is a function in that is common for both server and client. It handles preparation of synchronization session.
* startSync - this is a pure virtual function in baseclass and has its own functionality in client and server modes. In Client Mode , this function initiates the Sync for client intiated sync and in server initiated sync waits for the data to be read from the transport. In Server Mode , this function initiates the sync request for server initiated sync and waits for the data from transport in case of client initiated sync.
* sendNextMessage - this API uses Response Generator to send the next Message based on the packages available in the current package Queue. Sending functionality is same for both client and server modes.
* composeLocalChangesPackage - populates package queue with packages that together compose the local changes
* saveSession – Saves the complete Session Information , like Changes to Changelog file , Mapping Table , Anchors etc.,
* validateConfiguration – Validates the SyncAgentConfig Object for Valid Values.
* finishSync – Final step in the sync process. Called when we have no more activities to do in the sync. This function emits a signal to indicate that all the data from the corresponding message for Sync has been read from the transport and the resources specific to the transport for that message can be freed.
Other Tasks related to Session Handler are implemented using Signal/Slot Mechanism of Qt. For Complete List of Functions in Session Handler Please refer to API documentation

== StorageHandler ==
Storage Handler takes care of retrieving/adding/deleting/modifying items in storages. This class provides the API like interface for several storageplugins supported.
StorageHandler has the following important API used by the SessionHandler
itemBegin – to begin building an item
itemAddData – to add data to item being built
itemReject – to reject the item that was built
itemFinalize – to commit the item was built

== CommandHandler ==
Command Handler Class takes care of handling several SyncML Commands like addItem , delete Item , Replace Item , Put , Get etc., Situations specific to client and server are handled in respective derived classes.
Important API in command handler:
handleSync – handles the SyncML command Sync
handlePut – handles the SyncML command Put
handleGet – handles the SyncML command Get
handleStatus – handles the SyncML command Status
handleMap – handles the SyncML command Map
For Information on Other API please refer to the API documentation

== ResponseGenerator ==
ResponseGenerator generates the actual syncml message to be sent to the remote side. Actual sending of requests is done by SessionHandler. ResponseGenerator uses the Packages to Generate the Messages needed to be sent to the other end.
Important API in Response Generator:
generateNextMessage – Generates a new SyncMLMessage based on package queue
addPackage – adds a package to the package queue
addStatus – adds a Status to the package queue
clearPackageQueue – clears the package queue

== SyncMLMessageParser ==
SyncMLMessageParser is responsible for processing responses received from remote side. It reads data in the slot connected to Transport and parses the incoming xml to several data structures and emits signals with these structures filled with necessary information. This Class Inherits from QXmlStreamReader and adds parsing functionality specific to SyncML. Important Commands of the SyncML Specification that are relevant to Sync’ing with 1.1. and 1.2 protocol support are parsed and the data structures corresponding to individual elements are populated.
Important API :
parseResponse – this is the slot connected to readData signal of Transport by SessionHandler.
There are several other parsing API that parse the header , body , and further elements in the XML formatted message based on the current tokenType() pointed by the QXmlStreamReader. These are private to the class and more information about them can be obtained from API documentation.

== Other Classes ==
LocalChangesPackage - Derived Class of Package Class that takes care of generating the Package Containing Local Changes to be sent to the remote side for Sync.
LocalMappingsPackage – Derived Class of Package Class that takes care of Sending the Mappings to Server after receiving items from the remote side.
AlertPackage – Derived Class of Package Class that has Alert Parameters set for sending a SyncML Message Containing Alert Command.
AuthenticationPackage - Derived Class of Package Class that fills authentication information to SyncML Message header
SyncItem – Used by StoragePlugin to describe One SyncItem. A SyncItem can be a contact entry or a calendar entry depending upon the StoragePlugin
SyncItemBuilder – Fills up the Data for the SyncItem , based on the data received from the remote side.
SycnElements folder – several Classes in syncelements folder that made up individual commands like Add , Alert , Body , Cred , Delete , DevInf ,SyncHdr ,Map , MapItem, Item , Meta,Put , Replace , Results , Status , Sync , and Messages Containing Multiple Commands like , LocalChanges , LocalChange, SyncMLMessage.

= Sequence Diagrams =

== Receiving Sync Command for adding an item from Remote End ==

[[File:Add_Remote_Item.jpg]]

== Sending Message ==

[[File:Sending_Message.jpg]]

== Server Flow - Handling First Request ==

[[File:Server_Flow_-_Handling_First_Request.jpg]]

== Server Flow for Client Changes without mapping ==

[[File:Server_Flow_for_Client_Changes_without_mapping.jpg]]

== Server Flow for Client Changes flow with mapping ==

[[File:Server_Flow_for_Client_Changes_flow_with_mapping.jpg]]

== Session Creation ==

[[File:Session_Creation.jpg]]

== Sending Items ==

[[File:Sending_Items.jpg]]

= State Machine =
The below diagram depicts the client state machine inside the syncml stack. The several terms used in the state machine are explained in the table below.

== Client State Machine ==

[[File:Client_State_Machine.jpg]]

== Server State Machine ==

[[File:Server_State_Machine.jpg]]

== Sync States ==
{| class="wikitable" border="1" cellpadding="5" cellspacing="0"
|-
! State
! Description
|-
|UNPREPARED
|When a new instance of SyncAgent is created, it is in UNPREPARED state. This means that it is not yet ready for operations as it has not been prepared by passing a proper SyncAgentConfig object to it using prepareSync() method.
|-
|PREPARED
|When a proper SyncAgentConfig object has been passed to SyncAgent, SyncAgent moves to prepared state. At this point, SyncAgent is ready perform start and resume operations.
|-
|LOCAL_INIT
|When SyncAgent is in LOCAL_INIT state, it is performing SyncML initialization phase. This phase includes authentication, exchange of device information sync mode negotiations.
|-
|REMOTE_INIT
|When SyncAgent is in LOCAL_INIT state, it is receiving handshaking information from remote side about SyncML initialization phase
|-
|SENDING_ITEMS
|When SyncAgent is in SENDING_ITEMS state, it is sending detected changes in local databases to remote side.
|-
|RECEIVING_ITEMS
|When SyncAgent is in RECEIVING_ITEMS state, it is receiving changes detected by remote side.
|-
|SENDING_MAPPINGS
|When SyncAgent is in SENDING_MAPPINGS state, it is sending server the local UID mappings of the changes received . Note that when sync direction is client-only, this state never occurs as mappings never need to be sent. In this case, SyncAgent state moves directly from RECEIVING_ITEMS to FINALIZING
|-
|RECEIVING_MAPPINGS
|When SyncAgent is in RECEIVING_MAPPINGS state, it is receiving the remote UID mappings of the changes sent to remote side.
|-
|FINALIZING
|When SyncAgent is in FINALIZING state, it is waiting for map acknowledgement package from remote side. After this package has been received, SyncAgent will finalize sync session by storing sync anchors.
|-
|SYNC_FINISHED
|When SyncAgent is in SYNC_FINISHED state, initiated sync session has completed successfully.
|-
|}

== Sync Error States ==
{| class="wikitable" border="1" cellpadding="5" cellspacing="0"
|-
! Error
! Description
|-
|INVALID_CONFIGURATION
|SyncAgentConfig object passed SyncAgent is invalid, for example it might not have proper TransportConnectionData object or it has no sync targets specified.
|-
|INTERNAL_ERROR
|Internal error has occurred during processing of operation.
|-
|ABORTED
|Sync session was aborted by user or due to fatal error received in protocol response.
|-
|SUSPENDING
|User has called suspendSync() method and SyncAgent is currenly negotiating with server about suspending the session.
|-
|SUSPENDED
|SyncAgent has finished suspending the session.
|-
|CONNECTION_ERROR
|Transport layer has lost connection to remote side during session.
|-
|INVALID_SYNCML_MESSAGE
|Received response could not be parsed as the response was empty or contained invalid or unrecognized data.
|-
|}

[[Category:Buteo]]

Buteo/SyncFWClient

2011-04-26T12:13:57Z

Amigadave: categorise

== Synchronization Framework Client ==

For reference headers, please see [http://meego.gitorious.org/meego-middleware/buteo-syncfw/blobs/master/libsyncfwclient/SyncClientInterface.h SyncClientInterface.h] and [http://meego.gitorious.org/meego-middleware/buteo-syncfw/blobs/master/libsyncprofile/Profile.h Profile.h]

Create a new SyncClientInterface:

sci = new SyncClientInterface();

Connect relevant signals (notification about sync progress and completion):

connect(sci, SIGNAL(syncStatus(QString,int,QString,int)), this, SLOT(slotSyncStatus(QString,int,QString,int)));
connect(sci, SIGNAL(profileChanged(QString,int,Buteo::SyncProfile)), this, SLOT(profileChanged(QString,int,Buteo::SyncProfile)));
connect(sci, SIGNAL(resultsAvailable(QString,Buteo::SyncResults)), this, SLOT(resultsAvailable(QString,Buteo::SyncResults)));
connect(sci, SIGNAL(transferProgress(QString,int,int,QString)), this, SLOT(slotTransferProgress(QString,int,int,QString)));

To load a profile one approach is to use a premade XML-file containing the settings:

QString file = "testsync-scheduleworld.xml";
QString profile = "scheduleworld";
QDomElement root = loadProfileFromXML(file);

Where loadProfileFromXML is implemented as:

QDomDocument doc("profile");
QFile file(fileName);
doc.setContent(&file);
file.close();
QDomElement root = doc.documentElement();
return root;

Create a SyncProfile (which can then be modified to update settings etc):

SyncProfile syncProfile(root);

'''Note that this is not the recommended approach.''' Clients should ask the framework for profiles that were added to the framework. TODO: add example for that part of the API.

Change a setting for the profile:

syncProfile.setKey("Username", “myusername”);
syncProfile.setKey("Password", “mypassword”);

Add the profile, and start the sync:

sci->addProfile(syncProfile);
sci->startSync(profile);

To get a list of the running syncs:

QStringList lst = sci->getRunningSyncList();
qDebug() << "Running syncs:" << lst.length();
for(int i = 0; i < lst.length(); i++) {
qDebug() << "Running" << i << ":" << lst.at(i);
}

== Slots ==

For up to date information regarding the meaning of different status code, see [http://meego.gitorious.org/meego-middleware/buteo-syncfw/blobs/master/libsyncfwclient/SyncClientInterface.h SyncClientInterface.h].

void SyncHandler::slotSyncStatus(QString aProfileId, int aStatus, QString aMessage, int aErrorCode)
{
QString stat = "";
if (aStatus == 0) {
stat = "QUEUED";
} else if (aStatus == 1) {
stat = "RUNNING";
} else if (aStatus == 2) {
stat = "PROGRESSING";
} else if (aStatus == 3) {
stat = "ERROR";
emit syncDone(-3);
} else if (aStatus == 4) {
stat = "DONE";
} else if (aStatus == 5) {
stat = "ABORTED";
}
qDebug() << "STATUS CHANGE:" << aProfileId << stat << aMessage << aErrorCode;
}
void SyncHandler::profileChanged(QString aProfileId, int aChangeType, Buteo::SyncProfile aProfile)
{
qDebug() << "Profile changed:" << aProfileId << aChangeType;
}
void SyncHandler::resultsAvailable(QString aProfileId, Buteo::SyncResults aResults)
{
qDebug() << "Results available" << aProfileId << aResults.resultCode();
if (aResults.resultCode() == Buteo::SyncResults::SYNC_RESULT_SUCCESS) {
// Do something nice when we succeed
} else if (aResults.resultCode() == Buteo::SyncResults::SYNC_RESULT_FAILED) {
// Do something nice when there is a failure
}
}
void SyncHandler::slotTransferProgress(QString aProfileId, int aTransferDatabase, int aTransferType, QString aMimeType)
{
qDebug() << "Progress:" << aProfileId << aTransferDatabase << aTransferType << aMimeType;
}

== Sample XML files for Scheduleworld ==

scheduleworld.com.xml (goes to /etc/sync/profiles/service/):
<?xml version="1.0" encoding="UTF-8"?>
<profile name="scheduleworld" type="service">
<key name="Remote database" value="http://sync.scheduleworld.com/funambol/ds" />

<key name="http_proxy_host" value="" />
<key name="http_proxy_port" value="" />

<key name="destinationtype" value="online"/>

<profile name="syncml" type="client" >
<key name="use_wbxml" value="false" />
<key name="Sync Transport" value="HTTP" />
<key name="Sync Direction" value="two-way" />
<key name="Sync Protocol" value="SyncML12" />
</profile>
<profile name="hcontacts" type="storage" >
<key name="Local URI" value="./contacts" />
<key name="Target URI" value="./card" />
</profile>
</profile>

scheduleworld.xml (goes to /etc/sync/profiles/sync/):

<?xml version="1.0" encoding="UTF-8"?>
<profile name="scheduleworld" type="sync" >
<key name="displayname" value="scheduleworld" />
<key name="enabled" value="true" />
<key name="use_accounts" value="false" />
<key name="hidden" value="false" />
<profile type="service" name="scheduleworld.com" >
</profile>
<profile name="hcontacts" type="storage" >
<key name="enabled" value="true" />
</profile>
</profile>

[[Category:Buteo]]

Buteo/MTP

2011-04-26T12:13:25Z

Amigadave: categorise

= Introduction =
The MTP applications provides the functionality of file exploration from a PC that supports the initiator role of MTP. The purpose of this wiki document is to provide the design details of the MTP stack implementation and the MTP application. The MTP application uses the stack and provides Maemo specific MTP functionality.
The MTP stack provides the implementation of the standard Media Transfer Protocol (http://www.usb.org/developers/devclass_docs/MTP_1.0.zip). It uses the MTP driver which provides a combined interface for OBEX, SyncML, MTP functionality. So a Buteo Sync framework can load three plug-ins that could handle each of these interfaces at the same time. The stack is not completely backward compatible with PTP.

The MTP application does not have a UI and so does not use any MeeGoTouchUI components. The MTP application is integrated into the Synchronization framework and is provided as a client plugin (Note: currently it is a server plug-in, but this going to be changed very soon). The main reason for integrating the MTP application to the Synchronization framework is for the synchronization daemon to start the MTP application when the user connects the device to the PC. Details of the MTP integration into the Synchronization framework are provided in the following sections. Figure 1 shows the structural view of the MTP application.

[[File:MTP_Engine_Structural_View.jpg]]

The MTP application is a plug-in for the Synchronization framework and is loaded as a loadable module in a separate thread. It uses the MTP stack library for MTP protocol functionality. The Content Framework is used to retrieve information about the media files and the Context Framework is used to fetch the device specific information like battery level, device state etc. Even though DRM is listed in the diagram, only abstract interfaces for DRM are provided. No implementation is available. Once a DRM solution is chosen for MeeGo, it could be implemented. Once the files are copied to the device, tracker automatically reaps the meta-data information from the file. But not all meta-data is embedded in the file. For such cases, MTP application write the extra meta-data information to the tracker.

= Usecases =
Following is the usecase diagram of MTP

[[File:MTP_Application_Usecase_Diagram.jpg]]

The main usecases of MTP application is to synchronize media files between Nokia Music Application and the device. Theoretically, it should be possible to use the MTP application with any PC application that supports MTP1.0 specification

= MTP Stack Design =
As per the MTP specification, Initiator is the entity like PC based application that sends commands to the Responder, which is a MTP service running in a hand-held device. The MeeGo device is going to be an responder (USB slave) and the PC application would be a initiator (USB master)

The MTP specification broadly constitutes the following entities:
* Operations
* Events
* Objects
* Device Information
* Object Formats

MTP follows a operator-data-response model for all the communications. Operations are MTP operations initiated by the Initiator from the PC. Some examples of operations are, GetDeviceInfo, GetObjectHandles.
Events indicate a change in a specific property of the device to be notified to the responder. An event is just a notification and does not contain the actual data. The responder is responsible for retrieving the data after receiving the event notification.
Objects are any kind of objects in the responder’s device. Each object is associated with meta-data information that the initiator fetches to display the object information in the Initiator UI. For example, Nokia Music Application fetches the objects meta-data and displays the filenames and the file type information in the NMM UI. Apart from files, objects can also be other mime types, like iCal, vCal or vCard files. Synchronization of Calendar and Contacts mime-types is not in the scope of the the MTP stack.
MTP specification supports some specific formats that the initiators and the responder’s can choose to support. The various formats are listed in the MTP specification [MTP_SPEC_1.0].

The directory structure of MTP stack is as below:

[[File:MTP_Stack_Diagram.jpg]]

The Core directory will have the basic MTP operations, events and objects handling. The common directory will have the common utility functions. All the MTP core functionality, like Operations, Events and Objects are maintained in the core directory. The transport specific functionality is maintained in the transport directory, which in-turn has directories for the specific transport (like bluetooth for Bluetooth and usb for USB transports). The transport directory itself will have the transport related generic and abstract functionality. The common directory has the common utility functions. The platform directory has functionality that is specific to the implementation platform. This directory has an abstract interface to the target platform and the specific platform implementations are provided in the subdirectories. Multiple platforms will have similar set of directories. It is possible to have a platform specific directory under ‘platforms’ directory, but since currently, the current target is MeeGo, this level is not required.

= MTP Stack Features =

Almost all the major features of the MTP stack are implemented and supported. A list of non-supported features are listed below:
[TBD]

= MTP Sequence Diagram =
Following figure depicts the sequence flow diagram of MTP

[[File:MTP_Server_engine_Sequence_Diagram.jpg]]

The MTP application is invoked only on demand. The MTP application is implemented as a plug-in in the Buteo Synchronization Framework. The main reason for implementing the MTP application as a plug-in is for the synchronization daemon to load the MTP application whenever the user connects the device to the PC using the USB cable. This ensures that it is not required to run the MTP application continuously. Following is an explanation of the sequence of steps, w.r.t above figure (note that the sequence number below might not exactly match with the sequence number in the figure, but is quite close):
1.The user connects the device with the PC using the USB cable. One of the features of the Synchronization application is not to display to the user multiple options for selecting the “Ovi Suite” mode and “MTP” mode. This ensures that the user need not manually change the modes during synchronization of PIM data (using SyncML plug-in) and synchronization of media file (using MTP plug-in). In order to achieve this functionality, a separate USB MTP driver has been implemented. Since the SyncML plug-in and the MTP plug-in will be running in separate threads of the Synchronization daemon, it is possible to handle parallel synchronizations.
2.Once the USB is connected, the ke-recv (or HAL) receives a notification that sends a signal to the synchronization daemon. Since it is possible that the user can synchronize PIM data or Media data, a USB connection is taken for both the interfaces. In the current implementation, separate USB character devices are created for each kind of interface, like ‘/dev/ttyGS1’ for OBEX interface, ‘/dev/ttyGS2’ for SYNCML interface and ‘/dev/mtp0’ for MTP interface.
3.The Synchronization daemon on receiving the signal from ke-recv, launches the SyncML engine and the MTP engine in two separate threads.
4.The MTP engine opens the character device (using the standard Linux file operations).
a.Note: At this stage, the MTP engine populates an internal cache of object handles of all the objects in the media repository. The information about the object handles is created by reading the information from Content Framework. Populating the objects at this stage is a matter of performance against the memory consumption. More information about the object size and the process CPU usage is discussed under the Performance section.
5.At this stage, typically the initiator issues an GetDeviceInfo operation to fetch the device specific information. A list of device specific properties along with the API used to fetch the device information. In the device info response, the MTP engine also sends information about all the operations that are supported by the device (see MTP Stack Features).
6.Based on the operation list that the initiator received in step 5 above, the initiator may choose to invoke any of the supported operations. If a GetObjects operation is invoked, then all the objects created in step 4.a above are returned to the initiator. Also the initiator may choose to synchronize media files, transfer files from/to PC/device.
7.If a media file is protected by DRM (information obtained from the DRM property of the MTP object), then the MTP engine reads the license information from the media file, uses the Maemo DRM engine API to store the license to the license store. The actual responsibility of decrypting the media file using the stored license rests with the media player. Note that if a DRM protected media file is transferred from device to PC, then the license itself is not transferred to the PC. Rather the media file has a DRM URI in its meta-data information, which the PC software uses to retrieve the license from the network.
8.Once the device is disconnected from the PC, the ke-recv daemon sends a signal again to the Synchronization daemon, which will inturn send a signal to MTP engine. The MTP engine will then do the necessary cleanup operations (releasing the USB connection being one of them) and finally sends a signal to daemon.
9.The daemon will then unload the MTP engine. Note that there are no UI operations involved in this process

= Configurability =
The device information is configurable by adding new codec types and new support for media content. Refer to the deviceinfo.xml file in the code (http://meego.gitorious.org/meego-middleware/buteo-mtp/blobs/master/mts/deviceinfo.xml)

= Packages =
The main components of the MTP application include the MTP stack library (libmeegomtp) and the MTP plug-in itself.
* libmaemomtp
* libmaemomtp-dev
* libmaemomtp-doc
* libmaemomtp-dbg

[[Category:Buteo]]

Buteo/Framework

2011-04-26T12:13:04Z

Amigadave: categorise

= Introduction =
Personal computing, cloud computing and mobile computing have increasingly made users to store their personal data in personal computers, Internet based cloud services and mobile devices. The kind of personal data varies from normal text files to a varied range of media data like pictures (JPEG, GIF, etc.), music files (mp3, wav, etc.), movie files (wmv, mp4, etc.), data file (.doc, .ppt, .pdf etc.) and non-file formats like vcard (format for contact card), vcal (format for calendar entry) which has contacts and Calendar information. As the data gets more and more distributed, it become the more important to keep the data in sync among the various computing entities.Various protocols(SyncML, MTP, REST etc.) have evolved to keep the user data in sync among the entities.

These various protocols work over different kinds of transports (like Bluetooth, USB, IP etc.). So it is no more enough that a particular mobile device supports only a single protocol to keep the user data in sync. It also so happens that two different protocols are also used to synchronize the same kind of data (for example, SyncML and REST API can be used to synchronize Calendar data). The choice of the protocol to use largely depends on the kind of target service from where the data is fetched. Also, the device UI has to provide a coherent view to the end-user without having to expose the internal protocols being used to keep the user data in sync. In order to handle the various synchronization protocols, it is important to have a framework that dynamically chooses the protocol to use for a particular sync session and also provide various kinds of platform based services to the sync session. The Buteo Synchronization Framework tries to create a unified architecture for any kind of synchronization protocol and also enables application developers to create a unified user interface to merge all the synchronization services in the device (here the device can be a PC, mobile device or any other computing device).

The Buteo SyncFW does not provide any synchronization capabilities by itself. It is only the plug-ins and the corresponding protocol stacks that provide the synchronization capabilities.

Note: The name '''''Buteo''''' is the Latin name for a Hawk (more from here: http://en.wikipedia.org/wiki/Buteo)

= Requirements =
Following diagram shows the end-user usecases for Buteo Sync solution.

[[File:Buteo_Sync_Solution_-_End_User_Usecases.jpg]]

The high level end-application use-cases are taking into consideration while creating the architecture
* Supporting synchronization of data between mobile devices
* Synchronization of data between mobile devices and PC
* Synchronization of data between mobile device and the cloud based services. The cloud based services are any internet based online services

The main usecases are to allow a 3'rd party synchronization application developer to create synchronization services and deploy to the framework and to provide various other features like deploy/undeploy synchronization plug-ins, develop storage plug-ins for already existing synchronization services etc.

== Functional Requirements ==
* The solution should provide a d-bus API for on device application to interact and use the framework features and properties
* The framework should provide the end-user a means to initiate, abort, suspend/resume, getting status and logs of synchronization. These API methods would end up in the GUI functionality for the end-user
* As a user of the solution, it should allow me to deploy a synchronization service on the fly
* As a user of the solution, it should allow me to remove an already deployed synchronization service. Even after remvoal of all the deployed services, there should not be any affect in the working nature of the computing device
* It should allow integration to the platform databases as pluggable components, so that support for the synchronization of databases can be added and removed on the fly
* There should be a facility to schedule sychronization sessions. Scheduling is used as an automated mechanism to initiate synchronization with online services at periodic intervals of time without the end-user intervention
* It should be possible to run multiple synchronization sessions in parallel
* If it is not possible to run multiple synchronization sessions, then the requests should be queued and the requests should be executed in the order of the queued requests
* There should be a mechanism to activate/de-activate synchronization based on the context. The context mainly is related to network availability, in which case, synchronization should be intiated when the network is enabled and available and should be disabled and scheduled for later incase the network is not available
* In low battery conditions, synchronization should be disabled and should be rescheduled for a later session
* It should be possible to backup the configuration files of the framework and restore it another machine/device. This requirement needs to be considered carefully, as it cannot be satisfied to the fullest extent
* The framework should support synchronization with transport requirements for network based, PC based and device-device synchronization. The PC based synchronization could use sort range connectivity solutions like USB and Bluetooth
* The architecture should support any kind of data and also different kinds of data. For example, it should support Contacts in Vcard format, but it should also be able to support Vcard versions 2.0, 2.1 and 3.0
* Optional: should support "Push Based Sync"
* Optional: Should support changed based synchronization

== Performance Requirements ==
* There should not be a theoritical limit on the number of synchronization services that the framework can support. But practically this could be limited by the resources available on the target device
* Usage of the network resources on a device at random intervals of time could increase the number of times the processor is woken up, because of which the use-time of the battery could reduce drastically. For this reason, the framework should optimize the usage of the network through some mechanism available in the device

== Non-Functional Requirements ==
* The solution should be generic in nature and should not be tied to or depend on any synchronization protocol
* The solution should be as much portal as possible across all Linux distributions (GNOME, KDE etc.)
* The framework should provide backward compatibility so as to allow any synchronization services that are deployed with an older API
* The solution should provide a simple API for 3'rd party developers
* The framework should be implemented in a transport independent manner
* It should be possible to change the end-user graphical user interface without the need to change the core engine. The architecture should be extensible and scalable for any kind of data to be synchronized and for any kind of protocol

Following diagram depicts some more usecases of the framework

[[File::ButeoFW_Usecase_Diagram.jpg]]

= Architecture Details =
The Buteo Synchronization framework architecture is created taking into consideration the extensibility and scalability of the solution for current and future use cases. Effort is made to make use of the existing components as mush as possible.

== Framework Components ==
=== Plug-in Manager ===
A plug-in based architecture is the logical choice to satisfy the requirement of the ability to deploy/undeploy sync services in the device. The plug-in manager forms the core concept of the Buteo SyncFW. Even though the component is named as plug-in manager, the component does not perform any handling of the plug-ins itself. It is the sync daemon that performs the actual functionality of loading/unloading of the plugins. These plugins could also be called as sync agents, since they handle the sync sessions by using the corresponding sync protocols.

In the synchronization world, typically, there are two kinds of sync services - one that acts as a client and initiates a sync towards a sync server; the typical scenario is where a device sync’s PIM data with an online service (like Ovi.com) and another that acts as a sync server that accepts incoming sync requests or one which has to have a persistent connection towards a sync service. In order to satisfy these two kinds of modes, two kinds of plug-ins are designed. One is a '''''Client Plugin''''' and another is a '''''Server Plugin'''''. A client plugin is loaded on demand either by a GUI application or through a scheduled sync session and is unloaded once is sync is completed. On the other hand, a server plugin is always loaded for accepting incoming sync requests and is never unloaded. In terms of interface methods, the only difference between these plugins would be a “listen” method, which the server plug-in would have. The client/server role decision is made at the time of writing of the plugin and is defined the plugin configuration file. Since the Buteo SyncFW is a generic architecture for MeeGo platform, which is not just targetted for mobile devices, the server functionality could as well be used for a netbook kind of usecase, where the sync service in the netbook acts as a server and the Buteo SyncFW acts as a client.

Another plugin that is defined is the '''''storage plugin'''''. Typically every sync service would involve synchronization of different kinds of user data, the formats of which are profoundly different. A sync protocol like OMA DS SyncML would be able to synchronize different kinds of data with different formats, which would mean that the framework should be able to handle synchronization of these different kinds of data formats. The concept of “Storage Plugin” is created to cater to this kind of usecases. Backend storage is defined as a component in the platform that holds the user personal data. Some examples are Contacts, Calendar, SMS, MMS, music files, audio files, photos etc. Storage plug-in would be loaded along with the corresponding client or server plug-in. The decision of which storage plug-in to load is made based on the profile information of the deployed service and also the protocol request for the storage. More information about a profile is described in the following sections. This kind of plug-in based mechanism for storage provides a scalable architecture where it is possible to provide many storage plug-ins for the same kind of backend storage. The following figure describes the context of the plugins and the plugin manager.

[[File:Buteo_FW_-_Plugin_Manager.jpg]]

The main functionality of storage plug-in would be to obtain the raw data in the protocol message and perform a transformation of the data to the format suitable for the backend storage in the device. For example a SyncML message would provide the Contact information in the form of a vcard, while the storage in the device could be in the form of a SQLite database with an API layer. In this case, the storage plug-in would obtain the vcard from the protocol, use the API layer over the Contacts database and store the vcard entry to the database. A reverse mechanism would be used to retrieve the vcard from the storage and return it to the target sync entity.

Apart from the implementation interfaces, a plugin should also have a configuration file that defines the properties of the plugin, like, whether the plug-in should be visible or hidden to the user, the storage plugins that client/server plugin should use, the target service address, like the ovi sync URL etc. The plugin configuration file has only static information, which is read by the synchronization daemon and used accordingly. The configuration file could also provide extensions, which could specifically be used by the plug-in, but not the framework.

=== Profile Manager ===
Profile Management is quite important both from managing the deployed plug-ins as well as holds the information to be displayed to the end-user. From the end-user point of view, a profile is defined as something that provides information about the synchronization service that the user has synchronized with. A profile has only dynamic information that is created using the plug-in configuration and other information that is generated after a sync has been initiated. For example, if the user has synchronized his data with Ovi.com, then a profile entry would be created with information like the databases the sync session was initiated, time of sync, sync status etc. A profile is also used to display the sync status in a user-friendly manner in a GUI application.

The profile information is stored persistently, so that it could be used across sync sessions and also be available for any GUI application to query the sync status. The profile is the only object that moves across all the synchronization entities (daemon, GUI’s etc.). Some of the properties of a profile can be modified by the user and some properties are only modifiable by the framework. Some of the identified properties of a profile manager are as under:

* Profile ID - a unique identifier generated by the framework using some of the fields of a profile that uniquely identify a profile (like profile name, target address etc.)
* Profile name - is the name of the profile (need not be unique)
* Transport type - the transport type used for the profile (USB/BT/HTTP/HTTPS/TCP). Note that a transport type can also be a combination of two transports. For example, when synchronizing with PC Suite, it is possible to use both BT and/or USB to synchronize with PC Suite
* Sync Content - the databases that this profile is used to synchronize (like Contacts, Calendar, Notes, Music etc.)
* Sync direction - the direction of synchronization (1-way send, 1-way receive, 2-way sync)
* Synchronization status - the status that identi#es the last synchronization status. This inturn will have the following entities:
* Last sync status (success/failed/cancelled)
* Last sync time
* Last sync log (sync item count)
* Credentials - the username/password, if any used for synchronization with the service. These items are expected to be returned from Accounts application
* Synchronization type - a flag to represent manual/automatic synchronization. When manual sync is set, the user has to manually initiate the sync. Incase of automatic sync, the framework will initiate sync as per the automatic sync frequency
* Sync frequency - the frequency at which synchronization should happen (incase of automatic sync)

=== Scheduler ===
Another important component of Buteo SyncFW is the synchronization scheduler. The Scheduler is responsible for scheduling synchronization sessions and also for handling parallel synchronizations. It has a queue mechanism to queue the incoming sync requests. The periodic scheduling of the Sync sessions is handled by using an alarm kind of functionality. The frequency is set by the end-user through a well-known GUI interface. The frequency is defined as a repeat event like everyday, a particular day every week, the hour setting etc. This event is converted to an alarm event and the alarm is triggered whenever the timer expired.

[[File:Buteo_SyncFW_-_Sync_Scheduler.jpg]]

One of the main properties of a sync protocol is to provide data consistency. Even though the backend datastores may provide data consistency through database ACID properties simultaneous synchronization sessions might result in inconsistent results in the end-user data. For example, if sync session1 adds 10 data elements, and a simultaneous sync session2 might result in the addition of the same set of data from a different source, resulting in duplication of data. The framework provides a functionality, wherein simultaneous sync requests that access the same backend datastore are queued and are executed in the first-in-first-out order. In the above example, the two sync sessions are queued and are executed one-after-the-other. More details on how this is achieved is explained in the low-level design.

=== Accounts Integration ===
Accounts&SSO (http://wiki.meego.com/Single_sign-on) is a component in MeeGo platform that provides a one-stop shop for the end-users to configure online accounts. Examples of online acconts are Ovi, Google etc. Most of the online services have Single Sign On enabled which enables the user to enter the credentials only once and be able to access all the services (like Ovi Music, Ovi Sync, Ovi Sharing etc.) without having to re-enter the credentials again and again. The Accounts&SSO component on the device is the counterpart of the online service accounts management. This subsystem also stores the user credentials in a secure location which is not readable by a non-root user. Since the Buteo SyncFW supports synchronization of user data with online services, it needs to be integrated to the Accounts&SSO subsystem to fetch the SSO token and provide it to the online sync service.

The Accounts&SSO subsystem provides a pluggable interface to hook-in a new online account service. The pluggable component uses a XML file definition similar to Buteo FW. The Buteo SyncFW uses the account identifier defined in the accounts XML definition to link the sync plug-in with the corresponding account. The plug-in developer is also given the option to not use to the Accounts&SSO subsystem, but rather provide the credentials in the service XML.

=== Synchronization Daemon ===
The synchronization daemon is the only always running process in the sync framework. It provides the functionality of loading/unloading the plug-ins, sending d-bus signals, handle profile management (like creating profiles, deleting them etc.) integration with Accounts, hooking up with the hardware layer to register for interested signals (like bluetooth availability, USB and network connectivity etc). The daemon would also load the server plug-ins which would allow external devices to connect to the sync service in the device and perform synchronization. Following is the component context diagram of synchronization daemon depicting the various components that it interacts with. The synchronization daemon is the central component in the framework and is responsible for managing the various states of the framework.

[[File:Buteo_SyncFW_-_Component_View.jpg]]

In the above figure, the boxes in blue represent the Buteo SyncFW components and the boxes in yellow represent the components in MeeGo. The framework provides handlers for each of the external component services that it uses. The main functionality of the daemon is:
* to maintain the state machine of the framework
* to load/unload synchronization plugins
* to initialize the adapters towards external components and maintain the interaction with external components (mainly the interaction is over d-bus)
* to make available the d-bus API of the framework

Following is the state machine diagram of the framework, of which the daemon forms the central component Following are the various states and activities that occur in the synchronization framework:

[[File:Synchronization_Framework_Activity_Diagram.jpg]]

* The daemon gets started (by the upstrart tool) during the startup of the device. Once the necessary initialization steps are done (signal handlers and so on), the daemon checks the DB to see if there is a need to load any server plug-ins. If there are any server plug-ins to be loaded, the daemon loads them in a separate thread and goes into an idle state.
* If the daemon receives client initiated sync, it checks to see if there is an ongoing sync. If there is, it puts the sync request in queue; else it loads the client sync plug-in in a separate thread. Once the client plug-in finishes sync, it releases its resources and sends a signal to the daemon to unload the plug-in.
* If the daemon receives a schedule sync alert from alarm daemon, it takes the same sequence of actions as of initiating a sync by the user from UI.
* Whenever the user activates an account from the Accounts UI, a signal is sent to the daemon, whereby it activates the sync account in the sync UI Note that it might be possible that the daemon has to unload and load a sync plug-in for a sync request in queue to perform the same synchronization. This would be not good for performance. While implementation, this should be taken into consideration and some sort of heuristics should be used to avoid unloading/loading of plug-ins.

=== Developer API ===
As part of the framework, the solution provides an API for 3'rd party developers to create plug-ins for the MeeGo platform. The framework provides two kinds of APIs:
* A plugin API that allows developers to create new synchronization plugins. A client-side DLL API is provided for anyone not willing to understand d-bus
* A d-bus API that any application can use to interact with the framework (the API typically includes methods to start sync, abort sync, get sync status etc.). For application that deal with profile data, a client-side API is provided using which the clients can handle the communication with the sync engine.

=== Hardware Hookup ===
For most of the synchronization services, it is important to initiate the sync on the availability of the underlying transport. For example, when the device is connected to a PC via USB, when bluetooth is switched on in the device, on the availability of the network (wifi/GPRS/3G..) etc. In order to support these usecases, the framework hooks into the hardware notifications services in the device, like Context Framework, Hardware Abstraction Layer (HAL) etc. The Context Framework provides context aware information like Bluetooth availability, network availability etc. The USB connectivity is obtained using HAL. Whenever these events happen, the hardware hookup adapter notifies the daemon to take the appropriate action. The daemon checks all the plugin profiles that have registered to be invoked whenever a particular transport is available and loads those plugins. Once loaded, the plug-ins check if the transport suits their requirements, perform their work and exit, after which they are unloaded by the daemon. There could be some server plugins that are always loaded as long as the underlying transport is available.

=== Device State Based Sync ===
The device state based sync is mainly related to handling of the scenarios where sync cannot continue because of low-device-resource conditions. Examples of low resource conditions are less disk space, low memory, low-battery level etc. The framework makes use of Context framework to fetch information related to some of the device state variables, like battery level, but for other conditions like disk space, low memory the native Linux methods should be used. Details are available in the low-level design chapter. Note that if the sync is initiated from the UI, most of these checks should be done in the UI itself to avoid round-trip checks by the engine. This is a performance improvement measure

=== Change Based Sync ===
Another important feature of any sync solution is to initiate sync whenever the user changes any of his/her personal data. The general term for this is change based sync. There could be two methodologies used to support this kind of feature:

1.If the backend datastores have the ability to send notification signals whenever the database is modified. But it cannot be expected that each datastore supports the notification mechanism. This leads to the next possible option
2.The synchronization daemon polls the various databases at periodic intervals of time to know if some changes have been done to the data- stores. If this methodology is chosen, the timing of the interval becomes quite important. In this methodology, the sync cannot be real-time, since if:
the change in the datastore happens at t0, and
the periodic datastore check interval is at t1, then
the sync would occur only after every n*t1, where n is the periodicity of the sync
This is a reasonable limitation, since the user might not expect a real-time sync operation. One of the possibilities to implement this functionality is to provide a plug-in that would be loaded in a periodic interval and which would be able to check the backend datastores for any changes. The scheduling functionality of the sync can be used to periodically load this plugin. This design avoids the sync framework to directly access the backend datastores.

=== Handling Deleted item list ===
Most of the synchronization protocols support a feature called “fast sync” [Ref: TBD] wherein the consecutive sync’s after the first sync only synchronize the changes from the previous synchronization. The changes include the data that was added/modified/deleted. The protocol implementations make use of the backend datastores capability to return the list of added/modified and deleted items. Though most of the datastores are able to provide information related to added and modified items, they do not keep track of the deleted items and purge them for good. In such cases, handling the list of deleted items becomes the job of the synchronization service.

Since this is a feature that is required by most of the storage plug-ins, the framework could as well provide an interface which the storage plug-ins would implement and store a list of deleted items. Couple of mechanisms exists to keep track of the deleted items:
* Keep track of deleted items for a particular datastore. This involves maintaining a list of previous list against the current and finding the difference between these two
* Maintain a complete list of the items and during every sync session, find the difference between the sync identifier map against the backend datastore id maps. The difference, if any is the list of deleted items. Note that only the ids of the items are stored and not the complete items

=== Profile Deletion ===
Apart from a profile being created whenever the user enables the account or synchronizes with a target device, at some points of time, it could also be deleted by the user. Any profile specific data in the sync framework could be handled by the framework itself, but most of the times, the protocol stacks and the plugins also maintain the corresponding profile specific data. For example, the SyncML stack maintains the anchor information and the id mappings, which have to be purged when the corresponding profile is deleted. The SyncFW cannot directly delete this information from the protocol stack, since the data is protocol specific. A good solution to handle this case is to provide a plug-in interace method (say “cleanup”), which every plug-in has to implement to cleanup the plug-in and stack specific data. In order to invoke this method, whenever the user performs a “delete” operation, the plug-in is loaded and the “cleanup” method is invoked. This is a clean approach to handle the plug-in specific operations and shows the strength of the extendability of the plug-in method.

=== Framework Client Library ===
The framework provides a d-bus API [Developer API] that the client applications can use to interact with the synchronization daemon. This works out as long as the just use simple d-bus API methods like “startSync”, “stopSync” etc., but for complex API methods like “fetchProfile”, “getSyncLogs” the UI clients have to unmarshall the complex d-bus message, parse the message and then take an appropriate action. The more then number of clients towards the framework, the more code replication there is. In order to avoid this, it makes more sense to provide a synchronization framework client library, which the applications can use to interact with the framework. The framework would be responsible for performing the task of un-marshalling the d-bus message, parsing the message and then signal the UI component to fetch the result. More detailed information is provided in further sections.

== System Context ==
Following is the system context diagram

[[File:Buteo-SyncFW-SystemContext.jpg]]

* Context framework (for obtaining context sensitive information) that belongs to the “Data management” layer
* Accounts & SSO subsystem (for accounts integration) that belongs to the “Personal Services” layer
* Bluetooth (for Bluetooth related information) that belongs to the “Comms Services” layer
* Qt Core (for using the Qt core API classes) (QtAPI) that belongs to the visual services
* The d-bus messaging services (for providing the d-bus services) (FreedesktopDbus) that belongs to the “kernel” layer

== Interfaces ==

=== Interfaces Used ===
{| class="wikitable" border="1" cellpadding="5" cellspacing="0"
|-
! Interface Name
! Interface Type
! Description
|-
| libcontextprovider
| Dynamic link library
| The library that provides the context properties
|-
| libaccounts
| Dynamic link library
| The Accounts&SSO library that provides the functionality of accounts registration
|-
| libdbus
| Dynamic link library
| The d-bus library that is used to use as well as provide the d-bus interface for the framework
|-
|libombservice
|Dynamic link library
|The Ovi Notification Engine library that provides the Ovi notification functionality for push-type sync support
|-
|libbluetooth
|d-bus
|The BlueZ d-bus API is used to get notifications about availability of bluetooth
|}

=== Interfaces Provided ===
{| class="wikitable" border="1" cellpadding="5" cellspacing="0"
|-
! Interface Name
! Interface Type
! Description
|-
|libpluginmanager
|Dynamic link library
|The library that provides the plugin functionality of the framework. This API also has a XML interface definition that has the configuration for the plugin. This interface is both for the synchronization plug-ins as well as the storage plug-ins.
|-
|libsyncfwclient
|Dynamic link library
|This is the client side helper library that provides a DLL based API for synchronization clients (typically UI applications). This is apart from the d-bus API provided by the framework
|-
|Framework d-bus API
|d-bus
|A d-bus API for applications to interact with the synchronization daemon. An application using this API will have to understand d-bus and unmarshall and parse the d-bus messages itself.
|-
|libombservice
|Dynamic link library
|The Ovi Notification Engine library that provides the Ovi notification functionality for push-type sync support
|-
|Profile XML API
|XML file
|A plug-in could be deployed to the framework with a default profile XML file. The format of the profile XML file also forms as part of the API
|}

[[Category:Buteo]]

Buteo

2011-04-26T12:12:02Z

Amigadave: categorise

== Buteo Sync Solution ==

The Buteo Sync solution is a complete solution that broadly provides the following synchronization services:
* Device to device synchronization of PIM data (Contacts and Calendar for now) based on SyncML
* Device to cloud synchronization of PIM data (ovi.com, Scheduleworld.com etc.) based on SyncML
* Synchronization of media content to PC based on MTP
* Device to PC synchronization (currently only OviSuite, but this requires contract with OviSuite to support a particular device)

In order to cater to the above service, the following components are available in the Buteo Sync solution:
* [[Buteo/Framework|Synchronization Framework]] - a generic framework providing a pluggable architecture.
* [[Buteo/SyncML|SyncML stack]] - a OMA DS 1.1 and 1.2 compliant SyncML stack
* [[Buteo/MTP|MTP stack]] - A Media Transfer Protocol 1.0 compliant MTP implemenation.
* Sync plugins - a syncml sync plugin and a MTP sync plugin that hook into the synchronization framework

All the above components make up the Buteo Sync solution with the capability of being extended to accommodate more protocols. Refer to the individual pages to understand more about the individual components

== Buteo Sync Features ==

Buteo Sync is not just a sync solution that depends on SyncML, but provides a whole range of Sync features independent of the protocol and the data to be synchronized. Following are the high level end-user features supported by Buteo:
* Synchronization of Google contacts (based on SyncML)
* Contacts, Calendar, Notes sync with Mobilcal.net
* Contacts, Calendar, Notes sync with memotoo.com
* Contacts, Calendar, Notes sync with scheduleworld.com
* Any standard SyncML service

The MTP stack is made public, but the integration with the functionfs driver is being worked on and should soon be available. There are other plug-ins planned for Buteo in future (flickr, facebook etc.)

== Resources ==

To request enhancements or report bugs, please check the [[http://bugs.meego.com/buglist.cgi?type0-1-0=notequals&field0-1-0=product&field0-0-0=component&query_format=advanced&value0-2-0=SyncEvolution&value0-1-0=SyncEvolution&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&field0-2-0=component&type0-0-0=substring&value0-0-0=sync&type0-2-0=notequals list of known issues]] and then [[http://bugs.meego.com/enter_bug.cgi?product=OS%20Middleware&component=Buteo%20Sync report new issues]] or [[http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Core%20OS%20Features&component=Device%20sync propose new features]].

Discussion of Buteo development happens in the issue tracker, on the [[http://lists.meego.com/listinfo/meego-dev Meego Developer list]] and on IRC (freenode.org, #meego-sync).

Source code can be found in the [[http://meego.gitorious.org/meego-middleware Buteo repositories on meego.gitorious.org]].

An [[Buteo/SyncFWClient|example client app]] is available.

[[Category:Buteo]]

Build Infrastructure/Sysadmin Distro/CrossToolchain PackageTypes

2011-04-26T12:06:34Z

Amigadave: categorise

The current naming scheme is still WIP and might change in future releases. Naming was chosen to reflect the function/purpose of the package.

== Packages being transferred from x86 to ARM ==

Scheme: <name>-<src_arch>-<dest_arch>-<version>

Example: glibc-x86-arm-2.11.90-7.1.armv5tel.rpm

Repackaging Prefix: /emul/ia32-linux/

== Packages being transferred from ARM to x86 ==

=== Cross-toolchain packages ===
To match the widely used naming of cross-<arch>-name for cross toolchain packages, there's an exeption in the naming.

Scheme: cross-<arch>-<name>-<version>

Example: cross-armv5tel-glibc-devel-2.11.90-1.1.i586.rpm (package name in BS is still: glibc-arm, glibc-devel-arm, glibc-headers-arm)

Repackaging Prefix: /opt/cross/<arch>-meego-linux-gnueabi/sys-root/

=== Non-toolchain packages ===

'''Unused atm.'''

Scheme: <name>-<src_arch>-<dest_arch>-<version>

Example: ncurses-libs-arm-x86-5.7-7.1.i586.rpm

Repackaging Prefix: /emul/armv5tel-linux/

[[Category:Build Infrastructure]]

Build Infrastructure/Sysadmin Distro/CrossToolchain Components

2011-04-26T12:06:15Z

Amigadave: categorise

= Basic concept =
Crossbuilding and speedup use a so-called "mixed chroot" of ARM and selected x86 binaries.
Normally, the ARM binaries are called and execute the transparent emulation (qemu-arm, from scratchbox also know as cpu-transparency) through the binfmt_handler. x86 binaries don't need to call that emulation layer for obvious reasons.

= Component overview =
The setup has 4 different components:
* packages being transferred from x86 to ARM
* packages being transferred from ARM to x86
* supplementary packages
* cross-toolchain for use in meego directly

== How packages are transferred between arches/schedulers ==
Originally this process was developed to support -32bit sub-package sharing between x86_64 and i586. So any packages built on i586 with libraries
needed on x86_64 for 32bit operations could just be exported from the i586 build without any need to rebuild the sources. Instead it repackages
the binaries and stores them into the x86_64 tree (:full).
Through extension of the configurations, this is also possible e.g. from x86 to ARM and vice versa. This enables the folowing operations.

Currently, all i586 binaries/libraries are installed (in the ARM compile chroot) using a prefix of /emul/ia32-linux/ . Additionally, binaries to be called get
appropriate RPATH and dynamic-linker sections added to the ELF header to look in the folders according to the new prefix.

Most packages can be handled by a template specfile designed for this purpose.

== Packages being transferred from x86 to ARM ==
Naming scheme: on i586 the packages have -x86 in their name and the transferred packages have "-arm" added. The package to install on the ARM side is then e.g. glibc-x86-arm-2.11.90-7.1.armv5tel.rpm .

* speedup
** glibc-x86 - (mandatory also for cross-compiler)
** bash-x86
** gmp-x86
** mpfr-x86
** ncurses-libs-x86
** zlib-x86
** more to come (research shows that especially rpm, bzip, gzip, sed, cat, m4 and perl are candidates which improve speed much)

* cross-compiler in 2 flavours
** Available as 'normal' cross-compiler e.g. cross-<targetarch>-binutils/gcc in /opt/cross on MeeGo@i586
*** cross-armv5tel-binutils
*** cross-armv5tel-gcc
** and for the Build Service acceleration with "-accel" added to the name e.g. cross-<targetarch>-binutils/gcc-accel
*** cross-armv5tel-binutils-accel
*** cross-armv5tel-gcc-accel

== Packages being transferred from ARM to x86 ==
These packages are copied into the appropriate /opt/cross/<target_platform>/sys-root directory . Thus no staging build on x86-side is needed, which would potentially differ from the "native" ARM side builds. 2nd benefit is the speed gain at it reuses the already built ARM versions.
The packages have also the extension "-x86" added to the package name as part of the baselib operation e.g.
Naming scheme: glibc-arm-x86-<version>.i586.rpm
* glibc-arm
* glibc-devel-arm
* glibc-headers-arm
* kernel-headers-arm

== Supplementary packages ==

* meego-accelerator (only on ARM)
** base files/directories for the acceleration on the ARM side, package is aaa_meego_acceleration, as the runscript extension of the build service is executed alphabetically
* meego-cross-armv5tel-sysroot (only on i586)
** /opt/cross/armv5tel-meego-linux-gnueabi/sys-root basic files/directories
* meego-cross-armv7l-sysroot (only on i586)
** /opt/cross/armv7l-meego-linux-gnueabi/sys-root basic files/directories

== Cross-toolchain for use in MeeGo directly ==
As the work is 90% same for cross acceleration and 'traditional' cross toolchain, this was done in one effort.
Packages are partly built on i586 and partly transferred directly from the ARM side:
* transferred from ARM via baselibs
** glibc-arm
** glibc-devel-arm
** glibc-headers-arm
** kernel-headers-arm
** more possible - depending on the need for sdk ?
* built on i586
** cross-armv5tel-binutils
** cross-armv5tel-gcc
* supplementary
** meego-cross-armv5tel-sysroot

Current layout:

/opt/cross/bin/armv5tel-meego-linux-gnueabi-*

/opt/cross/armv5tel-meego-linux-gnueabi/sys-root

Work on the cross-toolchain is not yet completed. Especially installation side-by-side of the armv5tel and armv7l version is not yet supported.
Goal is to support multiple cross-compilers and allow parallel installation/execution.

[[Category:Build Infrastructure]]