Community
Participate
Working Groups
I only discovered there was content assist by reading the N&N. It would make sense to show the same decoration as used in other places that support content assist.
It was decided not to show a content assist decoration to avoid cluttering the UI. We can reconsider but I'm inclined to mark this as won't fix.
agreed - I tried it out and it really detracts from the UI
Created attachment 212155 [details] screenshot Here's a screenshot just to make sure we're talking about the same thing. I don't understand how this is any worse than all the other places the icon is shown. It would only be visible when typing in the find box. I think it's worth showing it to have UI consistency and discoverability of features. The checkbox to only search the summary causes more clutter IMO.
If we don't want to have the icon, we should at least consider a tooltip on the find box, although that actually creates more clutter in a way.
Thanks for the screenshot. The icon looks restrained to me. The fact there is already a lot of UI clutter in Eclipse isn't a great argument to add more but I have added this bug as a UI review item for the upcoming Mylyn call to discuss the proposed change.
I guess I do see your point. I still think it's bad not to be consistent, and to hide such a useful feature. Another option would be to display the content assist as soon as the user first clicks in the find box, as some plugins do, but I'm not sure that would be better.
Yet another option, longer term, is to have some sort of callout to open an "advanced" find dialog which would make it easier to see what is supported. The real purpose of the dialog would be to provide a wider search box and perhaps to show the results in the search view.
We decided to try this to make content assist more discoverable. Sam, can you commit your change to master and add a 1 or 2 px margin to the left of the light bulb?
I have not made any change. The screenshot I attached was just a mockup.
Excellent artwork :). I'll grab this then.
See the attached context - the code is in there, just commented out.
Created attachment 212337 [details] mylyn/context/zip
The decoration is now shown when the search field has the focus. David, you can pass a boolean parameter to ContentAssistCommandAdapter to install the decoration which saves a few lines of code.
Created attachment 212483 [details] clipped icon. I like the idea of showing the icon in the search field, I think, but the icon is clipped.
Also, the tootltip says "Content assist available (null)"
At this point we can't make any non-standard UI changes of that sort.
I didn't realize it was standard for the tooltip to say null. ;)
(In reply to comment #13) > David, you can pass a boolean parameter to ContentAssistCommandAdapter to > install the decoration which saves a few lines of code. Thanks Steffen, I wasn't aware of that API. Much cleaner.
(In reply to comment #17) > I didn't realize it was standard for the tooltip to say null. ;) Feel free to commit a fix. I took a quick look and it wasn't clear to me why the command handler binding didn't set the tooltip as expected.
The problem is that the binding service hasn't been initialized yet when the decoration is created on startup. If you close and reopen the task list the tooltip is set correctly. Wrapping the call to adaptTextSearchControl in an asyncExec would fix it, but it also causes the decoration to be drawn to the left of the text field.
Created attachment 212672 [details] mylyn/context/zip
it's normal for the decoration to appear to the left of the control
Nice find. That seems simple enough that we should go with the asyncExec(). I'll make that change once bug 373178 is resolved.
(In reply to comment #22) > it's normal for the decoration to appear to the left of the control I assumed it was deliberate that it doesn't in this case. With my suggested change, there may need to be some padding added because the decoration is partly obscured by the border of the text field.
I didn't realize the screenshot depicted an actual problem on Windows. I'll look into a fix.
Ahhh. I didn't realize you thought that was a suggestion.
I have pushed a fix for the margin. The icon is now shown inside the text field on Windows and to the left on other platforms. Leo, can you verify what it looks like on Mac? The asyncExec() tweak doesn't work all the time but it seems to improve behavior in some cases. I did notice though that if the the Task List view isn't visible on startup and then made visible the decoration isn't shown if the find field is focused shortly after making the view visible. Please comment if you have other suggestions how to address this.
Created attachment 212738 [details] task list search decorator
Thanks Leo! That looks reasonable.
