Community
Participate
Working Groups
build I200303 The font dialog used in the Fonts preference page should not show the colour field (or any other attributes that we do not capture in a font preference). It should be possible to hide the colour field. See bug 4786.
Should also fix up any other refs to FontDialog in the SDK.
This was changed some time ago
How does one suppress now the display of the "Color" field in the FontDialog?
I believe this was closed in error - this dialog still contains the color controls.
Punting to SWT for comment.
Just FYI, the native call on win32 to do this is to not set the CF_EFFECTS bit in the CHOOSEFONT.Flags field. Also note that if an API is added to turn off the color chooser in the dialog, then the FontDialog's setRGB and getRGB API will be ignored. Currently, the SWT FontDialog supports color selection on both Windows and Mac OS X. GtkFontSelectionDialog does not seem to have this capability as yet. I don't have time at the moment to determine whether the Mac Font Panel will allow turning the color selection control off. But perhaps a better API to request would be one that asks the platform if the FontDialog supports color selection. Then if it does, the application would prefer to use the dialog for selecting the color of a font. Currently, Mac & windows would answer 'true' when asked for this feature. On platforms that answer 'false', you could resort to opening up a second dialog for the color selection.
(In reply to comment #6) rning the color selection control off. > > But perhaps a better API to request would be one that asks the platform if the > FontDialog supports color selection. Then if it does, the application would > prefer to use the dialog for selecting the color of a font. Currently, Mac & > windows would answer 'true' when asked for this feature. On platforms that > answer 'false', you could resort to opening up a second dialog for the color > selection. > That doesn't really help the UI case. Our issue is that we (in our themes code) do not tie fonts to colors - having them both in the same dialog is confusing because even if there's a logical connection between a font and a color there is no real connection for us. There's no situation where we'd ever want to see the color chooser in the font dialog in our themes code.
Ah, I see. I had a very quick look at the OS X Carbon Font Panel, and I can't see a way to turn off the color selector. There seems to be a way if you are using QD fonts (set hasColor to false in the FontSelectionQDStyle struct?) but we are using ATSU fonts. SSQ, do you think it is possible to turn off the color selection control in the OS X Font Panel?
I don't think it is possible to remove the color field from the carbon dialog. The field hasColor in FontSelectionQDStyle tells if the color in the struct is valid or not, it does not remove the color field.
I do realize that platforms other than Linux (gtk) have a color selector in their font selector window. The real problem fro me is, how can we develop a cross platform RCP application where we want to be able to select a font and color. Currently we would need to determine the platform we're running on and depending on that, add color selectors to the dialog, form or whatever we use as input. IMHO this is going to be a very ugly if-construct. Eclipse itself is using this FontDialog to change fonts for view tabs or editors, and does not honor the color selection. In fact, the color is taken from, for example; "Active part foreground".
Kenneth, I think I can help your use case. Call fileDialog.open() to get your font, and then call getRGB(). Here's what happens: - on Windows and Mac, getRGB() returns an RGB unless the user canceled the dialog (in which case it returns null) - on GTK, getRGB() always returns null So your cross-platform rcp app can do something like the following: FontDialog fontDialog = new FontDialog(shell); FontData fontData = fontDialog.open(); if (fontData != null) { RGB rgb = fontDialog.getRGB(); if (rgb == null) { ColorDialog colorDialog = new ColorDialog(shell); rgb = colorDialog.open(); } if (rgb != null) { // do something with your fontData and rgb here... } } The javadoc for getRGB() in FontDialog says: * Returns an RGB describing the color that was selected * in the dialog, or null if none is available. Steve, please verify that this was intended to always return null on platforms that do not have color selection in the FontDialog. i.e. Kenneth can rely on this behavior in future - correct? (Sorry, Kim - this doesn't help the UI case either).
Yes, this is the intent. We can talk more about it Monday.
Please note that this must be deferred to 3.5 because the API freeze for 3.4 is past. Summary of platform api for hiding color selector in FontDialog: - Windows: don't set CF_EFFECTS bit in CHOOSEFONT.Flags field - GTK: doesn't currently have color selection in GtkFontSelectionDialog - Mac Carbon: no obvious way to hide the color field in FontPanel - this might prove tricky, but we may be able to reach in and disable it - Mac Cocoa: NSFontPanel validModesForFontPanel: does not set NSFontPanelTextColorEffectModeMask or NSFontPanelDocumentColorEffectModeMask
Is there any plan to add support for disabling the color selector for the windows platform in an upcoming release?
I am building an RCP application and I also would like to disable the color field in the font dialog. Carolyn has indicated that there are straight-forward solutions for Windows, GTK, and Mac Cocoa. Is it feasible to make the API changes in 3.7 and/or 4.1?
Fixed: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=4ce7925a86fe89375303d3ae22e64d3377f63c74 The new API is called setEffectsVisible(boolean) and there is a corresponding getter. Here is the comment for the setter: /** * Sets the effects selection controls in the dialog visible if the * argument is <code>true</code>, and invisible otherwise. * <p> * By default the effects selection controls are displayed if the * platform font dialog supports effects selection. * </p> * * @param visible whether or not the dialog will show the effects selection controls */ Note that if the effects controls are not visible, then getRGB() will always return null. Windows and Mac Cocoa both support selection of "font effects" (underline, strikethrough, color... and on Mac there's also background color and some fancy shadow effects) in their font dialog. Gtk does not. This new API will be in Eclipse 3.8 M3 and 4.2 M3.
I get API Tools warnings for the missing @since 3.8 tags. Maybe your workspace is missing an API Baseline?
Thanks, Markus - I released the @since. New workspace - I didn't have an api baseline set yet. Thanks for the reminder. :)
Fixed
