Kepler

Making the Cancel button useful when a search is not in progress, to do a reset, seems like a good idea to me. If we do this, we should do it on both the Components and Data panes. Also in favor of this idea is that the Cancel button currently serves no purpose on the Components pane, since we our Components searches return so quickly.

Any comments?

No objections on this proposal, so I plan to do it once many more important tasks are complete.

With r20263 now using the Cancel button to do resets.

The Cancel button is clickable at all times--this is probably not the optimal situation, it should probably gray out in certain situations, like when no text has been entered in the search textfield.

Component searches that hit the network could take a bit longer..."Cancel" would be nice in those situations.

Um, I just tried this and hitting Cancel (or the "x") clears/resets the search results.
Can we close this bug?

It works now, but see comment #3. I took a quick look at doing that and it seemed more effort than it's worth. Chad changed this bug to an ER yesterday which seems appropriate. Seems minor enough to push post 2.0 to me...

make sure to test this on Windows please

How about this policy:
-Deactivated Cancel button until Search button is pushed
-Activated Cancel button until Cancel button is pushed

That seems like a good idea, though the concept of "search button pushed" needs to include hitting Enter, and "Cancel pushed" includes hitting the little x on Mac, or doing a blank search. I'll take a look...

First, it works on Windows. The current behavior is functional and convenient. It's good enough to use for now.

Second, I'd argue for the following (eventual) behavior:
1. The search button is a search/cancel button. There's no need for the cancel if there's no search, and vice versa. The code to toggle this should be at the beginning and end of the search code (basically on.enter and on.exit functionality), rather than keyed to the method of initiation.
2. The reset view button is always active except when the tree is in its default state. Basically, in the code to modify the tree, turn the reset view button on. At initialization and when the reset view button is clicked, turn the reset view button off.

Hi Oliver, off the cuff having a search button that does both search and cancel doesn't feel right to me. I see how it'd save space, but I'm having trouble thinking of an example that does that (have one?). Anyhow we want to avoid gui changes at this point for the 2.0 release, so I'm punting on that suggestion for now...

I've checked in a change (r20491) that enables/disables the cancel button appropriately. The cancel button should now do both what the old cancel and reset buttons would do. Please comment if you find any problems.

Also I believe r20491 uncovered a bug: when you cancel during or after a Data search, you get errors from ObjectManager and/or CacheManager. I'll open a new bug for that, and leave this one open for a little while longer.

It's like having a play/pause button on a music player. Stopwatches usually have a start/stop button. In my mind, it's a little like an on/off switch. I'm not actually sure I could think of a search function that has a cancel option, let alone one with a search/cancel button. The thought was really which set of buttons to give double duty. We currently have cancel/reset, but the cancel/search behavior are mutually exclusive complements.

We might be able to get rid of the reset button entirely by putting the search results in the "All Ontologies and Folders" tree. That way, if you want to dismiss the search results, you just fold the search results branch. Your original browsed tree never goes away, so you never need to call it back. In that case, the only useful reset button might be to close up the tree after the user has opened up a ton of branches.

All that being said, the thing works and looks fine. The rest is polish and some personal preference, so it's really less important.

Original Bugzilla ID was 4087