Dear Michael: Thank you for initiating this discussion and providing a pull request!
I would like to make a few comments and ask your opinion on some of the difficulties the application developers face when confronted with requirements to provide a custom styling or even a completely different look and feel. I'll try to number the individual topics, but please forgive me if this message turns out to be long and jumbled. #1 Theme I wonder if we need to clarify what we mean by the word "theme" in the context of a javaFX application. Are we talking about colors, fonts, spacing, graphics, or all of the above? Would a completely different stylesheet like Caspian or Modena be considered a separate theme, or would we rather have a way to modify the standard stylesheet by adding ability to redefine the different aspects such as colors and spacing without making structural changes to the stylesheet itself? #2 Colors When talking about colors specifically, the main requirements might be: * change the base colors used by the standard stylesheets, or just Modena * derived colors might use different logic for light and dark themes * have ability to select a group of colors, or "color themes" - such as Light, Dark, Solarized, High Contrast, etc. * pick up the user-defined color preferences from the platform * track the user-defined color preferences at run time I think most of these (except for platform colors) can be implemented currently at the application level (that is, without introducing new APIs) simply by loading a stylesheet that redefines base colors (e.g. -fx-base), however, it gets complicated when we start deriving colors. For example, the use of derive() will need to change in order to obtain an esthetically pleasing colors in the dark theme. #3 Platform Colors Thank you for researching the preferences provided by the three different platforms. I wonder if it would make sense to extract that into a separate PR, perhaps as an implementation detail, to be further refined as a part of Desktop replacement for JavaFX? And, if we are talking about exposing platform colors via APIs, do we want to make it as a part of one giant facility like java.swt.Desktop equivalent, or via individual methods in Platform, or perhaps some other lookup scheme that allows for future extension? Do you think it could be possible to describe the individual platform properties (what is Windows.UIColor.AccentDark3?), and possibly attempt to map platform-specific properties to a platform-independent set of properties which represent a union of the three major platforms? There is one more complication - constant changes in the platform design language. Ideally, any new APIs would support gradual evolution of the platform by, for example, providing methods to query whether particular item is available or not. #4 Spacing and Font Size A lot of modern UIs introduced the concept of density (for example, in MS Outlook, Preferences -> General -> Density preference), by making spacing between UI elements larger or smaller (at run time). Similarly, the font size can be made larger or smaller (Ctrl-+ / Ctrl-- in Firefox). The font size change affects "em" units, perhaps we need a parallel construct like "space-em" units that is applied to spacing? Even then, we might need special logic to switch from pixels to fractions of "space-em" for large scales. How can we enable this functionality, ideally without making drastic changes to the base stylesheet? Is it even possible? #5 Programmatic Stylesheet Generation Somewhere in this discussion we might also consider adding a possibility of generating a stylesheet programmatically, ideally in a type-safe manner, compatible with auto-completion. jfx17 (I think) added a way to load a stylesheet data url, so it is much easier now, but I think a better way would be to skip the encoding/decoding step and just generate the stylesheet object directly. Perhaps the ideal scenario, one that makes it possible to adjust every aspect of the application styling, is to generate the complete stylesheet at run time, and possibly passing it to JavaFx in a binary form that does not require parsing. I understand this is totally separate issue which will no doubt require its own discussion. What do you think? -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß <michaelstr...@gmail.com> Date: Saturday, 2023/01/07 at 10:35 To: openjfx-dev <openjfx-dev@openjdk.org> Subject: Style themes API The following PR introduces new APIs to support style themes in JavaFX: https://github.com/openjdk/jfx/pull/511 As Kevin already indicated, we need to finish the discussion on the proposed API. I'd like to invite comments or suggestions with regards to the API to hopefully get a bit of momentum for this feature to make it into the 21 release. Michael
