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 may be the typical case for push, where I know which patches are in
the list in advance (because I have recorded them). For pull, I get a
list from the repo, and I don't think it is the typical case that I
already know that list and know which of the patches in the list I want
to pull.
>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.
It may be useful not to see them, though, or more precisely: only see
them if I like. Getting a list of all patches, which may be long, forces
me to scan them and possibly to scroll the dialog (or whatever window
they are on); if they are in a tree below the root node, I have to
expand them only if the root node seems acceptable or interesting to me.
Only in the case when I have a special patch in mind or want to
cherry-pick from the list I want a different view. For this I could
switch to flat view (or we could have a filter like in the Eclipse 3.1
preferences dialog).
By contrast, using the arrangement you show, I need to already know at
least one of C's immediate dependencies in order to actually find C.
That's true for pulling at least. For unpull, the situation reverses,
so probably in the long term both views should be available (but
again, all patches should appear at the root, and no automatic
ticking, please).
Can't see how to avoid it. If not for ticking, then for un-ticking. For
instance if we have A > B. Initially, A and B are unchecked and B is
disabled. Check A, so B gets enabled. Now check B. We have two
possibilities: either we disable A (in checked state) or we don't. If
the latter, the user can uncheck A, which would force us to uncheck B
automatically. I the former, that's no good, for now I can get into the
situation that there is a checked disabled patch that I would like to
uncheck, but first have to figure out which others I must uncheck
elsewhere to get it enabled again. In the simple case, that's only B. In
the example above, suppose C is checked and disabled, because all it's
dependencies are checked. Now you have manually to go through the entire
dependency tree below C and locate A, B, and D in the list at the top
level and uncheck them. And that's bad too.
Apart from that, some people like it if the number of clicks they have
to do is reduced. If I select something that has dependencies, there is
nothing I really can decide about these. I just have to select them, and
that can be done automatically as well as manually. And this is a common
UI paradigm. It's everywhere in the Eclipse export wizards, where you
want a file to be exported, all parent folders are selected
automatically. This is not an exact parallel, of course, because of the
multiple parents that we have in our case, but apart from that special
problem, it's perfectly common UI behaviour.
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.
Yes, I agree. I'd prefer a list or tree with checkbox items over a
special graphical drawing.
Ciao,
Leif
-- Jamie Webb
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
