Community
Participate
Working Groups
20021115 The dialog font is not honoured by the Java preference pages. Preference pages have the dialog font set as the font of the control sent to createContents - you can just copy the font from the parent to the children you create. Other dialogs can get it by calling JFaceResources.getDialogFont(). Also an issue for export jar file, javadoc preference and properties, compiler properties
Are you saying that we have to set the font to every widget we create in a dialog. Wouldn't it make sense that JFace provides more support for this. Otherwise I think that we always end up having preference pages and property pages with different fonts since not every plug-in writer will be aware of this. Moving back to JFace to comment on more support for setting the dialog font automatically.
JFace is setting the font wherever we can but there are places where this can't be done as the widgets are created by the pages themselves (notably buttons and labels). If you see somewhere where API from us would be of us please let us know and we would be happy to add it.
One idea is that JFace sets the font to every wigdet created in a dialog and provides a special hook (applyFonts) to sent fonts that differ from the dialog font. This hook would be called after createContents. Doing so would solve the 99% case.
This is an interesting idea. Nick what implications do you see for this? We can always walk the dialogs using getContents and see what widgets are set to the default font.
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.
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.
This is very annoying on MacOS X because the default font is quite big and the JDT preferences are nearly filling the whole screen.
As Tod pointed out setting the font after the widget has been created always asked for trouble if the original font has already been used to do some calculation (for example for GridDatas). On the other hand always writing code like Button button= new Button(parent, flags); button.setFont(parent.getFont()); looks strange as well. And given the fact that WS* and other plugins have hundereds of dialogs and preference pages I think if we delegate this to the plugin provider we will never get a consistent UI. IMO there should be more support from SWT to propagate fonts to children, but I agree that this can't be a general mechanism that takes place without a client asking for it. An idea for a helpful SWT support is as follows: we define an additional style bit (lets call it PROPAGATE_FONT_ON_CREATION). If a client creates a new composite with this style bit its font is used as a default font for child widgets. An change of the font will not impact any already created children. May be we have to distinguish between deep and shallow propagation. Sebastian Davids posted some patches to automaically inherit the font from its parent (see bug 27386). May be we can resuscitate the code. Carboning Steve Northover to get an SWT opinion on this as well.
Inheritance of font (and colors) has been debated back and forth for quite a while now. Our position is that SWT should not be setting fonts (and colors) as this is generally done through the preferences mechanism of the platform. There is no native mechism for the inheritance of fonts on Windows and most other platforms. Because fonts can be shared between controls, it's important to know when a font is in use so that it won't get disposed while in use. Right now, Control.setFont() is the only way to set a font in a control and this makes it explicit that a font is in use. Why does Eclipse have a dialog font in the first place? It's just another place to get the font wrong on non-English platforms.
I understand the argument that this ask for disposed font's that are still in use although the client has to request the feature "propagation feature" explicitly by passing a flag. Since the UI is managing the dialog font we should "somehow" set it to the widgets. But I still believe that this shouldn't be done by hand coding this all over the place. Another idea how to "ease" this is to have an addChildListener. A client can install that listener on a composite and the listener is informed when a new children gets added to the composite. Relayout of composites could also profit from this feature (currently we call layout "by hand" pushing the knowledge of special layouters to the place where a child is created, not where the composite and layout is created).
Agree that addChildListener (or the equivalent) could be helpful. Then the application program (ie. Eclipse) could decide the policy, not SWT. Can the UI stop managing the dialog font? NOTE: Layout "by hand" is by design. The idea is that layout is expensive and calling layout every time a child is added or removed for each child will cause multiple layouts causing flashing and poor performance. The idea is that the application knows when layout needs to happen and does this explicitly. An alternative to this strategy is to implement a deferred layout mechansim (similar to the painting with redraw()/update()). The problem with this is that clients who expect layout to happen right away and query coordinates from widgest, will have to wait until the event loop. GTK does this internally in it's implementation and this is a huge source of bugs and problems.
Opened new PR bug 28821 for the childAdded listener. Regarding the "layout by hand" issue: I am not asking for a general support in SWT. The idea was that in the special cases where we need to relayout a parent when a child gets added the new listener could ease this relayouting.
Yes it could but using the addChildListener to do relayout in any general way would mean that you would need to implement a deferred layout strategy or risk the potential poor performance when multiple children are added or removed (which may not be an issue for your application). In any case, the callback would allow you to decide both layout and font policy without changing SWT.
OK, interpreting Steve's answer as a "yes, we will add a childAdded listener", JFace could implement a listener which propagates the font down to its children. IMO the default implementation should do a "deep font propagation" and clients, not interested in this should disable this either when creating a JFace dialog or when creating a property, perferences, wizard or other dialog page. This ensures that all the dialogs and all dialog pages will use the right dialog font. Since this must be implemented by JFace, it would be nice to get some feedback on the proposal from the JFace team members.
This is something that we could add API for but not by default - it would be very similar to the applyDialogFont method we have right now so this is something we could easily provide, the main difference being we would set up the listener servicing code. It is not something we want on by default as the dialog developer needs to decide when the font is dialog font the whole way down the tree. You typically cannot start at the shell and apply it everywhere as title labels etc. use different fonts.
IMO it should be the default and here are my reasons: - the behaviour differs from calling the method applyDialogFont in the following way: the widget has the correct font after it has been created. So if a client writes code like: Button button= new Button(parent, SWT.PUSH); <== button has the dialog font button.setFont(myButtonFont); <== button has my button font. So calculating any hints using the widget after it has been created will use the correct font metric. - in the early days of SWT we had to set the platform font (the one settable using Window's Appearance dialog) by hand to all widget since it used some old "Windows 3.x" default font. This resulted in a funny looking UI since developers forgot to set the font to all widgets. Our current preference pages already show this behavior: change the dialog font and open the pages Workbench->Local Histroy. The Note label has the wrong font. - since JFace introduces dialog fonts and manages dialog classes and dialog pages it should use the dialog font for all widgets created inside dialogs or inside dialog pages (if we dont't want to do it for all dialogs). So only developers which need widgets having a font different from the dialog font have to write any code.
While verifying bug 30616 I found an issue regarding dialog fonts. If you switch to high contrast mode in Window the fonts get enlarged. This also happens for dialogs, except for those were we apply a different font (dialog font) programmatically. Hence most of our preference pages still have a small font. Any comments ?
This is a general issue with fonts and colours (the JDT text doesn't show up in a switch to High Contrast until you switch to white either). We assume that the user will set up appropriate values when they do this - there is no way for us to know that High Contrast mode has been selected (and for that matter it is very different on different platforms).
There is also an issue with wide fonts and buttons not spacing adequately. Andrew managed to select a very wide font on GTK using the KDE desktop and the buttons were cut off. This same problem has been reported by Japanese testers in Bug 31080 (referenced here)
Problems with the button sizing were observed in the following pages Java Appearance - Members Sort Order Classpath Code Generation Editor-Templates Javadoc Organize Imports Task Tags
Entered a separate bug for the button spacing issue since it is independend from the dialog font issue. http://dev.eclipse.org/bugs/show_bug.cgi?id=31143
is this fixed? that way we can close bug 19346
All our dialogs should show the correct font (I am running with a different dialog font and I didn't notice dialogs not showing the dialog font). However I kept this bug open since I still don't like the solution how we apply the dialog font. Clients have to call a special method which they very likely forget to call... Nick, we had some discussion about a better solution in the past. Can you comment on the state. I searched for the bug but couldn't find it.
I think the discussion was centered around a suggestion you had made to automatically propagate the dialog font to all children, which required the addition of a child listener in SWT. Post 3.0 I want to revisit this whole area, and look at how we can do the kinds of propagations of fonts and colors we need in a easy-to-declare way, taking inspiration from CSS and XUL. I believe this will require some rethinking of how we do layouts as well (i.e. width hints are bad).
Nick, is Platform/UI doing something here for 3.1 ?
We're currently debating whether to push further on this and try to make it more transparent to plug-ins, or to pull it out entirely.
Moving to later. IMO, we are not changing the way how this works for 3.1.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
