Bug 27386 - A Control should inherit the font of its parent
Summary: A Control should inherit the font of its parent
Status: CLOSED INVALID
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 98
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-29 09:16 EST by Sebastian Davids CLA
Modified: 2002-12-02 09:58 EST (History)
0 users

See Also:


Attachments
windows patch (771 bytes, patch)
2002-11-29 09:22 EST, Sebastian Davids CLA
no flags Details | Diff
other OS' patch (3.27 KB, patch)
2002-11-29 09:59 EST, Sebastian Davids CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Davids CLA 2002-11-29 09:16:52 EST
see Bug 26987
see Bug 26987 comment 7

Right now, a new Control will have the system's default font.

If one creates a dialog one has to call setFont() for each Control of the dialog
in order achieve a consistent look.

It is especially error prone if you have a complex design with several stacked
Composites -- A in B in C in D in E etc.

A solution would be to change the behaviour of Control:

- if the Control has a parent, then it's parent's font will be used
- if the Control does not have a parent, then the system's default font will be used
Comment 1 Sebastian Davids CLA 2002-11-29 09:22:18 EST
Created attachment 2583 [details]
windows patch

I have tested this patch and it works.

Once you change the dialog font in Preferances/Workbench/Font all dialogs will
now use the chosen font, unless setFont() was called on a Control explicitly.
Comment 2 Sebastian Davids CLA 2002-11-29 09:59:17 EST
Created attachment 2584 [details]
other OS' patch

I was not able to test these fixes.

I still think that they should work ;)

Implementation notes Carbon:

I looked at how the system default font is created in Display (line 969) --
instead of a call to OS I passed getThemeFont() w/ the fID of the parent's
MacFont (see MacFont 37/38 that this is the desired short for getThemeFont()).

Implementation notes GTK:

The Control's default font is not set in the constructer but lazily initialized
in getFont().

I looked at how the system default font is created in Display (line 937) --
instead supplying the font_desc of a GtkStyle I supplied the parent's font
description; notice lines 932/933 in Display and lines 1348/1349 in Control are
similar.

Implementation notes Photon:

The default font in Display is stored in a byte-Array TEXT_FONT (line 1117) --
in Control setDefaultFont() setFont(byte[]) is called w/ this byte-Array.

I call setFont(Font) which retrieves the byte-Array of the parent's font and
calls setFont(byte[]).

Implementation notes Motif:

Similar to Carbon, but Font.motif_new() wants a font handle this time (Font
line 550).
Comment 3 Tod Creasey CLA 2002-11-29 11:23:16 EST
I believe that this would actually break a heck of a lot of OS settings on 
most platforms. The best an OS will give SWT is a default UI font - this is 
far too general in most cases. Individual OS's may give more information than 
this but this is all they can get consistently.

Frustration with the small range of font settings provided by the OS prompted 
the JFace team to add the dialog font which we have now exposed in the UI. 
This font is only meant to be used in dialogs, not in windows or views which 
tend to have better fonts inhertied from the OS.

Using windows as an example there are already fairly rich font settings 
provided by the OS for windows (look in Properties->Appearance on your 
desktop) but no such support is provided for dialogs (they use the message box 
font everywhere by default).

Context is important here and SWT is at too low of a level to be able to 
determine this. 
Comment 4 Sebastian Davids CLA 2002-12-02 09:57:41 EST
.
Comment 5 Sebastian Davids CLA 2002-12-02 09:58:19 EST
see Bug 26987 comment #14