New features for the Hildon Application Manager
===============================================

* Fix the workaround pushed in commit 82b8b2 [dkedves & vjaquez]
 
Before the HildonStackableWindow only one HildonWindow existed, and all 
the interaction flows started and ended in this window. But with the stackable
ones, the end of the interaction may end in another stackable window. The 
workaround avoids the assertion raised when the current window is different
of the window what started in the interaction, using (hackishly) the last
pointer in the dialogue stack, instead of the current window.

IMO, the correct way to fix this is to AVOID the creation of new stackable
windows when an interaction flow is ongoing. [vjaquez]

* New hard buttons logic as in the spec. [vjaquez]

* Enable the user edit the package catalogues name.

* Complete port to new Fremantle APIs [vjaquez]

- update-notifier.c: alarm API.
- New widgets.
- New I18N strings.

* Try to get rid of the legal notice as much as possible [mvo]

Right now, the legal notice dialog is shown whenever a package from a
non-certified repository is installed.  It might be more educational
to only show that notice when a non-certified repository is added or
enabled.

* Better handling and reporting of dependency and conflict issues. [mvo]
  [DELAYED]

We need to get better at explaining the reasons why a given operation
can not be performed so that the user has a chance of taking
corrective actions.

Also, since we now have a visible package that represents the
operating system, we can be more agressive with making changes to
invisible packages: the operating system package will make sure (via
its dependencies) that we don't kill the device by accidentally
uninstalling or upgrading important packages.

The general principle that this feature aims to implement is that the
user-visible packages are managed completely manually by the user, and
the user-invisible packages are managed completely automatically.

Thus, the general behavior of the Application Manager should be the
following:

 1 When the user requests to install or remove a package, the AM will
   plan to do any necessary (and possible) changes to all the packages
   to satisfy the request of the user.  These changes can include
   installing additional packages, removing already installed
   packages, or upgrading installed packages to a newer version.

   The AM should try at least as hard as apt-get to find a solution,
   but it should favor upgrading over removing.

   For example, instead of removing the OS meta package in order to
   upgrade some invisible packages, it should prefer to upgrade the OS
   meta package (and pull in the complete OS update).

 2 Once a solution has been found, and it requires changes to user
   visible packages, the user has to confirm these changes.

 3 When no solution has been found, the only reasons for this can be
   that the OS package would need to be removed, or that packages are
   needed that are not available from any repository.  This can be
   explained easily, I'd assume.  We should probably not even list the
   individual packages that are missing, but just say that the
   catalogues are broken.

The following steps might be appropriate:

- Investigate which algorithms apt-get and aptitude use for "install
  <pkg>" and "remove <pkg>" and make them available in the apt-worker
  (preferably aptitudes).  Don't remove the existing algorithms.

- Add a red-pill setting that makes the apt-worker use those
  algorithms.

- Tune the algorithms to favor upgrading over removal, as explained
  under point 1 above.

- Add suitable problem detection and reporting algorithms that
  implement points 1 and 2 from above.  But instead of letting the
  user confirm the planned changes to visible packages, we just report
  these changes as errors, or do them automatically:

  - If a visible package A would be removed and the user is doing a
    "uninstall B" operation, we report "B is needed by A."

  - If a visible package A would be removed and the user is doing a 
    "install B" operation, we report "B conflicts with A."

  - If a visible package A would be newly installed or upgraded and
    the user is doing a "install B" operation, and package A is not
    the OS, we just do the upgrade.

  - If package A from the last paragraph is the OS, we report "B needs
    A to be installed first".

  - If a visible package A would be newly installed or upgraded and
    the user is doing a "uninstall B" operation, we report "B is
    needed by A".

  The reports should always include the respective versions of the
  packages.

- Experiment!  Make a decision whether we can ship with these
  algorithms enabled by default or whether we can get the next step
  done as well:

- Show the thing to the UI people so that we can come up with the
  right way to do it: letting users confirm the changes to the visible
  packages.

* Unify configuration by having one directory for dropping off xexp
  files. [mvo, config-cleanup]
  [DELAYED]

We should implement a unified handling of settings.  Each setting has
up to four values: user value, system value, variant value, and
builtin value.  These four values are merged according to the type of
the setting.  All values except the builtin value can be unset.

* Implement Maemo-Upgrade-Only-From [mvo]
  [DELAYED]

Details later.
