- This topic has 5 replies, 3 voices, and was last updated 6 years, 10 months ago by
.
-
Posts
-
New search seems to keep values per open editor and switches them as editor tabs switched which doesn’t make sense.
It also doesn’t keep classical dialog, showing it only for tab where it was open but new search in others.
Even if technically search box is created per each editor (which IMHO doesn’t make a lot of sense) it should behave as a singleton regarding appearance and values.
Fedor,
New search seems to keep values per open editor and switches them as editor tabs switched which doesn’t make sense.
I can see benefits to both approaches – but we’ll look at adding a preference page for this in 2017 CI 11 – thank you for asking.
It also doesn’t keep classical dialog, showing it only for tab where it was open but new search in others.
The classical search dialog is a modeless dialog that remains open as you switch between editors. Are you suggesting that if it was used in one editor (instead of the inline search) – the next time the search keystroke is pressed for that editor, the classic dialog appears? As I write this, I realize I’ve probably misunderstood your request – could you please elaborate?
Thanks!
> I can see benefits to both approaches
There may be some rare benefit, but most frequent everyday use case is definitely not when one searches different text depending on selected editor. Rather, most frequently one uses some of last values from all searches (note the dropdown list for last values is missing as well in new search, this is another thing to fix).
Usually, the last search on a particular file becomes irrelevant when one did perform new search or replace in another file. The only somehow useful separation I can see is on the editor type level, not editor instance level, but then it becomes too complicated (e.g. is angular form search typescript type or is it html type).
This is very inconvenient when you replace text in a couple of open files – you replace in one file, come to another and all of sudden search box is filled with different values you searched before may be many hours and even without dropdown for last values. For me it looks very strange, against a common sense the user has for search UI.
> The classical search dialog is a modeless dialog
Sorry not being clear, you are right in the sense that it doesn’t break the functionality, Find dialog indeed stays open. But I think it should not show new search box for other files once Find is shown and they should focus the dialog on CTRL+F once it is open rather than popping new search (again, it comes down to the point that search local state and behavior per editor tab is somehow against common search intuition, mentally one searches multiple files with the same global search box and doesn’t expect it to look or behave differently when switching editor tabs).Fedor,
We are working on adding settings for this for the next release – I agree that what you have described is definitely an important use case.
As far a the regular search dialog, again, that’s a valid point as well – if the regular search is already visible, Ctrl + F again should work with this dialog. However, I had a more general question – do you find yourself using both the inline search and the regular search often? We were thinking of removing the double Ctrl + F functionality due to other side-effects and usability, which means to get back to the regular search, you would most likely have to disable the inline search from preferences, or, make a preference for this Ctrl+Fx2 functionality. We’re curious about your thoughts on this matter.
I use both equally.
For simple search inside single file, the new search is ok and convenient, I like its up/down arrow and match index/count. But it definitely should have value history and (may be setting to) keep last value regardless of editor.
For anything more I switch to old search as new search still lacks usability
– it still misses some preference shortcuts (or I don’t see them in hints)
– new shortcuts do not match classic shortcuts, it is simpler to CTRL+F + old shortcut. I do a lot of other things in classic Eclipse and don’t want to learn thousand Eclipse shortcuts for the same thing
– it can not be moved at all, while old can be moved even outside window to second monitor
– as said it is not reusable between files
– as said sometimes it is quicker to click a button than shortcut but tiny icons are annoying to click. In general, I think that this panel is too miniature and feels really not handy on mouse interaction. In addition, there is a UX bug that only tiny icon area is clickable, there is some space between icon and row boundary that is not clickable.
In general, such small panels should be made that button hover area is maximized, and it can be made clickable even not only on full row height but also half way above and before next row (and when there is no button below or above than on full available height). Enlarge just a bit, make clickable on row height + half padding above and below (and full padding when there is no other button) and I think it will feel way better.So I definitely would prefer some setting that will allow to keep for now using old classic in parallel with new.
Regarding double Ctrl+F, despite sounding awkward, in practice I didn’t find it that disturbing or misleading (except mentioned cross-editor issues).
