On Thursday 15 June 2006 10:04, you wrote:
> 1) The animation is cool, but it is pretty easy to lose track of terms
> as they shift around when child terms are open. I don't know if you can
> control this behavior at all since I know GraphViz has a mind of its own
> when it comes to placing terms.
Unfortunately, there's no way to control this. GraphViz wants to draw the
easiest to read graph no matter what, so it shifts nodes around willy-nilly.
In the end, I added the animations so you can at least get a sense of how the
graph has shifted around when you expand terms.
When I have some more time, I'm going to see what I can do about controlling
the ordering of the nodes within ranks. There's no way to have total control,
but I may be able to use some of the node ranking commands to give GraphViz a
hint about how I'd like the ordering to look.
There are other layout engines that do less shifting around of the graph (like
yFiles), but these are always commercial products.
> 2) After opening and closing various terms, I found a lot of terms
> became orphans because their parents had been closed. Perhaps this is
> necessary for the editing function, but I would like to see a way to
> close all the orphan terms at once, or select subsets of them to close.
> Also maybe there should be an option to close all child terms of a
> parent term when closing the parent term.
That's kind of a feature. The idea is that you should be able to expand the
graph in any direction you want, so it's fine to orphan a term, and then
browse out from that term.
But this certainly shouldn't be the default mode.
> 3) Another pop-up menu option for the orphan terms might be "reconnect
> with root," to quickly show the parental lineage of a term.
Absolutely. I also was going to add a "select all paths to root" option.
> 4) Other pop-up menu options could selective open links only of a
> particular type when opening parent or child terms.
That's a really good idea.
> 5) Better explanation of the little numbers in the corners and why
> sometime a red dot appears would be helpful.
I forgot to explain this in my initial email. Here's how that works (explained
in terms of the parent expand button, but it's also true for the child expand
* If no parent terms are expanded, the icon is a +.
* If all parent terms are expanded, the icon is a -.
* If there are more than 10 parent or child terms, the icon will be drawn in
red. This is to warn you that the graph will probably be massively rearranged
if this node is expand.
* If some (but not all) parents are expanded, the icon changes to represent
the number of unexpanded parents that aren't being shown. If there are < 10
unexpanded parents, the icon displays the number of unexpanded parents. If
there are > 10 unexpanded parents, the icon becomes a circle (since numbers
with more than one digit won't fit into the box).
In the future, I may add a tooltip that will show the actual number of
unexpanded parents when the mouse hovers over the circle icon.
> 6) I could not discern any actual editing function in the demo, which I
> took to be a display demo. In any case, I think you should pursue this
> line of further, even if the only end result is an interactive graphical
> browser for OBO-Edit and a possible annotation tool.
There are no editing capabilities here. This was just a demo to show how
interactive browsing would work with GraphViz.
It will be easy to tie this kind of component into GraphViz, once the OBO-Edit
infrastructure is updated. There is a considerable amount of infrastructure
work to do, because in the current ontology editor panel, every selection
picks a link (not a term), and every selection represents a single unique
path to the root.
In the GraphViz driven editor, it would be possible to select a link OR a
term, and a selection would not imply any particular path to the root.
OBO-Edit's understanding of selections would have to be expanded to allow for
this variety. That could be a week or so of work.