Community
Participate
Working Groups
JDT currently provides preferences for content assist popup colors, auto-activation delay time, etc. Platform Text implementations typically hard-coded these values (such as auto-activation delay). The new field assist support generally attempted to mimic the defaults used by platform text. However it is reasonable in the long run to provide preferences for these values. Examples include: - main popup color - secondary popup color - autoactivation delay When this is investigated, check for the state of the art in JDT prefs.
This message is part of a mass update...the bug is likely legitimate, but not a priority. Marking P5. Patches would be entertained.
As a first step we could "move" the color definitions from JDT UI to Platform UI or IDE and use the 'Colors and Fonts' preference page. Adding a new General > 'Content Assist' page might be an overkill at this point. If you agree I can come up with a patch.
I think that's a good start. Thanks, Dani...
Providing the preferences wouldn't help much as JFace can't access those and even worse there's no API which clients could use to set them. Something like ContentAssistCommandAdapter could initialize the color but this clas also in the wrong layer. We would need to put e.g. DefaultContentAssistAdapter or WorkbenchContentAssistAdapter into org.eclipse.ui. ContentAssistCommandAdapter should be changed to allow subclassing so that the new content assist adapter can inherit from it. Moving back to inbox as Platform UI should decide how they want to expose the new API(s).
I'll look at this during M2
moving to M3, I'm busy with some other items for M2.
*** Bug 195955 has been marked as a duplicate of this bug. ***
did not make it into M3.
This should be straightforward, I'm just not so familiar with the theme/color stuff. Kevin, can you provide some guidance as to how/where the actual prefs are defined? I could do whatever restructure in the field assist code was necessary to have a platform UI class that honors those colors.
Fixed in HEAD. Dani, sorry this is coming in so late in M6, but I had to squeeze it in for API freeze. Hopefully you'll have time to adapt to these preferences for M6. JFacePreferences now defines colors for: CONTENT_ASSIST_FOREGROUND_COLOR CONTENT_ASSIST_BACKGROUND_COLOR CONTENT_ASSIST_INFO_FOREGROUND_COLOR CONTENT_ASSIST_INFO_BACKGROUND_COLOR These colors are initialized in the JFace color registry by the current theme and appear alongside the other misc. workbench colors on the Appearance pref page. They can be accessed from JFace code using: JFaceResources.getColorRegistry(). get(JFacePreferences.CONTENT_ASSIST_FOREGROUND_COLOR); ContentProposalPopup uses CONTENT_ASSIST_FOREGROUND_COLOR and CONTENT_ASSIST_BACKGROUND_COLOR. PopupDialog, and therefore the secondary content assist info popup, use CONTENT_ASSIST_INFO_FOREGROUNDCOLOR, etc. Consumers of these classes such as the find/replace regexp fields will honor the prefs for free. However, platform text content assist will need to be changed to consult these prefs. Kim/Tod - I assume there is no need for a high contrast override to these colors because they are using system colors (list foreground/background and info foreground/background) for the defaults. ThemesTestSuite still passing. I opened bug # 223251 to track the lack of a content assist delay preference.
A PopupDialog is not tied to content assist. Either remove the code that uses that color or rename those preference constants to something more generic (preferred), e.g.: JFacePreferences.INFO_FOREGROUND_COLOR JFacePreferences.INFO_INFO_BACKGROUND_COLOR The content assist bg label should be without "text": ==> Content Assist background color Another question is whether we also want to use the info color for hovers (tool tips). In that case the description should be adapted. Also, could you remove the preference UI for M6 as several plug-ins are affected and clients won't have time to updated all their code for M6.
>A PopupDialog is not tied to content assist. Either remove the code that uses >that color or rename those preference constants to something more generic >(preferred), e.g.: > JFacePreferences.INFO_FOREGROUND_COLOR > JFacePreferences.INFO_INFO_BACKGROUND_COLOR I originally agreed with your preferred suggestion - rename to be more generic, as my intention was to apply the color to all info popups. But after setting the colors set to something extremely bright, it emphasized for me that it's a bit random to have some things popping up in my bright color, and other things not. I think it's better to direct these color preferences only at content assist. The problem I see is that not every info popup is implemented with PopupDialog, and some of the popup dialog implementations (like the key assist dialog, quick type hierarchy, etc.) are heavyweight enough that they don't necessarily feel like info popups. I think it would be kind of random that some of the popups use the pref color, and some don't, depending on how they are implemented. And as you mention, then we have to decide about hovers, find the various private implementations of hovers and use the color, etc. etc. So...I've kept the preference names as is and changed the code so that PopupDialog continues to use the SWT.INFO_* colors for the default rather than the content assist preference, and only the secondary content proposal popup uses the CONTENT_ASSIST_INFO_* pref colors (which default to the SWT.INFO_*). >Also, could you remove the preference UI for M6 as several plug-ins are >affected and clients won't have time to updated all their code for M6. The UI in the preference page is "free" if you define the colors in the workbench theme. So what I've done to buy clients time to adapt is add temporary code in JFaceResources to initialize the colors when the color registry is created. This code will be removed as soon as M7 ships and the colors returned to the theme. I'll attach the patch to this bug and revisit in M7. >The content assist bg label should be without "text": >==> Content Assist background color This was intentional to keep the colors sorted together, otherwise the content assist info colors and regular colors were separated in the list. In the patch I'll address this a different way.
Created attachment 93061 [details] patches to restore content assist colors to workbench theme This patch will be applied early M7.
>The UI in the preference page is "free" if you define the colors in the >workbench theme. No need for hacks/workarounds. Simply add isEditable="false" to the contribution in the plugin.xml.
>So...I've kept the preference names as is and changed the code so that >PopupDialog continues to use the SWT.INFO_* colors Fine with me. I will adopt the prefs in M7 and inform the other clients.
The content assist colors have been added back to the pref page >20080331. Marking this fixed.
This fix misses to set good colors for the 'Reduced Palette' theme. Filed bug 225303 for that. Verified that this bug here is fixed.
For those listening to this bug: the new color constants for the additional info colors: JFacePreferences.CONTENT_ASSIST_INFO_FOREGROUND_COLOR JFacePreferences.CONTENT_ASSIST_INFO_BACKGROUND_COLOR have been removed during M7 (see bug 225718 for details).
