Community
Participate
Working Groups
The dialogs provided by JFace use the defualt font from SWT to define thier dialog unit size and the size and font of many of the buttons. On some Motif platforms it is not unusual for these fonts to be very small. Two things need to be done 1) Test with an .xdefaults file that sets this font for eclipse and check that that is OK 2) In the 3.0 timeframe add a Dialog Font to the list of fonts and use that for this propagated font. Grant please advise on who to construct an Xdefaults file.
I can provide one. (anticipating) Below is an example of one that I've used in the past on linux. To try it save it to a file like .Xdefaults, then invoke: xrdb .Xdefaults *fontList:\ -adobe-helvetica-medium-r-*--14-*-*-*-*-*-*-*;\ -misc-fixed-medium-r-*--14-*-*-*-*-*-*-*:
This is now taken care of by use of the dialog font. Review import/export and creation dialogs to be sure fonts are being propogated.
I have made and released the changes to the org.eclipse.ui dialogs to use the dialog font. However for 2.1 we are going to remove the entry in the FontsPreferencePage for it as it required buy in from all other components to start using this themselves. Renaming PR and marking the use of the dialog font as an enhancement of P3.
This has been put as an action item for M4. Increasing priority to P2.
Need to integrate with the following UI dialogs: Editors Key Bindings Import Existing Project Switch to Editor dialog Customize Perspective Show View dialog Select Perspective Dialog External to the UI: Compare preference page Search preference page, Search dialog Application Server Debug - All and Launch Configuration All External tools preferences and Launch Configuration, External tools builder properties Help Install/Update All Java preference and new pages, export jar file, javadoc preference and properties, compiler properties All plugin development and import plugins. Plug-in and feature details dialogs All Team preference import/export team project set Find/Replace dialog
Fixed problems within the UI. Marking down to P3 as this PR can be closed when blocking PRs are fixed.
One should be able to change the font of a field editor.
Created attachment 2578 [details] fixes task-related dialogs fixes: "Task"FilterDialog TaskPropertiesDialog
Created attachment 2580 [details] fixes for workbench Fixes: AbstractElementListSelectionDialog CheckedTreeSelectionDialog ContainerSelectionDialog ElementTreeSelectionDialog FileSelectionDialog FilteredList MarkerResolutionSelectionDialog NewFolderDialog ProjectLocationMoveDialog ProjectLocationSelectionDialog TwoPaneElementSelector TypeFilteringDialog WizardNewLinkPage DialogCustomize AboutFeaturesDialog AboutPluginsDialog ActionSetSelectionDialog CheckboxSingleListGroup EditorSelectionDialog FilterDialog MultistepConfigureWizardPage PathVariableDialog ProjectCapabilityEditingPropertyPage ProjectCapabilityPropertyPage ProjectCapabilitySimpleSelectionPage ProjectPerspectiveChoiceDialog ResourceListSelectionDialog ResourceWorkingSetPage SavePerspectiveDialog SelectPerspectiveDialog WizardNewProjectNameAndLocationPage WorkingSetSelectionDialog WorkingSetTypePage CheckboxDoubleListGroup CheckboxTreeAndListGroup ProjectCapabilitySelectionGroup WizardStepGroup WelcomePageSelectionDialog
please take a look at bug 27386
Fixes suggested by Sebastian Davids released with some additions (button sizing). Congratualtions on joining the list of Eclipse contributors!
Font propogation added to BooleanFieldEditor, ListEditor, RadioGroupFieldEditor, StringButtonFieldEditor
Created attachment 2591 [details] ProgressMonitorPart label
Created attachment 2592 [details] InputDialog text box
When we initially started doing this the dialog font was not going to be applied to all widgets in the dialog - now it is. As a result we can do now what Dirk has suggested by adding API to Dialog that propogates this font to all of the controls in the Dialog whose font has not already been set. I have checked with SWT and Veronika beleives this is OK in principle but thinks we should verify with Silenio first.
public static applyDialogFont(Control control) has been added to Dialog. This can be called to apply the dialog font to the tree of a control whose font is the default font. I could not hook this up by default because it causes some layout problems on many of the pages and dialogs we have if it is called after widget creation as sizing is frequently done in the creation code. We do not wish to generate any layout problems by the addition of this API. I have also changed initializeBounds to use the dialog font for the calculations and not the font of the passed control. In the dialog provided by the workbench this will not do anything but for those dialogs provided by other components this will allow them to do the sizing before applying the dialog font.
What about the wizards? They now also use the dialog font and could profit from a method like applyDialogFont(Control).
This is why the method is static so that it can be used by elements (like WizardPages) that do not have direct access to thier parent dialog. Just call the new method at the end of your createContents method.
Comments copied from bug 26690, re applyDialogFont: Agree we need to make this easier, and that we can't apply it by default since that will break many layouts. The convenience method should probably be protected, not public. Also, I'm wary of changing the behaviour of initializeBounds. If the subclass hasn't changed to use the dialog font, then it's incorrect to initialize the conversion ratio assuming the dialog font.
Can't make it protected due to comment #18.
Verified the workbench pages in I20021216. All looks well except for bug 28427 and bug 28428.
There is still an inconsistency in the propagation of the font change. Some Preference pages immediately update to the new font after "Apply" -- the Font page itself or the Compare/Patch page for example. Most of the pages will not update their font, the behavior should be consistent throughout all pages.
Stefan many of our dialogs use font propagation and not applyDialogFont(). These need to be moved over for 3.0
can we close if bug 26990 is fixed?
No time left for 3.1.
Just got assigned this bug. Tod, can you help explain comment #23? Is the remaining issue that we need to go through the platform UI dialogs and ensure we are using Dialog.applyDialogFont rather than assigning controls their parent's font on creation? (If so, then I can look at this when I make a pass over all dialogs for size/position persistence)
Yes - exactly. Using the parent font breaks the font -widget mappings possible in GTK, Motif and the Mac.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
