ArmApplicationChoices

Summary

Because of issues such as cache size on ARM processors, some applications that are standard on x86 images do not perform as expected on ARM. Some applications do not currently port to or execute correctly on ARM at all. Alternatives should be investigated to produce a more optimal set of default applications for ARM releases. A perfect example includes some Mono applications, such as Banshee, which do not presently work on ARM.

Release Note

To better serve our users, some of our default and preferred application choices have been optimized for the ARM platform.

Rationale

Poor performance or broken applications reflect poorly on ARM targeted ubuntu.

User stories

Assumptions

Broken or poorly performing application detract from the ARM user experience. This is especially true when this involves primary default applications we provide.

There are no reasonable default application choices in some application categories.

Design

Current applications will be reviewed and alternatives compared based on performance and acceptability in the UNR screen size.

Since there are some areas with no application choices, it has been proposed instead to insert bookmarks or guides for helping the user to select web applications in their place.

Implementation

This is partially a seed specification, that is, it ultimately relates to and is implemented in editing the choice of applications that will appear in meta package seeds. The following changes will be made to the seed:

OpenOffice.org will be removed, a bookmark will be used in it's place. Email client (evolution) will be removed, a bookmark will be used in it's place.

A new Canonical package will be created to install menu items for bookmarks for those cases where no application choices exist. This will be une-default-application-bookmarks. This will likely only require dropping appropriate .desktop files.

A second order solution suggests that rather than a bookmark, a small gtk application will pop-up, offering the user to install one of several packages, or one of several online options. If this happens, it would also be done in une-default-application-bookmarks. This could be handled with a small pygtk greater app and seems a natural application to do in quickly.

UI Changes

Possible splash application when no appropriate default application is available. New artwork for icons may be desired for these bookmarks or splash applications.

Code Changes

There are no code changes anticipated specific to this spec outside of seed files and meta unless splash application is added.

Effort

Actual changes are less than a day. To create a une-default-application-bookmark package should take a day as well. To write a small splash application with lists of appropriate alternatives should be a day or so, maybe a week if more extensive artwork support is also needed for that. Profiling and investigating bottleneck applications on ARM may be a week.

Migration

For UNE, this would be the first release for ARM, and hence there should be no user migration issues.

Test/Demo Plan

Our best criteria would be to test usability side by side.

Unresolved issues

One consequence of this is that the ARM UNE seed would be diverged from x86. However, this is already contemplated with respect to browser choice.

Mono eats ARM battery performance alive. My preference by far would be to use gnote in place of tomboy and gthumb in place of f-spot. Some suggested mono battery/gc issues might be fixable.

BoF agenda and discussion

Notes from mobile-lucid-arm-une

  • UNE for ARM
  • special ARM restrictions:
    • no free 3D drivers

    • relatively low CPU/mem/disk power (target v7: > 384 mb / > 800 Mhz / > 4Gb / no 3d accell)

      • 4 GiB lower bound of disk space with minimal swap, and a little bit of space left over

      • browser (firefox is too heavy weight) -> chromium-browser

      • ensure that xulrunner is not pulled in by any reverse depends
      • strip down application
        • by use-cases
          • office: openoffice? might require compcache on low mem systems

            • check if this is really needed -> decision: lightweight devices that are

              • net/web-centric; -> don't install by default: provide easy access through software center; maybe trigger install when trying to access appropriate content type.

            • strip down openoffice.org

            • check alternative: lightweigt alternative -> abiword -> might have

              • problems;
            • point users to google docs. check whether we can hook up content types
          • internet: chromium-browser
          • email: thunderbird? (xulrunner problem again);
            • anjal (low mem evolution-data-server frontend); sylpheed modest? not good enough
            • on demand (allow to select webmail/application on first use)
            • killing evolution might remove the abilities and features of
              • evolution-data-server
            • evolution (44M) has problems small screens
              • check whether evolution can be split up by components.
            • thunderbird is large
            • anjal: active development by intel (default moblin client)
              • evaluating anjal: does it target the right screen
            • firefox has plugins mailto: links
              • check chromium-browser

          • games: Solatire -- popcon? (3 most popular games / select games by depends -> ensure that most likely libs etc. are on the image to allow OEMs etc. to extend game set without incurring too many changes to the libs etc. installed by default); check what windows installs;

          • launcher: 2d launcher in free distribution
          • chat: empathy
          • music/video: use whatever desktop selects, but reevaluate when desktop switches to new app
            • desktop team will reevaluate what is used on UNE

            • canola came up as a choice http://openbossa.indt.org/canola/

              • touch screen centric (is this the right choice?)
                • bfiller: some evaluation was done on making it less touch
                  • screen centric;

                • could replace f-spot, rhythmbox & totem

                • work required for non-touch screen -> ~1 month (bfiller)

              • might require new packages
              • no plugin for browser most likely.
                • check the overhead of totem-plugin only

            • banshee -> more modern than rhythmbox -> decision by end of december (install on arm)

        • by elimination
          • mono might be a problem, potential replacements:

            • mono eats battery (-> open a bug LP:)

              • f-spot -> gphoto

              • tomboy -> gnote (won't go to main)

              • banshee -> rhythmbox

            • canola ?

          • firefox -> chromium-browser

          • xorg-driver-* -> remove/replace (change xserver-xorg-all on arm to only depend on relevant drivers)

          • compiz -> follow 32-bit UNE

          • fglrx-*

          • gnome-* -> only use essential gnome apps?

          • language packs -> fill up image (CD-size or 1G SD-Card -> decide later)

            • evaluate whether users/comsumers/oem can inject language packs after
              • download (ncommander)
      • use compcache by default ?
      • swappyness needs to be turned down by defailt (might need special arm related -settings package)
        • (/proc/sys/vm/swappines needs to be 0)

Changes Proposed at UDS

  • get rid of openoffice -> hook up google doc in launcher

    • evaluate if we can autolaunch google doc when user first time touches doc content type
  • email client evaluation (last resort fallback: provide on demand options to user)
  • browser: chromium-browser (see lightweight browser spec)
  • music/video: evaluation, decision by mid december (bfiller)
  • chat: stick to UNE decision
  • games: select a small subset (either using popcon or check what windows ships)

  • f-spot: no real alternative exists -> keep it

CategorySpec

Specs/ArmApplicationChoices (last edited 2009-11-30 22:44:27 by pool-72-75-157-65)