Home · All Namespaces · All Classes · Grouped Classes · Modules · Functions

Quicklauncher

• Issues affecting application startup times
• Quicklauncher Stub Application
• SXE Issues
• Launcher integration
• Making Applications quicklauncher Enabled
• Initial Results

Issues affecting application startup times

Early Qtopia versions suffered from slow startup times primarily for the following reasons:

• loading and linking dynamic libraries
• constructing QtopiaApplication
• constructing widgets
• loading data files

The quicklauncher functionality aims to eliminate 1, 2, and some of 3. Further information about speeding up application startup times can be found in Writing Applications that Start Quickly.

Quicklauncher Stub Application

To eliminate loading/linking and QtopiaApplication construction, a stub application (called quicklauncher) will be run in advance of an application being requested. When the quicklauncher is started, it will:

• link to the most common libraries
• construct QtopiaApplication
• pre-load the default font and initialize other data where possible
• execute the event loop and wait for a request to run an application

When quicklauncher is requested to run an application, it will:

• drop all current LIDS/SXE credentials
• load the application plugin
• change identity to that of the requested application. This includes LIDS/SXE credentials, process listings and QCop channels
• run the application initialization function (which constructs the main widget)
• return to the event loop

At this point, quicklauncher appears and should behave exactly as if the app had been started normally.

SXE Issues

The use of static global initializers in quicklaunch applications should be avoided where possible. The problem is that these fire before quicklauncher can confirm and switch to the identity of the application. A typical symptom is SXE errors reported for the quicklauncher process or for an invalid process.

Static global initalizers can be used as long as they do not cause code that interacts with LIDS/SXE to be run. It is suggested to limit static global initializers to registration-type functions and to perform any further actions required once the main widget has been constructed.

Launcher integration

The QuickExeApplicationLauncher server task is responsible for ensuring enough instances of quicklauncher are running.

When a request to launch an application is made:

• QuickExeApplicationLauncher checks if it can launch the app
• If quicklauncher is running it is sent a message via QCop to become the application
• Otherwise the application is started manually (which causes quicklauncher to run and then become the application)
• If required new quicklauncher processes will be started

If the server is running as root, it will set the priority of quicklauncher to low while it is being started to ensure that it does not take processor cycles needed by foreground processes. It will be given normal priority when a request to load a new application is received.

Making Applications quicklauncher Enabled

To enable an application for quicklauncher, use the macros described in Applications.

Initial Results

The initial results of the design described above are:

* The Media Player delays its main GUI construction, so the initial window displays in 0.4 seconds and the full GUI is displayed in 1.3 seconds