Revised Hidden Node Deletion

[everbeek]

NB: This issue is mature. See final comments for why the issue became complicated.

Peggy pointed out the oddness of the deletion buttons and display checkboxes. She suggested changing them to be alongside the display title bar, and as icons with very quick hover over explaining what they do. An X and a checkmark might be the way to represent them. Probably can use tipsy for the quick popup.

There is a problem though. Deletions require that we consider all node checkboxes, not just those in a particular panel. When I combine the ontology and node ones into a tree of checkboxes, that will help a bit, but the expansion set checkboxes still interact with the other ones. You can hide an expansion, then cherry pick a node out of it to keep, then delete...

If I made both the ontologies and the expansion sets into trees, then I could have deletion boxes for those two. I can't imagine someone getting rid of an expansion set while keeping a particular ontology...oh, wait, I can...

[everbeek]

Would it be ok to have the two separate sets of deletion and reset boxes for Ontologies/Concepts, and for expansion Sets? the reset button would be odd, then, because it would only work on the associated set, presumably. The deletion button only working on the associated set is mostly fine...I still think these buttons need to be about where they are (though made prettier).

[cpetrachenko]

I think I need to see a mockup because my brain isn't parsing this. (And it's getting pretty full in that sidebar.)

[everbeek]

I was lazy with the expansion set part, and am not sure if we want those to also show nested concepts (but why not? That's a good idea actually.)

[everbeek]

Implemented the nested version, have the checkbox updates working. Enhanced ontology checkbox to become non-grey when all of its nodes are visible, whereas before it stayed grey unless directly checked again.

[everbeek]

When resetting checkboxes, the nested filter does not get updated.

[everbeek]

I want to add a "Collapse/Expand All" type button to the bar, for the ontologies.I want to add a "Collapse/Expand All" type button to the bar, for the ontologies.

if I do this, and add the delete/re-check buttons, where will they all fit? Three icons on the collapsible filter bar?

Also, Peggy convinced me that having no interaction at all between the expansion set and concept filters would be fine. It is not without problems, but the UI benefits so much, primarily at the cost of making the already unusual expansion set filter slightly more unusual.

Also also, I should create a nested version of the expansion set filter.

[everbeek]

Moving the delete and re-check buttons all into the expander bars. I have some icons I need to decide on. Here they are:

1) 2) 3) 4)

[cpetrachenko]

No. 4!

[everbeek]

Have the filter-specific Delete and Re-check buttons working. That was kind of wild; I had used some awesome shortcuts that made sense before, and I could no longer use them, and had to make more involved inheritance-safe methods of deleting nodes.

I need to fix the un-greying of ontologies with only a single node in them. Try a mapping expansion of artery, and use the ontology checkboxes to see how it misbehaves. Note too that on undo, the ontology checkboxes do not get un-greyed.

[everbeek]

Fixed the single ontology checkbox issue.

Now, proceed with showing the node checkboxes beneath the expansion set filters.

[everbeek]

Have the nested expansion set concept filter working. But...the re-check buttons now behave quite strangely. When I work with the nested ontology filter for a while, things are fine, but once I start working with the expansion set ones, it gets weird. Try various ordering like deselecting, then trying to reset, then selecting one node and trying to reset, and see what happens.

I need to get the expansion set checkmarks working like ontologies (checking to see if all their nodes are active, and removing the grey effect if so, etc). If that doesn't do it...dig deeper.

[everbeek]

Fixing the greying and re-check behavior of the expansion set filter to be like that of ontologies worked perfectly.

[everbeek]

Consider changing the ascii +/- to the open-iconic +/-. And consider the other icons as well...probably a different issue! See #496.

Remove the older expansion set filter from the menu, and the old node management buttons now. Actually, for the node addition field, I will move it...and remove that whole widget panel from the view. I am not sure if I will delete the class yet, but I will deprecate it.

[everbeek]

Bug in the deletion buttons: the expansion set one doesn't get updated concept checkboxes on any delete. Hmm...I cannot replicate, but now the ontology and expansion boxes, when used to clear all the checkboxes, cannot be re-checked. Also, if all concepts are cleared, the same thing happens. At least one concept must be visible for it to work.

Aha! I changed the re-check function to trigger a click n each checkbox. Since the nesting checkboxes affect the same entities as the nested checkboxes, those entities get toggled visible to hidden. I can sort this out.

[everbeek]

Fixed that bug. Now, I notice that if the same node is involved in two expansion sets, that the expansion un-check will not be complete as long as the other one is visible. That is, the same concept as two checkmarks will interfere with itself. This probably means we need the parent's id tacked on to the checkbox id, to differentiate the two.

No, it is due to the parent of the expansion set I think. It is not represented as a checkbox in the set, and this might be interfering.

To describe more precisely: Expanded artery, deleted original ontology, expanded Artery (AURA), then Concepts of XAO. Now, when I try to hide the mappings of artery (AURA), artery (XAO) refuses to be hidden. But, if I click it specifically, it goes away. if I subsequently click its expansion set, then it is free to toggle in and out. It seems to entirely depend on whether the concept expansion of artery (XAO) is hidden or not. Notably, also, if I hide artery (XAO) via the individual checkbox in its ontology group,I can then toggle the expansion set that contains it, being artery (AURA).

So, yes, I think this is occurring because the root of each expansion should be a checkbox...

Or, it is happening because I made things so that roots of existing expansions are not hidden when their containing one is hidden. That is...artery (XAO) is aprt of expansion (AURA). It is also the root of expansion (XAO). So if expansion (AURA) is hidden, I keep any roots of other expansions, meaning that expansion (AURA) cannot be completely hidden (since one of its nodes is a root of another expansion).

So...how can I make the UI behave in a less confusing way? It needs to reflect this result, but also not disallow the user from hiding everything, as I am now experiencing. Hmmm...

I am in a logical bind. When there wasn't a checkbox to go grey for the expansion set filter, there was no problem. The constraint was acceptable, and necessary. Now it isn't really acceptable. One alternative is to force the dependent expansion sets to hide when we hide the other...and I will not do that. Another is to drop the requirement that an expansion set root be in the graph if it has had a removal attempt via another filter. I mean, we're allowed to cherry pick and hide it, then delete it, so why can't it be hidden via other routes too? Is it really such a fundamental part of the expansion?

I could allow hiding of roots, but also add a checkbox for each expansion root. This would mean that dependent expansions would get greyed checkboxes when their root's member expansion is hidden. Is that ok? That looks and sounds complicated. But it is consistent. A side effect is that nodes that perhaps are still desired could be unwittingly hidden, then deleted...but maybe that's a risk always.

Ok, option three is to not grey out the checkbox if the remaining checked box is a root. This looks buggy, and could frustrate attempts to remove an entire expansion set, but it respects the original rule of not deleting roots of expansion sets.

Why did I make that rule? Was I avoiding a big problem, making it because it sounded good? Can I get rid of that rule?