From info at sten-net.de  Mon Oct  3 21:48:33 2005
From: info at sten-net.de (Jannis Pohlmann)
Date: Mon, 03 Oct 2005 21:48:33 +0200
Subject: [Installit-dev] TreeView/TreeModel implementation
Message-ID: <43418B11.70905@sten-net.de>

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


From tukem at iki.fi  Tue Oct  4 21:58:19 2005
From: tukem at iki.fi (=?UTF-8?B?VHV1a2thIE3DpGtpbmVu?=)
Date: Tue, 04 Oct 2005 22:58:19 +0300
Subject: [Installit-dev] TreeView/TreeModel implementation
In-Reply-To: <43418B11.70905@sten-net.de>
References: <43418B11.70905@sten-net.de>
Message-ID: <4342DEDB.5040300@iki.fi>

Jannis Pohlmann wrote:
> 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:
> 
----- clip Lot of good stuff removed ----------
> 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?

I have no idea how to best implement such tree structure with categories 
and groups so forgive me if my understanding and then what I write below 
is completely wrong.

In the way to describe, if you unselect a group do you have to go 
through all packages belonging to that group and see if it is still 
enabled by some other group or explicit selection? Doesn't sound bad 
unless groups can overlap. What I started thinking was counters. Add 
selection counter to all packages so that you increase the counter when 
the package is selected directly or indirectly and decrease it when it's 
unselected. Anybody getting reminded of magic pointers or garbage 
collection...


Well anyway just a thought.

Tuukka



From info at sten-net.de  Wed Oct  5 09:41:28 2005
From: info at sten-net.de (Jannis Pohlmann)
Date: Wed, 05 Oct 2005 09:41:28 +0200
Subject: [Installit-dev] TreeView/TreeModel implementation
In-Reply-To: <4342DEDB.5040300@iki.fi>
References: <43418B11.70905@sten-net.de> <4342DEDB.5040300@iki.fi>
Message-ID: <434383A8.3030800@sten-net.de>

Tuukka M?kinen schrieb:
> Jannis Pohlmann wrote:
> 
>>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:
>>
> 
> ----- clip Lot of good stuff removed ----------
> 
>>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?
> 
> 
> I have no idea how to best implement such tree structure with categories 
> and groups so forgive me if my understanding and then what I write below 
> is completely wrong.
> 
> In the way to describe, if you unselect a group do you have to go 
> through all packages belonging to that group and see if it is still 
> enabled by some other group or explicit selection? Doesn't sound bad 
> unless groups can overlap. What I started thinking was counters. Add 
> selection counter to all packages so that you increase the counter when 
> the package is selected directly or indirectly and decrease it when it's 
> unselected. Anybody getting reminded of magic pointers or garbage 
> collection...

Correct, to prevent problems with packages being part of more than one
group, we would have to do this when disabling a group or group member:

  1. Determine the group
  2. Disable the group itself explicitely and the members implicitely
  3. Iterate over all enabled groups and re-enable members which were
     disabled just a second ago

And, enabling a package (from a category) explicitely would require to
iterate over all groups, searching for this package in order to enable
its checkbox. Well, you see, trees are fuckin' terrible to manage.

Anyway, this counter idea sounds like a good point (and, of course, it
reminds me of reference counting pointers). I will think about this. At
the moment I'm very busy with other stuff apart from InstallIt.

Thanks for the input again,
Jannis


From info at sten-net.de  Wed Oct  5 12:47:02 2005
From: info at sten-net.de (Jannis Pohlmann)
Date: Wed, 05 Oct 2005 12:47:02 +0200
Subject: [Installit-dev] TreeView/TreeModel implementation
In-Reply-To: <434383A8.3030800@sten-net.de>
References: <43418B11.70905@sten-net.de> <4342DEDB.5040300@iki.fi>
	<434383A8.3030800@sten-net.de>
Message-ID: <4343AF26.7020900@sten-net.de>

>>In the way to describe, if you unselect a group do you have to go 
>>through all packages belonging to that group and see if it is still 
>>enabled by some other group or explicit selection? Doesn't sound bad 
>>unless groups can overlap. What I started thinking was counters. Add 
>>selection counter to all packages so that you increase the counter when 
>>the package is selected directly or indirectly and decrease it when it's 
>>unselected. Anybody getting reminded of magic pointers or garbage 
>>collection...

I thought about counters for a while and I finally think we should not
use them. The reason is, and it's very obvious, that we would run into
lots of new troubles. For example, if you disable a package (from a
category) which is a member of an enabled group, the package shouldn't
be disabled (we would have to raise an error dialog, here).

If you run into too much complications with a concept, it's likely that
the whole concept is, well, shit. And that's what we have here.

I will drop what we currently know as "groups" in favor of something
widely known as "meta package". A meta package is a package without
header file. Instead of "group members" it has a list of packages it
depends on. Of course, meta packages also belong into categories. This
means:

  - If you select (enable) a meta package, all of its dependencies are
    selected.
  - If you deselect (disable) a meta package, only the meta package is
    deselected - the dependencies aren't.
  - Selecting/deselecting a package which is in the dependency list of a
    meta package doesn't affect the meta-package.

Having said this, our tree structure just looks like this:

  File Management
      Thunar 1.0
      Xffm 4.3.4
  Desktop Environments
      Xfce 4.2.2 [Meta]
      Xfce 4.2.3 [Meta]
  Xfce Libraries
      libxfce4util 4.2.2
      libxfce4util 4.2.3
      libxfcegui4 4.2.2
      libxfcegui4 4.2.3
      libexo 1.0
      libtubo 1.0

What means, that we just have categories and packages. We only have to
check the dependencies of each package recursively when selecting a
package. If the user deselects a package, we could of course ask him
whether he wants to deselect all its dependencies or not.

I think this is lots easier to implement.

Regards,
Jannis


From webmaster at nebulon.de  Sun Oct  9 11:41:45 2005
From: webmaster at nebulon.de (Johannes Zellner)
Date: Sun, 09 Oct 2005 11:41:45 +0200
Subject: [Installit-dev] TreeView/TreeModel implementation
In-Reply-To: <43418B11.70905@sten-net.de>
References: <43418B11.70905@sten-net.de>
Message-ID: <4348E5D9.7080006@nebulon.de>

Hola

>I wrote down some thoughts on the TreeModel/TreeView implementation we
>will use for InstallIt on
>  
>
--- cut ---

>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.
>  
>
Hm my opinion is, that if a user diables/enables a group the child-items 
will be disabled/enabled too.
But we should popup a dialog that reminds the User of this actions.

>* 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.
>  
>
Hm I think we should keep it simple and leave a bit more work on the user.
(some clicks more won't be too mad and then the user really knows what 
InstallIt will do)

So we could provide a Warning-list in the main window.
Every  not solved dependency puts a warning in this list.
(a dialog-prompt instead of a new listitem will be very confusing 
because you have no real overview)
So the user watch over the warnings and can decide what to do:
    * Do nothing, then InstallIt will print errors just before the 
install begins and prompts if you didn't        forget to watch and 
manage the list
    * Enable the missing package explicitely (until a InstallIt 
packagelist won't be sooo large there's no        problem to find the 
missing package)

And if a dependecy of a package is not in the packagelist, we could show 
this in the list.
This reminds the user to handle this on his own.


Greets,
Johannes


From info at sten-net.de  Mon Oct 10 19:07:22 2005
From: info at sten-net.de (Jannis Pohlmann)
Date: Mon, 10 Oct 2005 19:07:22 +0200
Subject: [Installit-dev] TreeView/TreeModel implementation
In-Reply-To: <4348E5D9.7080006@nebulon.de>
References: <43418B11.70905@sten-net.de> <4348E5D9.7080006@nebulon.de>
Message-ID: <434A9FCA.6040701@sten-net.de>

Hiho,

Johannes Zellner schrieb:
> Hola
> 
> 
>>I wrote down some thoughts on the TreeModel/TreeView implementation we
>>will use for InstallIt on
>> 
>>
> 
> --- cut ---
> 
> 
>>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.
>> 
>>
> 
> Hm my opinion is, that if a user diables/enables a group the child-items 
> will be disabled/enabled too.
> But we should popup a dialog that reminds the User of this actions.

Yes, that was what I had in mind, too. But ... this would be difficult
to handle, that's why I'm going to drop groups in favour of meta packages.

> 
> 
>>* 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.
>> 
>>
> 
> Hm I think we should keep it simple and leave a bit more work on the user.
> (some clicks more won't be too mad and then the user really knows what 
> InstallIt will do)
> 
> So we could provide a Warning-list in the main window.
> Every  not solved dependency puts a warning in this list.
> (a dialog-prompt instead of a new listitem will be very confusing 
> because you have no real overview)

See above for the change from groups to meta packages. This will make
such a list obsolete. But a nice feature would be to provide a solution
for detecting installed but orphaned packages. Orphaned in this case
means that no other packages depend on it. Often, if you select a meta
package, lots of dependencies are selected, too. But if you deselect the
meta package again, none of the dependencies is deselected (that's how
Apt/Synaptic behaves).

Popping up a (rememberable) question whether to deselect dependencies
when deselecting a meta package or not should be fine, at least from the
short-term view.

> And if a dependecy of a package is not in the packagelist, we could show 
> this in the list.
> This reminds the user to handle this on his own.

I'd prefer to print a warning in the install wizard before performing
the first action on the package, like:

  Hey, some of the dependencies of <package> could not be resolved from
  <mirror>. Maybe you have to install them manually before performing
  the installation.

  <unresolved dependency 1>
  <unresolved dependency 2>
  ...

  Do you really want to continue?

              					      < NO >   < YES >

That should be ok, don't you think?

Regards,
Jannis