[Installit-dev] TreeView/TreeModel implementation

[Jannis Pohlmann]

Hi all,

I wrote down some thoughts on the TreeModel/TreeView implementation we
will use for InstallIt on
http://dev.sten-net.de/2005/10/03/user-interface-complications/. You
don't have to visit the site because here is the content:

-- Tree View Complications --

It’s been a long time since I commited something useful for InstallIt.
There have been several problems with TreeView/TreeModel from GTK+. The
graphical listing of packages, groups and categories should look like this:

    [ ] Xfce 4.2.2 (Group)
            [ ] libxfcegui4    version: 4.2.2
            [ ] libxfce4util   version: 4.2.2
    [ ] File Management
            [x] thunar         version: 1.0
            [ ] xffwm          version: 4.3.3
    [ ] Xfce Libraries
            [ ] libxfcegui4    version: 4.2.2
            [ ] libxfce4util   version: 4.2.2
            [x] libexo         version: 0.3

When enabling/disabling members of a group, the group and all other
group members should be enabled/disabled, too. Additionally, you should
be able to enable/disable packages from the category listing. This
forces us with several difficulties:

* Let’s assume you enable a package in the category listing. After this,
  you disable a previously enabled group this package is part of. What
  do you expect the software to do with your package? Disable it? No,
  surely not.

* You enable a package A which depends on two other packages B and C.
  Then, you disable A again. What should InstallIt do with B and C?
  Display a warning that both are still enabled? No, it should disable
  them (only if they are no part of an enabled group, of course).

There are lots of other cases where tracking dependencies and manging
the enabled/disabled stuff correctly. This would be extremely
complicated to solve just by iterating through the TreeModel and
performing some actions. I finally found an easy way to circumvent
complex tree iterations/manipulations:

In addition to a TreeModel and TreeModel instance we define a list of
the explicitely disabled/enabled objects (= groups, packages,
categories) with their status (enabled/disabled). Flat, not nested. It
could look this way:

    [<package name="thunar" version="1.0" type="source">,
     <group title="Xfce 4.2.2">,
     <package name="libxfcegui4" version="4.2.2" type="source">,]

This means that the group Xfce 4.2. 2 and the packages thunar and
libxfcegui4 have been enabled explicitely by the user.

* If you disable the group Xfce 4.2.2 now, libxfcegui4 (which is p
  part of it) won’t be disabled. If you enable one of the members of
  Xfce 4.2.2 afterwards, this will only enable the group explicitely.
  All members are enabled implicitely.

* The package thunar is enabled. As it depends on libexo you can safely
  assume that libexo is also enabled (but since it wasn’t explicitely
  enabled it’s not in the list). Disabling thunar will disable libexo
  for you, too. If libexo would have been enabled explicitely, it would
  not be disabled.

* Let’s assume the whole package list is updated. This will force
  InstallIt to refresh the list of explicitely enabled items, too. Items
  which don’t exist in the new package list any more will be removed.
  After having done this, InstallIt will enable all items of this list
  and it will (implicitely) enable dependencies/group members/etc., too.

This surely will cause some overhead and won’t solve every problem but
it’s a good starting point, I think. Any comments on this?

Regards,
Jannis