[#IDEA-15600] Find bar should be disposed as soon as the search box loses focus.

IDEA: Feedback

Find bar should be disposed as soon as the search box loses focus.

Created: 10 Oct 07 03:43 Updated: 10 Oct 07 22:38

Component/s:

Find, Replace, Find Usages

Environment:

Windows XP SP2

Build:	7,330
Severity:	High

Description

« Hide

For people that used Find dialog before, the new find bar seems better except the find bar sticks around if you didn't cancel it by hitting ESCAPE. That is introducing unnecessary clutter.

It works much nicer in Netbeans 6.0b1 where as soon as the find bar search box loses focus – e.g. you click in the editor or click on a different tab or click anywhere else for that matter – the find bar disappears.

I think that is the way to go since 99% of the time if you clicked somewhere else, that means you are done with the find bar.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Sascha Weinreuter - 10 Oct 07 11:55

No, please not. I find such "auto-hide" features utterly confusing.

[ Permlink | « Hide ]

AlexL - 10 Oct 07 12:41

I'm not sure what you mean by the label "auto-hide".

If you think of the old modal Find dialog, it 'hides' itself after you hit OK or ESCAPE. Ok, the user did something in that case..

But the problem is this find panel is not modal, so the user can go click somewhere else without hitting ESCAPE in the search box.
What I am suggesting is that if a user does that, we should take that to mean they had hit ESCAPE.

In general, I think IDEA should err on keeping the screen real estate clutter free. I used Netbeans some, and found how there Find works to by much nicer. In IDEA, I found that often I had those stupid find bars sitting at the top of my Editor panel, even after I had clicked a tab of another file and then tabbed back.

The real problem is this whole inline panel UI isn't really mature. Jetbrains seems to be using Firefox as the model, and Firefox has the same issues. I think there was discussion about this on firefox forums also.

[ Permlink | « Hide ]

Sascha Weinreuter - 10 Oct 07 12:59

That a dialog goes a away when pressing a button is a common UI behavior. Hiding some embedded control when it looses the focus is not - well maybe not yet, because things like the Find Bar are relatively new concepts. One problem of auto-hiding the bar is that this unexpectedly changes the editor layout which is confusing, even if just for a split second.

I personally prefered the old Find Dialog because it did what I expect a "Find" action to do: pop up a dialog and go away when pressing Enter or Escape. The only advantage of the Find Bar for me is that it stays open, displays the searched text and can toggle certain options (whole words, case sensitivity) on the fly. If it disappears in the moment it looses the focus, this advantage will be gone.

If I need to save the 1.5 editor lines the Find Bar takes, I can easily press Escape to hide it, but I want to keep the control over this.

[ Permlink | « Hide ]

Christof Schoell - 10 Oct 07 16:30 - edited

I agree with Sascha here. Its rather confusing if the Find Bar disappears as soon as it looses focus.

I quite like the new find bar due to the Highlighting of all occurences it finds as long as its opened. At the same time it remembers your current search while looking something up in another editor, which is (IMHO) rather useful than stupid and wouldnt be possible with autohide functionality / modal Dialog (at least not as obviously).

[ Permlink | « Hide ]

Mark S. - 10 Oct 07 22:31

Well, I have proposed, a few times, to provide 3 options for the current find bar:

1. Current Behavior - probably as default
2. Transient - It either closes when it loses focus(which might not be good), or at a minimum, when you hit enter/find next/find previous, that is, you start the search.
3. Permanent - stays around on all editor tabs.

In short, everyone could win(yeah, I know, we don't want that).

Now, to a point I was making in item 2. Closing on losing focus might not be good. You open up the find bar and then you decide to copy and paste something to it, boom, its gone, you have to reopen.

But, I could see why some(but now all) of us would like it to hide away once the find in actually started. That would also be more consistent with the original find popup. It didn't go away when you clicked else where(partly because it was modal); it either went a way because you started the search or you closed it.

[ Permlink | « Hide ]

Mark S. - 10 Oct 07 22:38

However, I will add, as I have also stated before, that I would like to have an option to have the focus go immediately to the first occurrence once I initiate the find(enter/find next/find previous).