Community
Participate
Working Groups
M2 PreferencePage.createNoteComposite create a 'Note' remork for preference pages: - Note does not adapt to the dialog font when changed. e.g. set dialog font to size 14: all 'Note:' labels still have the old font - createNoteComposite sets SWT.WRAP but the label passed is not wrapped (i guess the width hint is required, but can't be set on the parent composite)
The first problem is a non issue as it does not use the dialog font - it uses the header font. The composite sets using SWT.NONE - here is the code for the label new Label(messageComposite, SWT.WRAP);
a.) are you sure? I just set the dialog and the header font to something big (24 pixel). When looking at the Appearance preference page, all fonts are big, except the 'Note:' label. b.) It's about the note composite I create using 'createNoteComposite': The 'message' that I pass in is longer and should be wrapped. Note that you are creating the label, not me. (line 582) Maybe I completly misunderstood you, but I would suggest to reopen the bug.
Yes - it is the banner font not the header font (sorry my mistake). Just be sure to close the dialog and reopen - we don't apply the fonts to other pages right away due to sizing problems it can create.
It's the banner, you're right. I have to say that I would never had guessed that I have to change the banner code and keep it 'in sync' with the dialog font for the 'Note:'. So maybe tyhis is not the most optimal solution. Couldn't you take the dialog font and make it bold? If it's already bold it doesn't matter.
No you can't as there are many fonts that have no bold value (Asian fonts for instance).
My suggestion would have been to have the normal dialog font in that case.
(In reply to comment #6) > My suggestion would have been to have the normal dialog font in that case. I'm inclined to agree with Martin here (I just noticed this bug last night). I think it's strange that all your fonts are one size but then the one label control is another. Besides the fact that it updates itself based on the banner's font, it's currently set to start off with JFace's "default font". So first it's the default font, then if you change the banner font, your label will suddenly alter itself to the banner font.
The current solution does not work and gives a bad UI when users change their dialog font (see attached picture).
*** Bug 28428 has been marked as a duplicate of this bug. ***
Created attachment 126813 [details] Picture showing the problem
*** Bug 94681 has been marked as a duplicate of this bug. ***
It does look weird when the two fonts are not in sync. Do we need an additional "bold dialog font", just for this case?
>Do we need an additional "bold dialog font", just for this case? I think that would be overkill. I would set the bold style on the existing dialog font and live with the case where this is not available. Another approach would be to use another font (like banner) and set the height to match the dialog font's height.
(In reply to comment #13) > I would set the bold style on the existing dialog font and live with the case > where this is not available. Another approach would be to use another font > (like banner) and set the height to match the dialog font's height. I agree. It's bad typography design to mix too many font types. Because of the proximity of the word "Note" to the rest of the text, visually the best choice is to use the same font then live with lack of bolding on some char sets. This seems a better strategy (typographically) then picking banner or some other font and hoping they look ok side by side. Linda, would you agree?
yes agree.
Fixed in HEAD. Available in build > N20090423-2000. I also removed the code that updates the label's font on the fly because 99% of the preference pages don't update themselves on font change once they have been created.
(In reply to comment #16) > Fixed in HEAD. > Available in build > N20090423-2000. Thanks Dani. > I also removed the code that updates the label's font on the fly because 99% of > the preference pages don't update themselves on font change once they have been > created. Makes sense yes.
Verified in 0428-0100 in XP English.
