[darcs-users] Patches dependency discovery

Radosław Grzanka radoslawg at gmail.com
Fri Jul 8 20:48:22 UTC 2005


On Fri, Jul 08, 2005 at 02:40:15PM +0200, Leif Frenzel wrote:
>> the tree representation would look like
>>
>> A - B - C
>>   |
>>>   - D - C
>>
>> suppose you select B in the UI, this would automatically select A, C and
>> D go unselected. If you select C, then A, B and D would be selected with
>> it (even if the entire D branch was collapsed and not visible to the
>> user so far; we should automatically expand it in that case).

> That's bad. If I select C and then change my mind, I have to figure
> out which additional patches suddenly became ticked and untick them.
> That defeats the exploratory nature of good UI design. Either that or
> it starts getting more complicated with an 'undo' button, etc.

Hmm.. How about solution witch is used in 'aptitude' application on
Debian based systems.
Aptitude is an application witch manages packages in debian. Packages
(like patches) have several dependencies which must be satisfied to
install package selected by user.

Now, aptitude provides "automatic installed packages" feature. That
are packages which were installed only to meet dependencies of package
selected by user (they were not selected explicit).

Let's come back to patches realm.
Let's say patch A depends on patch C and patch B depends on patch C.
If user selects patch A then patch C is selected automaticly (with
flag set). Next user selects patch B. Nothing happens as all
dependencies are met. But just then user changes mind and deselects
A.. nothing happens. Only when user deselects B, C is not needed
anymore and was not explicitly selected to be applied so it is
deselected.

So basically it is something like three state checkboxes.. more or less..

Moreover it is possible to be implemented as flat list (that was my
'simpler design' thought witch was 'to be fixed' on proposal web
page'). User could be informed about patches needed for particular
patch.


> > Still it is good to have a tree that reflects dependencies. It gives the
> > user a quick overview of what he would have to select in order to get a
> > particular patch. But having the leaves as root elements would mean that
> > the user would have to expand all the tree to find patches that precede
> > the others.

> That's why I'm suggesting putting all patches at the root. So your
> example above would become:

> A
> 
> B - A
> 
> C - B - A
>  |
>  - D - A
> 
> D - A

> That is, I imagine the typical use case to be 'I want to pull patch X,
> and need to know which other patches I have to pull as well'. That is
> made very easy using the arrangement above, since X can always be
> found at the top level, and the dependencies of X are all its
> children. I don't see the list of patches that depend on X as being
> terribly useful information.

I get the feeling that this is flat list.. and tree is just for
informational purposes. User basicaly needs to select only top level
leafs to operate. I don't know is it really so helpful. Maybe just
some info text about dependency requirements were enough

> Regarding GEF: if you try the script I wrote, you'll see that Graphviz
> (which AFAIK is considered best-in-class for open-source software
> which does this) does a pretty mediocre job of laying out the graph,
> and scales poorly to large graphs. So, don't expect miracles if you
> actually try to show the complete graph. Some sort of simplified view
> is probably inevitable.

GEF does really poor job of laying connections between nodes. At least
from my experience. I instantly thought about it after your first
reply (which is reflected on web page) but two seconds later I wasn't
so excited about it anymore..
This is really effort overkill and graphs becomes uninformative after
about approx. 20 nodes (well - we could implement some inteligent
nodes laying algorithm which could help to raise that to.. let's say
50 nodes).

Cheers,
  Radek.

-- 
Galiera: http://zdjecia.zuzia.homelinux.net/
Gallery: http://zdjecia.zuzia.homelinux.net/




More information about the darcs-users mailing list