I think Appearance is exactly correct as it is. It encodes a
fundamental binary aspect of visual presentations that all themes,
styles, displays, posters, prints, etc. must choose between: do I
present text on a light background (and so the text is dark), or do I
present text on a dark backgro
I'd like to wrap up the discussion around the new `Appearance`
enumeration proposed for the Platform Preferences API:
public enum javafx.application.Appearance {
LIGHT, DARK
}
When viewed with the goal of eventually supporting style themes, this
might seem a bit limiting at first.
I think this is another step in the right direction. The
Platform.getPreferences() method would then document that the returned
map is an "unmodifiable map" (as defined by the Map interface docs).
-- Kevin
On 6/16/2023 6:36 AM, Michael Strauß wrote:
It might indeed be useful to split read-on
+1 for getPaint()
+1 for modena dark css
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Friday, June 16, 2023 at 08:56
To: Thiago Milczarek Sayão
Cc: openjfx-dev
Subject: Re: Platform preferences API
Maybe the Preferences API should have a convenience method like
Optional
Maybe the Preferences API should have a convenience method like
Optional getPaint(String key);
instead of getColor, to allow for cases when an OS defines complex
paint instead of solid colors.
I like your idea of shipping a Modena Dark variant. We should consider
this as a potential follow-up
I was thinking mostly about colors. Those will be hard because the tendency
to have css styles. Might not even be a solid color.
Light and Dark mode could be useful and seems like a hardened feature
everywhere. Maybe a Modena dark css should be shipped together (for optimal
use)?
-- Thiago
I completely disagree. Being able to adjust the applications appearance to the
OS has been a topic for me and many others for quite some time. Thanks for
people like Gerrit Grunwald I have been able to partially solve dark mode
support but it is very OS specific and requires execution of batch c
My perception is entirely different. In the last few years, most
operating systems seem to have embraced the light/dark mode concept.
More and more applications (as well as web applications) support dark
mode in addition to the default light mode, and many try to adapt to
the OS.
That is certainly
See also Andy's question:
> Is high contrast mode encoded as another attribute, or does it need two more
> values in Appearance (high contrast light, high contrast dark)?
LIGHT and DARK are the only two appearances afforded by Windows
(starting with Windows 10), macOS, and iOS. I think it's safe
It might indeed be useful to split read-only platform preferences from
mutable application preferences.
I've updated the API doc [1]; here is the summary:
1. Have `Platform.getPreferences()` return the same interface as
before, minus the mutation methods.
2. Have `Application.getPreferences()` retu
I think we should wait and don't do this in the short term.
Many recent apps don't care for platform appearance at all.
Take Microsoft windows for an example, there are many layers of "evolution"
and they all look different on the same OS.
Linux will be a nightmare, you have many desktop environ
my two drachmas (in addition to the comments in the PR and elsewhere):
#3 I think this API should be unidirectional, i.e. limited to reporting the
platform preferences and their runtime changes to the application (the key set
is immutable, and values cannot be put by the application). Whenever
12 matches
Mail list logo
