Community
Participate
Working Groups
There should be a find/search box widget that supports both the emulated and native controls as the filtered tree does so that it can be consumed by other tools for different purposes so that this implementation does not need to be copied. As Platform will be unable to accept this for Eclispe 3.6 (as per Bug 293230), we should take this widget and make it work within the Mylyn commons while ensuring that it can be applied to platform for the 3.7 stream so it can be consumed.
The initial implementation of this widget has been added to o.e.m.commons.ui (TextSearchControl). It has also been integrated with the EnhancedFilteredTree from Mylyn so that the Task List will have this new widget. The next step is to add a history popup dialog that can be customized by clients of the control.
Created attachment 160558 [details] history patch Here is a patch that adds a popup dialog and history to the find control for the enhanced filtered tree. It also removes the search repository link and moves it to the bottom of the popup dialog. I have committed this change so that we can get some early feedback on its usability (which will need some work to do with the policies for the popup dialog to open and close).
Created attachment 160559 [details] mylyn/context/zip
I realize this bug is mostly about a common implementation of a search box for various uses, but I thought it would be useful to pose a broader question here and point those interested to bug 304440 to continue the discussion. Do you guys have a good sense of the use cases for the idea of a "common search box" in the workbench? In bug 293230, Mik mentioned >One of our key goals at this point is that the >search/find widget that shows in the default perspective of several EPP >distributions, can you point me to which EPP distributions you speak of (or even better, a screenshot?) I have not looked at these search implementations and it would be interesting to learn about them. Also, while discussing a different topic (shell colors, toolbar/menu, etc.), Mik had a mockup that happened to also show a common search bar located in the perspective switcher. This notion is very similar to the visual design work going on for e4, where we are trying to ensure that the new workbench reserves space for a common search area, and are trying to figure out the relationship of this search bar with the toolbar, platform trim, perspective switcher, etc. Of course, where something is located depends largely on what the user intends to do with it, and I've found that that different people have different ideas of what this "common search box" will do. Any info you can provide in bug 304440 (including pointers to related bugs) would be helpful.
(In reply to comment #4) > I realize this bug is mostly about a common implementation of a search box for > various uses, but I thought it would be useful to pose a broader question here > and point those interested to bug 304440 to continue the discussion. > > Do you guys have a good sense of the use cases for the idea of a "common search > box" in the workbench? I will defer this one to Mik, but my opinion is that it would be useful to have an easy way to search for files and provide a way that other search providers could be executed quickly as well (i.e. Mylyn's task search). I don't know what other types of search would be useful as most of the searching that I currently do in Eclipse is either via hot-keys or using filtered trees (which it seems should not be controlled by the common search). > In bug 293230, Mik mentioned > >One of our key goals at this point is that the > >search/find widget that shows in the default perspective of several EPP > >distributions, > > can you point me to which EPP distributions you speak of (or even better, a > screenshot?) I have not looked at these search implementations and it would be > interesting to learn about them. Mik is talking about the filtered tree in the Mylyn Task List view. > Also, while discussing a different topic (shell colors, toolbar/menu, etc.), Mik > had a mockup that happened to also show a common search bar located in the > perspective switcher. This notion is very similar to the visual design work > going on for e4, where we are trying to ensure that the new workbench reserves > space for a common search area, and are trying to figure out the relationship of > this search bar with the toolbar, platform trim, perspective switcher, etc. > > Of course, where something is located depends largely on what the user intends > to do with it, and I've found that that different people have different ideas of > what this "common search box" will do. > > Any info you can provide in bug 304440 (including pointers to related bugs) > would be helpful. This search box that you saw is a web search that is provided by Tasktop.
thanks for the info. So it sounds like most of what's going on here is local-search. And it sounds like the TaskTop web search might be a candidate for plugging into a future common search bar provided in the workbench. Mik, if you have any additional thoughts, please respond in bug 304440 where we are collecting use cases for "common search bar."
(In reply to comment #6) > thanks for the info. So it sounds like most of what's going on here is > local-search. And it sounds like the TaskTop web search might be a candidate > for plugging into a future common search bar provided in the workbench. Yes, this could be a good candidate. One thing that may need to be considered is that each of the search providers may have special options that users could change (i.e. file search may have a name and a contents search). This would mean that there are 2 selections that the user may have to make when using a common search widget.
I have made some usability improvements to this. It now has keyboard navigation and if it isn't open, ctrl+down arrow will open the dialog. Also, the history dialog doesnt open until the user starts typing (not on focus of the text box).
Nice work Shawn. I wish there would be a "hide completed" checkbox, because quite often I can't limit the search too far (mostly because I just don't remember the words used) but know it's an open task... Wonder if the task list would even support that though ;)
We are done with the current implementation. Any future work or bugs will be tracked on new issues.
While this is cool, after a couple of weeks of usage I'm noticing a pretty big usability problem that I don't think we will be able to work around. The popup currently obscures the task IDs and start of the summary of a task, without giving much value over the previous UI (only recent matches). I think we need to revert the implementation until we can address this.
In general, I think that any tool that shows matches should not obscure them when they show. As per the dialog below, let's revert. Shawn: If straightforward, consider inlining the shell's content so that we get to keep the history UI, as long as it's not too weird to have the Task List jump down that far. Fyi, I just checked and Outlook 2010 exhibits exactly the same bug when it's in the mode of doing a Find without requiring you to hit Enter. Could we get a round of votes on wheter we want to revert this? [1:19:59 PM] Mik Kersten: either that or we inline the contents of the shell in the place of the composite that we used to add before. [1:20:00 PM] Mik Kersten: +1 [1:21:35 PM] Robert Elves: I find it combersome and haveing to click next to that dialog to reveal the hit. +1 for doing something about that or reverting [1:22:10 PM] Steffen Pingel: +1 for reverting [1:24:27 PM] Mik Kersten: Shawn? [1:26:49 PM] Shawn Minto: yeah..sure [1:27:46 PM] Mik Kersten: Shawn: whatever is best, just revert, or inline your shell in place of the component that was there. That way you can keep the feature and history. I'll comment on the bug.
I have reverted the change, but left the code for the dialog so if we want to re-integrate it in the future, we can.
Created attachment 171442 [details] mylyn/context/zip
