Community
Participate
Working Groups
F2 1) Window>Preferences>Debug>Console>Text Font>Change (pick any) OK 2) Window>Preferences>Debug>Console>Text Font>font setting Change is not remembered
This is working for me.
Still does not work for me if I simply choose the font that the font selection dialog opens with. Trebuchet MS Bold 9 This is on XP Cannot reproduce on Nick's XP machine Cannot reproduce on my Linux or win2000 machine Should investigate post 2.0
*** Bug 19483 has been marked as a duplicate of this bug. ***
This is likely due to our font specification format not beign robust enough.
The format also needs to handle color as FontData is now accessible from the dialog.
*** Bug 2708 has been marked as a duplicate of this bug. ***
See FontDialog.getRGB and FontDialog.setRGB
Cannot replicate in 20020903 on XP. Changing PR to a feature request for color support in fonts.
*** Bug 24645 has been marked as a duplicate of this bug. ***
I can reproduce it with 3.1 final - on 3.0, I use very small courier font, and this setting was remembered. After clean install of Eclipse 3.1 and setting the smaler font size (and/or another font), this setting will be accepted only for the current session. Next time I start Eclipse, the console font is reset to the default size/font. Moreover, the setting of the color for the console seems to be completely broken in 3.1 - I could not change the font color. Another question - why is this bug marked as enhancement? Now, with 3.1, this is a regression comparing to 3.0.
This bug is really old and is requesting that the colour setting from the font chooser dialog is honoured. If you're having problems with your settings not being remembered, and it is a regression from 3.0, I would recommend filing a new bug.
Sorry, I was thinking this is a similar problem - because the font color for the console should be changed/remembered in the same dialog. I have filled the bug 103907.
One of the problem with using the color methods on FontDialog is that they aren't adequately supported on every platform.
*** Bug 168405 has been marked as a duplicate of this bug. ***
This is a really old bug and comment 13 suggest this to be a limitation of the FontDialog but I cannot confirm this. The following code: FontDialog fd= new FontDialog(shell); fd.open(); RGB color= fd.getRGB(); System.out.println(color); fd= new FontDialog(shell); fd.setRGB(color); fd.open(); Correctly opens the second font dialog with the chosen font color which means the font dialog can handle this. In addition I could not find a comment regarding a platform limitation in he Javadoc of FontDialog. Adding Steve to confirm. How would we get/assign the color for a Font? Is that even possible? I couldn't find any method that would do this. So maybe JFaceResources needs to offer additional methods to query the font color for those fonts.
*** Bug 175358 has been marked as a duplicate of this bug. ***
Is there a resolution to this bug? When I attempt to change the color of the text in the java editor via: Window -> Preferences -> General -> Appearance -> Colors and Fonts -> Java -> Java Editor Text Font the changes in color are not honored. Changes in font/typeface are. OS: XP SP2 Color Scheme: High Contrast Black Eclipse: Version: 3.2.2, Build id: M20070212-1330 Cheers Lawrence
We wont have a resolution for this until at least 3.4.
*** Bug 214371 has been marked as a duplicate of this bug. ***
*** Bug 218261 has been marked as a duplicate of this bug. ***
*** Bug 227619 has been marked as a duplicate of this bug. ***
i am surprised by the comments that this is an old bug. i only recently updated to 3.3.2 (from 3.3.0) and only after updating do i see this. if i run my previous installation the selected font colors are honored. i also didn't think this was a duplicate, as my settings for the console font color are honored - it is within the editor that font colors are not correct.
Kim, please find me and Carolyn and let's figure out what to do.
(In reply to comment #23) > Kim, please find me and Carolyn and let's figure out what to do. > I'll be by after lunch.
Summary of our discussion: SWT is providing functionality (the color in the font dialog) that UI cant consume in the 3.4/3.5(?) timeframe. API to disable this functionality (removing or disabling the color controls) should be considered. UI will investigate better integration of fonts and colors (and use of this functionality) in the future (3.5 or 4.0). This request has already been captured in bug 35890.
OK - But if this is an old bug (circa 2003) why did my 3.2.0 installation work correctly? Between both 3.2.0 and 3.3.2 I could select for example courier 9pt font, blue for both the console and editor. When I started 3.2.0, the font in both the console and editor were blue. When I start 3.3.2, the console font is blue, the editor font is black. Perhaps I don't understand your explanation... Looking forward to 3.5/4.0.
(In reply to comment #26) > OK - But if this is an old bug (circa 2003) why did my 3.2.0 installation work > correctly? > > Between both 3.2.0 and 3.3.2 I could select for example courier 9pt font, blue > for both the console and editor. When I started 3.2.0, the font in both the > console and editor were blue. When I start 3.3.2, the console font is blue, > the editor font is black. > > Perhaps I don't understand your explanation... Looking forward to 3.5/4.0. > We're asserting that the color selection control in the system font dialog (utilized by the Color and Fonts preference page) has NEVER been used. Selecting a color by the dialog should have never worked. If this was ever the case I would be incredibly surprised - the only way this could happen is if the color info was somehow embedded in the font info in SWT. We never made use of the getRGB() method on the FontDialog.
(In reply to comment #27) > (In reply to comment #26) > > OK - But if this is an old bug (circa 2003) why did my 3.2.0 installation work > > correctly? > > > > Between both 3.2.0 and 3.3.2 I could select for example courier 9pt font, blue > > for both the console and editor. When I started 3.2.0, the font in both the > > console and editor were blue. When I start 3.3.2, the console font is blue, > > the editor font is black. > > > > Perhaps I don't understand your explanation... Looking forward to 3.5/4.0. > > > > We're asserting that the color selection control in the system font dialog > (utilized by the Color and Fonts preference page) has NEVER been used. > Selecting a color by the dialog should have never worked. If this was ever the > case I would be incredibly surprised - the only way this could happen is if the > color info was somehow embedded in the font info in SWT. We never made use of > the getRGB() method on the FontDialog. > Actually, hold up on that. I may be full of the smelly brown stuff. A little birdie has told me that we may have embedded color info in the font descriptors at some point in our past. I am going to dig into this further.
I've just tried setting the font color on Eclipse 3.2 - I can't reproduce the behaviour you're describing. The font color is ignored in every case - it is not persisted between invocations of the dialog.
Susan is now responsible for watching the [Themes] category.
*** Bug 313203 has been marked as a duplicate of this bug. ***
*** Bug 339283 has been marked as a duplicate of this bug. ***
(In reply to comment #32) > *** Bug 339283 has been marked as a duplicate of this bug. *** All, what's the status of this one? Just counted at least 6 duplicates so it seems to be a high-priority one, is there any chance we'll get this fixed in 3.8, or is it already? Thanks! :) Helmut
For bug 35890, I am adding API to FontDialog to optionally turn off the color, strikeout, and underline controls (collectively called "effects") in the FontDialog. On Mac, this will turn off the color, strikeout, underline, and shadow controls. On Linux, this will do nothing because the GTK font dialog does not have any "effects" controls. The API will probably be called FontDialog.setEffectsVisible(boolean), with a corresponding getter. The default is to leave the effects controls visible. Note that this means that a call to getRGB() will always return null (and a call to setRGB(RGB) will do nothing) if the effects controls are not visible. Note also that "effects" are not separately available via FontData API, however they are available via TextStyle API. Eric, does 4.x still store font color separate from the font?
API to turn off the "effects" controls (including the color control) has been added to the font dialog. Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=35890#c16 for details.
Carolyn, is there anything we need to do on our side or can we close this one ?
Sorry, Eric - you've still got a bit of work to do <g>. Anywhere you open a FontDialog, you need to decide whether you want to call fontDialog.setEffectsVisible(false) before opening it. i.e. anywhere that you do not call fontDialog.getRGB() after the dialog returns the font to you. i.e. pretty much every FontDialog in the UI, I believe? *Unless* you have changed or are planning to change the way the UI gets and stores a font and its color? The Eclipse 3.x UI stores font/fontColor separately, and therefore doesn't use any color that may be selected by a user in a FontDialog. But if font-and-its-color are stored together in 4.x then you may not need to do anything.
Sorry, I missed most of the history for this defect so I'm still trying for figure out what needs doing...under what circumstances would I decide to use/not-use the new API ? My current guess is that if the 'attribute' that I'm calling it for has a storage location for color... (aka 'effects'...;-) then I leave it on and change the code to pick up all the info and if I only have a storage spot for face/size then I should use 'setEffectsVisible(false)' since I've got no place to store the changes should they make any ?
Created attachment 204033 [details] preferences -> general -> appearance -> colors and fonts (In reply to comment #38) That sounds about right. However, now that I actually go and look at the preferences dialog under: preferences -> general -> appearance -> colors and fonts I am beginning to suspect that you will likely find that you want to just turn off effects for every font dialog. There are very few fonts that have a corresponding color, and of those few, there is already a way to change the color using a ColorDialog. For example, in the attached screen snap there is a CVS font called Outgoing Change that allows changes to the foreground and background color of the font. If the user does this using "effects", then on Windows they can only change the foreground color of the font, and on Mac they can change the foreground and background, but on gtk, they can't change the colors at all using the FontDialog, so you would need to keep the ColorDialog, so it is rather pointless letting the user change the color in the FontDialog at all. (I think).
Actually, looking at bug 35890 comment 7, I see that Kim H said: "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." So this is probably the little piece of history that you were searching for. <g>
Thanks Carolyn... Susan, are you still dealing with defects in this area ?
(In reply to comment #41) > Thanks Carolyn... > > Susan, are you still dealing with defects in this area ? I am still the watcher of theme bugs (for lack of another owner) but no plans to work in the 4.x stream, and no experience/history in the themes code. It would be best to have someone working actively in 4.x stream handle this... That said, I agree with the conclusion here. We just want to use the new SWT api to turn off the effects on the font dialog.
Carolyn, when did this api go into SWT ? I just tried to use it to fix our FontsAndColors preference page but didn't see it (I'm using 20110920).
0922 <g>
> We just want to use the new SWT api to turn off the effects on the font dialog. +1. R3_development: commit ad794830c18bbd0d713c551fad3d036eddd65825 R4_development: commit 3af07ab976f0b27d109995511d199f46e6f813a7
Thanks Dani !
(In reply to comment #46) > Thanks Dani ! CQ:WIND00097282 Thanks for fixing this one !:) Helmut
Verified in 3.8-I20111025-1800 and 4.2-I20111018-2000.
