Community
Participate
Working Groups
Currently its a bit hard to provide nice looking UI (components) across platforms when it comes to choosing a good font. As there is no concept of system-fonts (or at least non I'm aware of) like in AWT it is even not possible to choose for at least a fallback in case the best looking font is not available and every hard coded name is inherit platform dependent (look at [1] for an example). The proposal is that SWT at least includes a handful of free fonts (e.g. Apache License or SIL Open Font License) that could be reliable used across platforms. These fonts should be accessible via Display.getSystemFont(int) as it is today the case for Display.getSystemColor/getSystemCursor/getSystemImage [1] https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/163593/22
Alexander, WDYT?
(In reply to Christoph Laeubrich from comment #0) > These fonts should be accessible via Display.getSystemFont(int) as it is > today the case for Display.getSystemColor/getSystemCursor/getSystemImage > Have you tried Device.getSystemFont()? From the javadoc: "Returns a reasonable font for applications to use. On some platforms, this will match the "default font" or "system font" if such can be found."
(In reply to Lakshmi P Shanmugam from comment #2) > Have you tried Device.getSystemFont()? > From the javadoc: "Returns a reasonable font for applications to use. On > some platforms, this will match the "default font" or "system font" if such > can be found." The problem is: What is "reasonable" clearly depends on the context! For example I wan't an equally spaced "console" font, or I like some font with or without serifs. Or in the referenced example one that support a given set of (unicode) symbols. See [1] how AWT uses the concept of "physical" versus "logical" fonts. [1] https://docs.oracle.com/javase/tutorial/2d/text/fonts.html
The motto of SWT is to stick to the OS default as much as possible. I don't think SWT should come out of the box with some extra fonts. However, SWT must (and already does) offer ways for adopters to ship their SWT-based software with whichever font they like and to use it at runtime. Necessary fonts should be included downstream, eg if one font is useful in Eclipse Platform to replace some icons, we can include it in Platform and use it there. SWT is not the right layer where to put such new fonts.
Please see the discussion at https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/163593/22 where it has shown that SWT can need fonts with given properties too. Weather or not these are provided by a font-file or by some "system specific default fonts" don't matter much as long as there are some guaranteed properties (serif vs sans-serif, equal spaced vs dynamic space, unicode symbols supported...) one can rely on.
(In reply to Christoph Laeubrich from comment #5) > Please see the discussion at > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/163593/22 where > it has shown that SWT can need fonts with given properties too. The C* widgets are the anomaly in SWT, as they're drawn manually instead of relying on native. They're not IMO worth influencing design discussions too much. Does win32 API come with fonts, does GTK come with fonts? I may be wrong, but I think they don't, for the reason that they expect them to be provided by the OS, or by the application. This is the right pattern for widget libraries regarding fonts and SWT should stick to it.
There is already Display.getSystemFont() that return a "system dependent font" so I don't see how this introduces a complete *NEW* aspect but enhancing an existing concept. Beside this it's just exceedingly complex to put the burden to the usercode to decide what are the most likely default fonts for a given task, while I would expsect this to be done in the abstraction between os and user-level (swt) like it is done for cursors already, and I think fonts are a similar demand, it would allow to have similar appearance even for custom drawn components!
(In reply to Christoph Laeubrich from comment #7) > There is already Display.getSystemFont() that return a "system dependent > font" so I don't see how this introduces a complete *NEW* aspect but > enhancing an existing concept. So you're suggesting to add some new Display.get*Font() ? Have you seen JFaceResources class which does actually host reference to various system fonts for several use-cases. Providing a reference to a new font for XXX seems to be a better fit here than in SWT. However, we're digressing, my concern is not about adding references to some system fonts in SWT, it's more about adding in SWT some non-system fonts. This is not really how SWT is supposed to work since its principal rule is to stick as close as possible/delegate as much as possible to the OS by default (and allow some customization). SWT is not application-level nor user-level, it's the widget toolkit standard framework, a bit like HTML language; it's not supposed to be a gallery of custom fonts/images/whatever; dealing with custom graphical resources is consumers' duty.
(In reply to Mickael Istria from comment #8) > So you're suggesting to add some new Display.get*Font() ? I would rather suggest the same pattern like with Display.getSystemCursors(int) /getSystemImage(int) / getSystemColor(int) that uses a SWT constant > Have you seen JFaceResources various system fonts for several use-cases. Yes of course its always possible to add other libraries but it often makes sense to add those thing in the base. > my concern is not about adding references to some > system fonts in SWT, it's more about adding in SWT some non-system fonts. A list of known default fonts for would perfectly solve this. > This is not really how SWT is supposed to work But how are fonts different from colors, cursors or even images where SWT provide different(logical) choices across platforms. > a bit like HTML HTML (well at least CSS) defines (beside colors and cursors) also defines a set of 'safe' names: serif/sans-serif/monospace/cursive/fantasy not more or less I would suggest here.
(In reply to Christoph Laeubrich from comment #9) > (In reply to Mickael Istria from comment #8) > > So you're suggesting to add some new Display.get*Font() ? > > I would rather suggest the same pattern like with > Display.getSystemCursors(int) /getSystemImage(int) / getSystemColor(int) > that uses a SWT constant > A list of known default fonts for would perfectly solve this. Cool. > > This is not really how SWT is supposed to work > > But how are fonts different from colors, cursors or even images where SWT > provide different(logical) choices across platforms. I agree, as long as the proposal is not to add extra fonts inside SWt. > HTML (well at least CSS) defines (beside colors and cursors) also defines a > set of 'safe' names: serif/sans-serif/monospace/cursive/fantasy not more or > less I would suggest here. Ok, good then. I think this approach is valid. I retitled the issue accordingly. I'm glad we managed to get rid of > The proposal is that SWT at least includes a handful of free fonts (e.g. Apache License or SIL Open Font License) that could be reliable used across platforms. which was my main point of disagreement. Please keep in mind that -as usual with Platform- we'd ideally need a consumer in Platform (for example can be JFaceResources font definition) to consume those new API elements in order to accept them safely in SWT. Also, we'll need this to be implemented for all 3 platforms in SWT before we add APIs. That's usually both a technical and organizational challenge!
(In reply to Mickael Istria from comment #10) > I agree, as long as the proposal is not to add extra fonts inside SWt. [...] > I'm glad we managed to get rid of Sorry for confusion, I just wanted to express that if a system does not provide a suitable font it could be "emulated" with a free-font as it is done for example with the DateWidget in GTK where no suitable system widget exits.
I had a similar problem when I made my SnippetExplorer in pure SWT and had the problem to get a platform independent monospace font. I remember to google around and found others had similar problems before (most solutions used JFace) and searching again brought me to bug 48055. Have not read all of it but it might overlap with this bug.
(In reply to Paul Pazderski from comment #12) > I had a similar problem when I made my SnippetExplorer in pure SWT and had > the problem to get a platform independent monospace font. Is SnippetExplorer part of SWT and could be used as a consumer as requested my Mickael?
(In reply to Christoph Laeubrich from comment #13) > (In reply to Paul Pazderski from comment #12) > > I had a similar problem when I made my SnippetExplorer in pure SWT and had > > the problem to get a platform independent monospace font. > > Is SnippetExplorer part of SWT and could be used as a consumer as requested > my Mickael? SnippetExplorer is part of SWT snippets. you can access it here. Its a pure SWT application.
(In reply to Christoph Laeubrich from comment #13) > Is SnippetExplorer part of SWT and could be used as a consumer as requested > my Mickael? It's borderline. For this change, I think the natural consumer would be JFaceResources, that would then reuse SWT system fonts to intialize eg the default dialog font and the text font.
