Community
Participate
Working Groups
HEAD, follow-up to bug 141690 The "Feel" of FilteredTree is still suboptimal: 1. When the filter text is "type filter text", the eraser is not visible (even if nothing is selected). The eraser should always be visible, unless the field is empty. 2. Selecting the initial "type filter text" in the field feels like a hack. The look and feel of the filter field should be aligned with how this is commonly done in modern UIs (Firefox, Web 2.0): - when the filter field is empty and does not have focus, the "type filter text" message should be rendered in gray - when the filter field is empty and has focus, the "type filter text" message should be removed and the text color should be reverted to black
This would probably also solve bug 161245.
Sorry but I don't have the time to follow up on this. We may end up having to pull this out again because of bug 257175.
> - when the filter field is empty and has focus, the "type filter text" message > should be removed and the text color should be reverted to black E.g. in the Preferences dialog, the filter field has focus initially, so this strategy would also hide the "type filter text" message initially. If we want to keep reusing the empty filter field as label to describe its functionality, I guess the message needs to be visible also when the field has focus. A better strategy would be: - When the filter field is empty and has focus, the "type filter text" message should be gray and the caret should be at the beginning of the field (and stay there, even if the user tries to move it or set it somewhere else). When the user types the first character, the message should be removed and the text color should be reverted to black.
>Sorry but I don't have the time to follow up on this. Boris, I could do this but given that almost everything in that class is API the only way to fix this is to introduce a new constructor and to provide the new LAF as new feature i.e. those that want it need to tell us. The code then has to implement that flag correctly. Let me know what you think.
Discussed this with Boris ==> we will keep the old LAF (with new button for now; can revive old button if needed) so that clients aren't broken but offer new constructors to use the new look. I'll do that tomorrow and then we each client can decide whether to port to the new look.
I have fixed the subclass breakage of FilteredTree in HEAD and ported the preference dialog's search field. You can now look at old and new look: new look: Window > Preferences old look: Window > Show View > Other... Note that for a start I kept the new icon (it has same size but is aligned a bit differently). Since it is transparent it looks quite good even with old look, especially for views that use white as background, e.g. Plug-in Registry view. If you think we should also bring back the old look image then I can do this. Boris, please take a look. If you are happy we should send out a note that clients should port to new look by using one of the new constructors. And we could also put this into the N&N and mention it in the porting guide.
>1. When the filter text is "type filter text", the eraser is not visible (even >if nothing is selected). The eraser should always be visible, unless the field >is empty. Nope, it should not be visible out of the box, however, when the user changes the initial selection in the field it should simply clear the field. This however, is harder than it should be due to bug 4655. >A better strategy would be: >- When the filter field is empty and has focus, the "type filter text" message >should be gray and the caret should be at the beginning of the field Looking at Web and other UIs I have never seen a field with focus + caret + gray hint inside the text. Normally, focused widgets in the Web give the hint via tool tip but in Eclipse we have the rule to not use tool tips on entry fields. In addition we can't hard-code the hint color to gray as people might use work with different color schemes. We should simply put a search icon on the left side and move the hint text from the field to the tool tip of the search icon. This would also solve 1) and bug 161245. What do you guys think?
(In reply to comment #7) Sounds good. For the Mac, we would need new API from SWT to show the native magnifying glass inside the SWT.SEARCH | SWT.CANCEL Text.
>For the Mac, we would need new API from SWT to show the native >magnifying glass inside the SWT.SEARCH | SWT.CANCEL Text. Steve would that be something SWT could do?
(In reply to comment #7) > We should simply put a search icon on the left side and move the hint text from > the field to the tool tip of the search icon. This would also solve 1) and bug > 161245. > > What do you guys think? It seems that you are trying to emulate even more of the search field behaviour that is available natively on some platforms (e.g. Mac Carbon and Cocoa, not sure if there are others). Wouldn't it be better if all of this code lived in SWT instead?
No objection there ;-)
*** Bug 185693 has been marked as a duplicate of this bug. ***
I've fixed this now for the new look style. Other things we could do to improve: - bug 260371: Show search icon and get rid of initial text when focused - bug 260373: Use Text.setMessage(...) where supported
Verified on WindowsXP and Linux-GTK. Markus, can you verify on Mac? Thanks.
Is also great on the Mac.
