|
Hi Eugene,
I think that Wind River's solution works quite well for
this requirement, since
any search participant can continue using the separated
dialog / results
metaphor.
Only those kinds of searches for which it makes sense to
integrate results
with query (currently, text search only) can use the
integrated results pane.
One option for a more general solution for complex searches
as well might
be to make the search dialog available from the results
pane like a fastview
(rather than forcing the user to use a kbd shortcut or walk
through the menu).
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Eugene Kuleshov wrote:
One thing
to take into consideration when generalizing search UI for embedding into
Search view is how it is going to scale for complicated search criteria. For
example, below is the search query configuration dialog used by Mylyn
connector. As you can see, it need much more screen real estate then simple
textual search.
Sorry, forgot the
attachment.
regards,
Eugene
Oberhuber, Martin
wrote:
Hi all,
it's some time since these
discussions were held, but I only found them today.
FYI,
Wind River has indeed adopted the new APIs put in place in the course
of working on _https://bugs.eclipse.org/bugs/show_bug.cgi?id=118200_
What we currently have is a variant of the Search Results
UI in our
commercial products, that lives side-by-side with the
classic Eclipse
Search Results UI but can use the search engine. We
currently don't
use tweaklets, but have the appearance of the Search
Results UI
depend on the kind of search that was made -- just like
"Java Search"
and "C++ Search" produce different kind of results in
the same Search
Results View, a Wind River Text Search will produce
results in the
Search Results View that have the additional UI
controls beside it.
Our current code is is essentially an
evolution of the patches made public
under EPL in bug 118200. See
attached for some screenshots.
I personally use this every
day, and couldn't live without it. There is
some killer features of
having the search results integrated with the
controls:
*
Ability to
change / refine / fix a search very quickly in case
there was a typo and the search results
are not as expected (see
screenshot 1:
e.g. change "whole word" match by "regex" match)
*
Ability to perform interactive
2nd-stage-filtering on the search
results (see screenshot 2) -- results change based on filters
just as I apply them.
*
Ability to manually remove items from
the search results BEFORE
a replace
operation is made on the remaining items to be
replaced -- I can directly preview the
matches to take part in
replace, select
them 1-by-1 and preview what replacement is made
(especially helpful if doing Regex
backreference replacements --
see
screenshot 3).
The evolution that we have made commercially,
compared to what's already
attached on the bug, was mostly bug fixes
plus minor enhancments such as
color highlighting of matched pattern
in the results tree -- so, It's not unlikely
that somebody picking up
the patch could come up with similar screenshots
quite easily.
We'll happily take part in any discussions when this topic
is picked
up again, please keep us in the loop with any work going on
in this
direction.
Thanks,
--
*Martin
Oberhuber*, Senior Member of Technical Staff, *Wind River*
Target
Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
ui-best-practices-working-group mailing list
ui-best-practices-working-group@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ui-best-practices-working-group
|
