Community
Participate
Working Groups
Created attachment 212567 [details] screen shot Version: 4.2.0 Build id: I20120312-1200 On the extensions tab next to the filter box there is a shrunk-up version of a search button. See the screen shot.
Besides being too small, the button is out of place. It should probably be moved to the context menu.
Please see Eclipse under Windows as how the button was meant to look. The button should be as high as the filter text but not as wide as the add/remove/up/down buttons in order to hint that the button doesn't work on the selection in the tree. I did test it under SuSE Linux where it was ok. What's your Window Manager with Linux? The Search... can't be in the context menu of the filter text field, because it seems not possible to add items to the default context menu. Removing it would disable the Undo functionality, because that's still not available with Ctrl+Z, the same with Copy/Paste when the plugin is not editable (still a problem). The Search... function shouldn't be in the tree's context menu, because it's someway hidden there. When filtering on the plugin model brings no results, it should be convenient to search other plugins. That's why I placed the button next to the filter text. I could try to fix the button layout.
(In reply to comment #2) > Please see Eclipse under Windows as how the button was meant to look. > The button should be as high as the filter text but not as wide as the > add/remove/up/down buttons in order to hint that the button doesn't work > on the selection in the tree. I did test it under SuSE Linux where it was ok. > What's your Window Manager with Linux? I am using Linux Mint 12 x64, although that *should* not matter. > The Search... can't be in the context menu of the filter text field, because > it seems not possible to add items to the default context menu. Removing it > would > disable the Undo functionality, because that's still not available with Ctrl+Z, > the same with Copy/Paste when the plugin is not editable (still a problem). > > The Search... function shouldn't be in the tree's context menu, because it's > someway hidden there. When filtering on the plugin model brings no results, it > should be convenient to search other plugins. That's why I placed the button > next to the filter text. I could try to fix the button layout. I think that we should remove the search button altogether, as it breaks the common conception of what the tree filter box does. Also I find that the wording of 'Search Related' is confusing as well. You select an item and 'Search Related' only to have it run some magic calculus and then display some results. What is it actually searching? Can I configure it? Can the results be broken down into search result kinds?
Created attachment 212577 [details] screen shot 2 After playing around with it for a bit more I found that after doing a few searches + selections I could cause the toolbar buttons to stop showing up. They did come back after I hover over them. Steps: 1. Select a child element of an extension 2. run 'Search Related' 3. open one of the search results 4. select the root extension element for the matched result in the plugin.xml editor 5. select the filter box 6. hit the 'Search' button 7. watch as the images disappear If it doesn't happen immediately try making some more selections + repeating the steps until it does.
>I think that we should remove the search button altogether, as it breaks the >common conception of what the tree filter box does. Then there will be no entry point to the search. The search button just extends the tree's function. The context menu or the toolbar doesn't feel right to me. But yes, I also haven't seen a filter tree with this kind of behaviour before. >Also I find that the wording of 'Search Related' is confusing as well. You >select an item and 'Search Related' only to have it run some magic calculus and >then display some results. What is it actually searching? If the selection has an attributes of type id, class, commandId, pattern, locationURI, defaultHandler, variable, property, contentTypeId, path, plugin, perspective, targetID the value is added to the filter text. I've tested this with many plugins and found it to match almost all use cases. There is some additional convenience added. If you apply Filter Related to an element of type (test) you will also find the PropertyTester, because the filter text is composed of all combinations from namespace + properties. I will provide documentation for the filtering behaviour. But basically it's searching attributes of the tree elements. >Can I configure it? Not now, but this could be done. If you miss any relations, please tell me. >Can the results be broken down into search result kinds? Do you mean the Search View or the filtered tree? > I could cause the toolbar buttons to stop showing up. I will look into that.
Please see ExtensionsFilterUtil.RELATED_ATTRIBUTES for the current list of attributes. I copied them from an older patch in my previous comment.
Created attachment 212604 [details] Patch for Bug 374096 and Comment#4 The Search button should be sized properly now. Regarding the disappearing toolbar icons, I can't reproduce it on Windows but will try it tomorrow with SuSE Linux. Since I didn't change the original code on these actions I added disabled image descriptors on them as well. Maybe this works. Please test it and let me know if it worked.
The patch fixes the sizing issue, but I'm still not sure about leaving the action in for M6. We should be using 'find' not 'search' and the button looks completely out of place. It has a predominate location and it is not going to get used very often. It also fails to convey to the user what it is doing.
I will change the label to 'Find'. What if the button is only visible when the tree is filtered? Maybe that's even more unconventional... How about adding the function as a toolbar icon again? Originally the Search Related action was the Search button. You thought that was a bug because it was disabled. See Bug 360894, Comment 12. The Search Related action was then only available in the context menu. I changed that by adding the Search button. Maybe the former was better.
(In reply to comment #9) > I will change the label to 'Find'. > What if the button is only visible when the tree is filtered? Maybe that's even > more unconventional... > How about adding the function as a toolbar icon again? > Originally the Search Related action was the Search button. You thought that > was a bug because it was disabled. See Bug 360894, Comment 12. > The Search Related action was then only available in the context menu. > I changed that by adding the Search button. Maybe the former was better. "Find" is wrong because as it opens the Search view. I agree with Michael that the button should go away. The user (i.e. I) has no clue what it actually searches and what the input for the search is.
(In reply to comment #10) > "Find" is wrong because as it opens the Search view. In other places in PDE we use "Find references" "Find declarations" which opens up the search view. "Find broken unexternalized strings" in the java editor opens the search view I can work with either, but I would prefer it to be consistent.
(In reply to comment #11) > (In reply to comment #10) > > "Find" is wrong because as it opens the Search view. > > In other places in PDE we use "Find references" "Find declarations" which opens > up the search view. > > "Find broken unexternalized strings" in the java editor opens the search view > > I can work with either, but I would prefer it to be consistent. I see. "Find" is normally used to search within one editor and "Search" goes beyond. For M6 I would just remove the button.
> The user (i.e. I) has no clue what it actually searches and what > the input for the search is. Since the button is enabled only when the tree is filtered and the tooltip describes its function, it should be clear that all platform plugins are filtered with the current filter text. This is a shortcut for finding attributes within the platform and displaying the results quickly in the extensions tree. Please test this feature with a RCP application that uses the Command Framework and shares definitions and usages of lots of elements (commands, handlers, activities, property tester, menu contributions) between plug-ins. This gets quickly confusing and hard to manage. The Search button doesn't has to be there but its function is inevitable because Search Related only applies certain attributes to the search, which includes many use cases but not all. Searching with the current filter text should be possible as well. I'm aware that the whole feature is a bit fancy but has proven helpful at least at the company I'm working for. Could we get some external opinions before constraining the feature? Please see also Bug 360894.
(In reply to comment #13) > > The user (i.e. I) has no clue what it actually searches and what > > the input for the search is. > > Since the button is enabled only when the tree is filtered and the > tooltip describes its function, it should be clear that all platform > plugins are filtered with the current filter text. > This is a shortcut for finding attributes within the platform and > displaying the results quickly in the extensions tree. > > Please test this feature with a RCP application that uses the Command > Framework and shares definitions and usages of lots of elements > (commands, handlers, activities, property tester, menu contributions) > between plug-ins. This gets quickly confusing and hard to manage. > > The Search button doesn't has to be there but its function is > inevitable because Search Related only applies certain attributes > to the search, which includes many use cases but not all. Searching > with the current filter text should be possible as well. > > I'm aware that the whole feature is a bit fancy but has proven helpful > at least at the company I'm working for. Could we get some external > opinions before constraining the feature? Please see also Bug 360894. Yeah, I tested it and also read the tool tip but this only says "Search with current filter". I have no clue "what" is searched and if you need to explain it first, then something is fishy wit the UI.
For M6 I have removed the button. We can figure out something more user friendly in M7.
(In reply to comment #15) > For M6 I have removed the button. We can figure out something more user > friendly in M7. Verified in I20120314-1800.
(In reply to comment #15) > For M6 I have removed the button. We can figure out something more user > friendly in M7. Version: 4.2.0 Build id: I20120315-1300 In Linux there is no longer a border on the Extensions list - on windows there is a border (did not check on Mac). Also in Windows the buttons on the Extensions tab do not align with the top of the extensions list, while in Linux they do.
fixed the no-border cheese in the extension editor: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=408550c2bf69fd1bc25408b6e91034bfd96c169d
I've pushed some significant cleanup to master. - Removed the search functionality entirely. There is no satisfactory way of conveying information to the user on what it is doing. - Cleaned up the filter related option. Removed it from the top level toolbar. Removed the ShowAllExtensions action and replaced it with a menu option to clear the current filter. - Updated the remove action to have an icon. - Removed the commented out code and unneeded classes/icons. After 4.2 is released I would be willing to consider alternate ways to provide the functionality, but there is no currently no time for the committers to work on it.
> Removed the search functionality entirely. Does this include "Search related" from the context menu as well?
(In reply to comment #20) > > Removed the search functionality entirely. > > Does this include "Search related" from the context menu as well? Yes, all actions that open the search view have been removed.
Verified in 4.2-N20120415-2015.
