Community
Participate
Working Groups
Created attachment 265417 [details] Java > Code Coverage preference page Said preference page does not react to changes in dialog font size. See the attached screenshot. FYI, it's probably enough to add a single Dialog.applyDialogFont to the end of createContents.
Needs to be checked for all EclEmma dialogs.
(In reply to Marc R. Hoffmann from comment #1) > Needs to be checked for all EclEmma dialogs. Yes, the preference page was just the one I noticed this on first. FYI, if you check this for other dialogs as well you should set the Banner Font, Title Font, and Text Font to something distinctive as well.
(In reply to Andreas Sewe from comment #2) > Title Font Can't find in Neon.1a Release (4.6.1) Build id: 20161007-1200 guess it is "Header Font".
(In reply to Marc R. Hoffmann from comment #1) > Needs to be checked for all EclEmma dialogs. FWIW to me seems that only merge dialog properly reacts on changes.
(In reply to Andreas Sewe from comment #0) > FYI, it's probably enough to add a single Dialog.applyDialogFont to the end > of createContents. Addition of Dialog.applyDialogFont works like a charm on Linux, but not on OS X and additional changes lead to a very strange results - see https://github.com/eclipse/eclemma/pull/13 Andreas, maybe you saw this in past? and can give me a hint?
(In reply to Evgeny Mandrikov from comment #5) > (In reply to Andreas Sewe from comment #0) > > FYI, it's probably enough to add a single Dialog.applyDialogFont to the end > > of createContents. > > Addition of Dialog.applyDialogFont works like a charm on Linux, but not on > OS X and additional changes lead to a very strange results - see > https://github.com/eclipse/eclemma/pull/13 > > Andreas, maybe you saw this in past? and can give me a hint? I work mostly on OS X and haven't seen this problem with Dialog.applyDialogFont before. Here's what we (Code Recommenders) do in FieldEditorPreferencePages [1] and "normal" preference pages [2]. From looking at your CoveragePreferencePage [3], it looks like you should call invoke applyDialogFont on getControl, but that's just based on pattern matching. But maybe that helps. Andreas [1] <https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/plugins/org.eclipse.recommenders.completion.rcp/src/org/eclipse/recommenders/internal/completion/rcp/CompletionsPreferencePage.java#n79> [2] <https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/plugins/org.eclipse.recommenders.utils.rcp/src/org/eclipse/recommenders/utils/rcp/preferences/AbstractLinkContributionPage.java#n38> [3] <https://github.com/eclipse/eclemma/pull/13/files#diff-3dbf76ef53b7fd99207d22f6de2a77dcR67>
(In reply to Andreas Sewe from comment #6) I reduced problem down to protected Control createContents(Composite parent) { // apparently presence of intermediate composite prevents StringFieldEditor // from getting default font on OS X Composite result = new Composite(parent, SWT.NONE); StringFieldEditor editor = new StringFieldEditor( UIPreferences.PREF_DEFAULT_SCOPE_FILTER, UIMessages.CoveragePreferencesClasspathFilter_label, result); addField(editor); Dialog.applyDialogFont(result); return result; } what looks like a bug (?), as a workaround: result.setFont(parent.getFont());
Created attachment 266491 [details] Package Explorer > Properties > Javadoc Location page And BW I suppose that Package Explorer > Properties > Javadoc Location page faces the same issue.
(In reply to Evgeny Mandrikov from comment #8) > Created attachment 266491 [details] > Package Explorer > Properties > Javadoc Location page > > And BW I suppose that Package Explorer > Properties > Javadoc Location page > faces the same issue. Please open bugs with the platform team both about this and the more general issue you outlined in comment 7 (and please put me in Cc, as I would like to see how this plays out). Thank you.
(In reply to Andreas Sewe from comment #9) > Please open bugs with the platform team both about this and the more general > issue you outlined in comment 7 (and please put me in Cc, as I would like to > see how this plays out). Thank you. Done - bug 511203 and bug 511206
