[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-openjfx-dev
Subject: Re: Style themes API
From: Pedro Duque Vieira <pedro.duquevieira () gmail ! com>
Date: 2023-01-31 23:54:55
Message-ID: CAAEud6a6VN=i=cba6zSycX-vkk4kskuWbpR22xoXyQYrQCQDvQ () mail ! gmail ! com
[Download RAW message or body]
My previous message seems to have perhaps gotten lost in the
various messages exchanged in this mailing list.. (just doing this small
comment so that my previous message doesn't get lost..)
It's getting very late here where I live, I will be back later tomorrow (a
few hours from now).
Thanks
On Tue, Jan 31, 2023 at 5:14 PM Pedro Duque Vieira <
pedro.duquevieira@gmail.com> wrote:
> Hi Michael,
>
> Truly sorry for the late reply but haven't had time to reply sooner,
> unfortunately..
>
> 2 -
>
>> > I've been building javafx themes for years now. Started creating JMetro
>> in JavaFX version 2. During this time I've been following how other themes
>> are being built and I can say that about 90% of the themes (rough estimate)
>> that are out there, are composed of author stylesheets, i.e they override
>> values set from code (including JMetro).
>> > I agree that themes that are to be provided to other developers would
>> probably be better off if they are user agent stylesheets. My point is that
>> migrating those 90% of themes to use this API would be easier if this flag
>> exists otherwise migration would likely introduce UI regressions for
>> developers using those themes.
>> >
>> > To be clear, what I'm proposing is a flag, or enum, or whatever, in
>> StyleTheme that defines whether the stylesheets in the StyleTheme should be
>> a user agent stylesheet or author stylesheet.
>> >
>> > Another point is in making themes that are only to be used locally in a
>> specific app that the developer is creating. It might be of interest that
>> he can toggle this flag and make all settings defined in the theme override
>> any styling set from code (or in FXML) so that he can have a centralized
>> point where all styling is done.
>
>
> I think that the likelihood of this feature making it into the 21
>> release dramatically increases if we keep changes to the CSS subsystem
>> to an absolute minimum. I understand your point, but I want to deliver
>> this feature in the smallest useful package and add more features
>> later with follow-on PRs.
>
>
> That's why I've renamed `Application.styleTheme` to
>> `Application.userAgentStyleTheme`. This makes it unmistakably clear
>> that we're only talking about user-agent stylesheets.
>> Also, it leaves open the possibility to add the
>> `Application.styleTheme` property later, which would cause the theme
>> to be interpreted as comprised of author stylesheets.
>> Classifying author/UA themes at the property level is also more
>> consistent with the way author/UA stylesheets are currently classified
>> in JavaFX.
>> What do you think about the styleTheme/userAgentStyleTheme API,
>> instead of having a flag in the implementation of StyleTheme itself?
>
>
> Since one of the objectives of the PR is to promote Caspian and Modena
>> to first-class theme implementations, it makes sense to focus on UA
>> themes first (since built-in themes are comprised of UA stylesheets).
>
>
> OK.
> Thinking of existing themes migrating to this StyleTheme API (90% are
> implemented as author stylesheets), some visual glitches may start
> appearing for users of those themes once they start using the migrated
> versions (since they will go from being author stylesheets to user agent
> stylesheets).
> So, 2 things to think about:
> 2.1 - How important is it that we think about this use case: existing
> themes migrating to this new API. I'd say we should probably think about it
> when designing this new API.
> 2.2 - The second thing then is, how problematic will it be for programmers
> using these themes to have their apps start having visual glitches because
> of these themes changing from author stylesheets to user agent style
> sheets?
> Perhaps we simply don't bother with this last point and simply have it be
> the price of innovation. And so programmers will have to adapt their
> applications and remove any code that is overriding the styles defined in
> the StyleThemes (which are likely causing these visual glitches when
> migrating to Themes using this new StyleTheme API). The same for any styles
> already defined in custom author stylesheets that are being used by the
> application and that might be NOW overriding the styles of the theme.
>
>
> 3 -
> > Style themes are generally either defined as dark or light. i.e. you'll
> very rarely have a theme that has some Windows with dark decorations and
> others with light decorations. So I think it makes sense to have this as a
> theme property.
> > The ability to toggle decorations (light or dark) on an individual
> Window is a good point you're making. Perhaps we should have a global
> definition in the StyleTheme (whether the theme is light or dark) and a
> definition that can be set per Window.
> > If you set it on the StyleTheme then all Windows will respect it, but
> you can override that value on each Window. If you override it on a
> specific Window, that definition would take precedence over the global
> StyleTheme one.
>
> In general, StyleTheme is a very simple concept: it's a dynamic
>> collection of stylesheets.
>> I don't think the interface should force implementers to deal with
>> anything other than stylesheets. If we did that, the following code
>> wouldn't work any more:
>
>
> Application.setUserAgentStyleTheme(
>> () -> List.of("stylesheet1.css", "stylesheet2.css");
>
>
> Maybe we can add a new interface, for example DarkModeAware, and if an
>> application theme is marked with this interface, JavaFX will try to
>> respect dark/light mode for platform decorations:
>
>
> public class MyCustomTheme implements StyleTheme, DarkModeAware {
>> @Override
>> public List<String> getStylesheets() {
>> return List.of("stylesheet1.css", "stylesheet2.css");
>> }
>> }
>
>
> // Setting a DarkModeAware theme causes JavaFX to draw light or
>> // dark platform decorations by default, depending on the current
>> // platform preference. If the theme is not DarkModeAware, JavaFX
>> // defaults to light decorations.
>> //
>> Application.setUserAgentStyleTheme(new MyCustomTheme());
>
>
> In any case, I think we can deliver this feature in a follow-on PR.
>
>
> I don't think we should put having StyleTheme be just a collection of
> stylesheets and nothing else as a requirement. I'd rather think of
> StyleTheme as being the concept of a Theme and all the possible properties
> and definitions of what a Theme is. This is one of the strengths of this
> new feature you've proposed, i.e.
> having the concept of a Theme exist in JavaFX whereas in the past there
> was no such concept and a "Theme" was just a collection of stylesheets.
> Added through the getStylesheets() method or through the
> setUserAgentStylesheet method.
>
> I'll just note that we don't just want the applications to be light or
> dark depending on what is set in the Operating System. You'll also want the
> ability to set whether the app is in dark or light mode on a per
> application level irrespective of what is defined in the OS (this already
> happens on many existing applications out there). So I think that
> DarkModeAware interface would have to have a method like:
> ThemeMode getMode();
> Where ThemeMode can either be LIGHT, DARK or OS_DEFINED (I've named it
> ThemeMode just as an example).
>
> So I think we could do it in 2 ways: one way would be to do it as you say
> (though DarkModeAware interface would need the getMode() method that I
> suggested, I think) or add a method in the StyleTheme interface itself in a
> future release:
> ThemeMode getMode();
> That method would probably need to have a default implementation that
> simply returns LIGHT because of retro compatibility.
>
> So, ThemeMode could be one of 3 possible values: LIGHT, DARK or
> OS_DEFINED. Where OS_DEFINED means that the app will honor whatever is
> defined at the OS level.
> JavaFX Window decorations would need to respect whatever is returned in
> this getMode() method and change their decorations to either LIGHT or DARK
> depending on its value. This would also remove the need for boilerplate
> code that for every Window that is created sets it to be LIGHT or DARK
> depending on whether the Theme is LIGHT or DARK.
>
> Of course, we can also simply support this from the get go and have this
> method exist in StyleTheme from the start.
>
> Thanks again,
>
>
>
>
>
>
>
>
>
> On Sun, Jan 22, 2023 at 12:51 AM Michael Strauß <michaelstrau2@gmail.com>
> wrote:
>
>> Hi Pedro,
>>
>> see my comments below.
>>
>>
>> On Sat, Jan 21, 2023 at 5:19 PM Pedro Duque Vieira
>> <pedro.duquevieira@gmail.com> wrote:
>> > I've been building javafx themes for years now. Started creating JMetro
>> in JavaFX version 2. During this time I've been following how other themes
>> are being built and I can say that about 90% of the themes (rough estimate)
>> that are out there, are composed of author stylesheets, i.e they override
>> values set from code (including JMetro).
>> > I agree that themes that are to be provided to other developers would
>> probably be better off if they are user agent stylesheets. My point is that
>> migrating those 90% of themes to use this API would be easier if this flag
>> exists otherwise migration would likely introduce UI regressions for
>> developers using those themes.
>> >
>> > To be clear, what I'm proposing is a flag, or enum, or whatever, in
>> StyleTheme that defines whether the stylesheets in the StyleTheme should be
>> a user agent stylesheet or author stylesheet.
>> >
>> > Another point is in making themes that are only to be used locally in a
>> specific app that the developer is creating. It might be of interest that
>> he can toggle this flag and make all settings defined in the theme override
>> any styling set from code (or in FXML) so that he can have a centralized
>> point where all styling is done.
>>
>> I think that the likelihood of this feature making it into the 21
>> release dramatically increases if we keep changes to the CSS subsystem
>> to an absolute minimum. I understand your point, but I want to deliver
>> this feature in the smallest useful package and add more features
>> later with follow-on PRs.
>>
>> That's why I've renamed `Application.styleTheme` to
>> `Application.userAgentStyleTheme`. This makes it unmistakably clear
>> that we're only talking about user-agent stylesheets.
>> Also, it leaves open the possibility to add the
>> `Application.styleTheme` property later, which would cause the theme
>> to be interpreted as comprised of author stylesheets.
>> Classifying author/UA themes at the property level is also more
>> consistent with the way author/UA stylesheets are currently classified
>> in JavaFX.
>> What do you think about the styleTheme/userAgentStyleTheme API,
>> instead of having a flag in the implementation of StyleTheme itself?
>>
>> Since one of the objectives of the PR is to promote Caspian and Modena
>> to first-class theme implementations, it makes sense to focus on UA
>> themes first (since built-in themes are comprised of UA stylesheets).
>>
>>
>>
>> > 3 -
>> > Style themes are generally either defined as dark or light. i.e. you'll
>> very rarely have a theme that has some Windows with dark decorations and
>> others with light decorations. So I think it makes sense to have this as a
>> theme property.
>> > The ability to toggle decorations (light or dark) on an individual
>> Window is a good point you're making. Perhaps we should have a global
>> definition in the StyleTheme (whether the theme is light or dark) and a
>> definition that can be set per Window.
>> > If you set it on the StyleTheme then all Windows will respect it, but
>> you can override that value on each Window. If you override it on a
>> specific Window, that definition would take precedence over the global
>> StyleTheme one.
>>
>> In general, StyleTheme is a very simple concept: it's a dynamic
>> collection of stylesheets.
>> I don't think the interface should force implementers to deal with
>> anything other than stylesheets. If we did that, the following code
>> wouldn't work any more:
>>
>> Application.setUserAgentStyleTheme(
>> () -> List.of("stylesheet1.css", "stylesheet2.css");
>>
>> Maybe we can add a new interface, for example DarkModeAware, and if an
>> application theme is marked with this interface, JavaFX will try to
>> respect dark/light mode for platform decorations:
>>
>> public class MyCustomTheme implements StyleTheme, DarkModeAware {
>> @Override
>> public List<String> getStylesheets() {
>> return List.of("stylesheet1.css", "stylesheet2.css");
>> }
>> }
>>
>> // Setting a DarkModeAware theme causes JavaFX to draw light or
>> // dark platform decorations by default, depending on the current
>> // platform preference. If the theme is not DarkModeAware, JavaFX
>> // defaults to light decorations.
>> //
>> Application.setUserAgentStyleTheme(new MyCustomTheme());
>>
>> In any case, I think we can deliver this feature in a follow-on PR.
>>
>>
>> > 4-
>> >>
>> >> If we wanted to expose this front-and-center, we could add these
>> >>
>> >> properties to the Platform.Properties interface:
>> >
>> >
>> >> public interface Preferences extends ObservableMap<String, Object>
>> {
>> >> ReadOnlyBooleanProperty darkModeProperty();
>> >> ReadOnlyObjectProperty<Color> accentColorProperty();
>> >> ...
>> >> }
>> >
>> >
>> > Yes, I think that would be great.
>>
>> Let's see what other people think.
>>
>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>
--
Pedro Duque Vieira - https://www.pixelduke.com
[Attachment #3 (text/html)]
<div dir="ltr">My previous message seems to have perhaps gotten lost in the various \
messages exchanged in this mailing list.. (just doing this small comment so that my \
previous message doesn't get lost..)<div><br></div><div>It's getting very \
late here where I live, I will be back later tomorrow (a few hours from \
now).</div><div><br></div><div>Thanks</div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Tue, Jan 31, 2023 at 5:14 PM Pedro Duque Vieira \
<<a href="mailto:pedro.duquevieira@gmail.com">pedro.duquevieira@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi \
Michael,<div><br></div><div>Truly sorry for the late reply but haven't had time \
to reply sooner, unfortunately..</div><div><br></div><div>2 - </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><span style="color:rgb(80,0,80)">> I've \
been building javafx themes for years now. Started creating JMetro in JavaFX version \
2. During this time I've been following how other themes are being built and I \
can say that about 90% of the themes (rough estimate) that are out there, are \
composed of author stylesheets, i.e they override values set from code (including \
JMetro).<br></span><span style="color:rgb(80,0,80)">> I agree that themes that are \
to be provided to other developers would probably be better off if they are user \
agent stylesheets. My point is that migrating those 90% of themes to use this API \
would be easier if this flag exists otherwise migration would likely introduce UI \
regressions for developers using those themes.<br></span><span \
style="color:rgb(80,0,80)">><br></span><span style="color:rgb(80,0,80)">> To be \
clear, what I'm proposing is a flag, or enum, or whatever, in StyleTheme that \
defines whether the stylesheets in the StyleTheme should be a user agent stylesheet \
or author stylesheet.<br></span><span style="color:rgb(80,0,80)">><br></span><span \
style="color:rgb(80,0,80)">> Another point is in making themes that are only to be \
used locally in a specific app that the developer is creating. It might be of \
interest that he can toggle this flag and make all settings defined in the theme \
override any styling set from code (or in FXML) so that he can have a centralized \
point where all styling is done.</span></blockquote><div><span \
style="color:rgb(80,0,80)"><br></span><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">I think that the likelihood of this feature making \
it into the 21<br>release dramatically increases if we keep changes to the CSS \
subsystem<br>to an absolute minimum. I understand your point, but I want to \
deliver<br>this feature in the smallest useful package and add more features<br>later \
with follow-on PRs.</blockquote><br><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That's why \
I've renamed `Application.styleTheme` to<br>`Application.userAgentStyleTheme`. \
This makes it unmistakably clear<br>that we're only talking about user-agent \
stylesheets.<br>Also, it leaves open the possibility to add \
the<br>`Application.styleTheme` property later, which would cause the theme<br>to be \
interpreted as comprised of author stylesheets.<br>Classifying author/UA themes at \
the property level is also more<br>consistent with the way author/UA stylesheets are \
currently classified<br>in JavaFX.<br>What do you think about the \
styleTheme/userAgentStyleTheme API,<br>instead of having a flag in the implementation \
of StyleTheme itself?</blockquote><br><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Since one of the objectives of the PR is to \
promote Caspian and Modena<br>to first-class theme implementations, it makes sense to \
focus on UA<br>themes first (since built-in themes are comprised of UA \
stylesheets).</blockquote><div><br></div><div>OK. </div><div>Thinking of existing \
themes migrating to this StyleTheme API (90% are implemented as author stylesheets), \
some visual glitches may start appearing for users of those themes once they start \
using the migrated versions (since they will go from being author stylesheets to user \
agent stylesheets). </div><div>So, 2 things to think about: </div><div>2.1 - How \
important is it that we think about this use case: existing themes migrating to this \
new API. I'd say we should probably think about it when designing this new API. \
</div><div>2.2 - The second thing then is, how problematic will it be for programmers \
using these themes to have their apps start having visual glitches because of these \
themes changing from author stylesheets to user agent style sheets? <br>Perhaps we \
simply don't bother with this last point and simply have it be the price of \
innovation. And so programmers will have to adapt their applications and remove any \
code that is overriding the styles defined in the StyleThemes (which are likely \
causing these visual glitches when migrating to Themes using this new StyleTheme \
API). The same for any styles already defined in custom author stylesheets that are \
being used by the application and that might be NOW overriding the styles of the \
theme.</div><div><br></div><div><br></div><div>3 - </div><div><span \
style="color:rgb(80,0,80)">> Style themes are generally either defined as dark or \
light. i.e. you'll very rarely have a theme that has some Windows with dark \
decorations and others with light decorations. So I think it makes sense to have this \
as a theme property.<br>> The ability to toggle decorations (light or dark) on an \
individual Window is a good point you're making. Perhaps we should have a global \
definition in the StyleTheme (whether the theme is light or dark) and a definition \
that can be set per Window.<br>> If you set it on the StyleTheme then all Windows \
will respect it, but you can override that value on each Window. If you override it \
on a specific Window, that definition would take precedence over the global \
StyleTheme one.<br><br></span><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In general, \
StyleTheme is a very simple concept: it's a dynamic<br>collection of \
stylesheets.<br>I don't think the interface should force implementers to deal \
with<br>anything other than stylesheets. If we did that, the following \
code<br>wouldn't work any more:</blockquote><br><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> Application.setUserAgentStyleTheme(<br> \
() -> List.of("stylesheet1.css", \
"stylesheet2.css");</blockquote><br><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Maybe we can add a new interface, for example \
DarkModeAware, and if an<br>application theme is marked with this interface, JavaFX \
will try to<br>respect dark/light mode for platform \
decorations:</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> public class \
MyCustomTheme implements StyleTheme, DarkModeAware {<br> @Override<br> \
public List<String> getStylesheets() {<br> return \
List.of("stylesheet1.css", "stylesheet2.css");<br> \
}<br> }</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> // Setting a \
DarkModeAware theme causes JavaFX to draw light or<br> // dark platform \
decorations by default, depending on the current<br> // platform preference. If \
the theme is not DarkModeAware, JavaFX<br> // defaults to light decorations.<br> \
//<br> Application.setUserAgentStyleTheme(new \
MyCustomTheme());</blockquote><br><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In any case, I \
think we can deliver this feature in a follow-on \
PR.</blockquote><div><br></div><div>I don't think we should put having StyleTheme \
be just a collection of stylesheets and nothing else as a requirement. I'd rather \
think of StyleTheme as being the concept of a Theme and all the possible properties \
and definitions of what a Theme is. This is one of the strengths of this new feature \
you've proposed, i.e. </div></div><div>having the concept of a Theme exist in \
JavaFX whereas in the past there was no such concept and a "Theme" was just \
a collection of stylesheets. Added through the getStylesheets() method or through \
the setUserAgentStylesheet method.</div><div><br></div><div>I'll just note that \
we don't just want the applications to be light or dark depending on what is set \
in the Operating System. You'll also want the ability to set whether the app is \
in dark or light mode on a per application level irrespective of what is defined in \
the OS (this already happens on many existing applications out there). So I think \
that DarkModeAware interface would have to have a method like:</div><div> ThemeMode \
getMode();<br>Where ThemeMode can either be LIGHT, DARK or OS_DEFINED (I've \
named it ThemeMode just as an example).</div><div><br></div><div>So I think we could \
do it in 2 ways: one way would be to do it as you say (though DarkModeAware interface \
would need the getMode() method that I suggested, I think) or add a method in the \
StyleTheme interface itself in a future release: <br> ThemeMode \
getMode();</div><div>That method would probably need to have a default implementation \
that simply returns LIGHT because of retro \
compatibility.</div><div><br></div><div>So, ThemeMode could be one of 3 possible \
values: LIGHT, DARK or OS_DEFINED. Where OS_DEFINED means that the app will honor \
whatever is defined at the OS level.</div><div>JavaFX Window decorations would need \
to respect whatever is returned in this getMode() method and change their decorations \
to either LIGHT or DARK depending on its value. This would also remove the need for \
boilerplate code that for every Window that is created sets it to be LIGHT or DARK \
depending on whether the Theme is LIGHT or DARK.</div><div><br></div><div>Of course, \
we can also simply support this from the get go and have this method exist in \
StyleTheme from the start.</div><div><br></div><div>Thanks \
again,</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> \
</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Sun, Jan 22, 2023 at 12:51 AM Michael Strauß <<a \
href="mailto:michaelstrau2@gmail.com" target="_blank">michaelstrau2@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Pedro,<br> <br>
see my comments below.<br>
<br>
<br>
On Sat, Jan 21, 2023 at 5:19 PM Pedro Duque Vieira<br>
<<a href="mailto:pedro.duquevieira@gmail.com" \
target="_blank">pedro.duquevieira@gmail.com</a>> wrote:<br> > I've been \
building javafx themes for years now. Started creating JMetro in JavaFX version 2. \
During this time I've been following how other themes are being built and I can \
say that about 90% of the themes (rough estimate) that are out there, are composed of \
author stylesheets, i.e they override values set from code (including JMetro).<br> \
> I agree that themes that are to be provided to other developers would probably \
be better off if they are user agent stylesheets. My point is that migrating those \
90% of themes to use this API would be easier if this flag exists otherwise migration \
would likely introduce UI regressions for developers using those themes.<br> ><br>
> To be clear, what I'm proposing is a flag, or enum, or whatever, in \
StyleTheme that defines whether the stylesheets in the StyleTheme should be a user \
agent stylesheet or author stylesheet.<br> ><br>
> Another point is in making themes that are only to be used locally in a specific \
app that the developer is creating. It might be of interest that he can toggle this \
flag and make all settings defined in the theme override any styling set from code \
(or in FXML) so that he can have a centralized point where all styling is done.<br> \
<br> I think that the likelihood of this feature making it into the 21<br>
release dramatically increases if we keep changes to the CSS subsystem<br>
to an absolute minimum. I understand your point, but I want to deliver<br>
this feature in the smallest useful package and add more features<br>
later with follow-on PRs.<br>
<br>
That's why I've renamed `Application.styleTheme` to<br>
`Application.userAgentStyleTheme`. This makes it unmistakably clear<br>
that we're only talking about user-agent stylesheets.<br>
Also, it leaves open the possibility to add the<br>
`Application.styleTheme` property later, which would cause the theme<br>
to be interpreted as comprised of author stylesheets.<br>
Classifying author/UA themes at the property level is also more<br>
consistent with the way author/UA stylesheets are currently classified<br>
in JavaFX.<br>
What do you think about the styleTheme/userAgentStyleTheme API,<br>
instead of having a flag in the implementation of StyleTheme itself?<br>
<br>
Since one of the objectives of the PR is to promote Caspian and Modena<br>
to first-class theme implementations, it makes sense to focus on UA<br>
themes first (since built-in themes are comprised of UA stylesheets).<br>
<br>
<br>
<br>
> 3 -<br>
> Style themes are generally either defined as dark or light. i.e. you'll very \
rarely have a theme that has some Windows with dark decorations and others with light \
decorations. So I think it makes sense to have this as a theme property.<br> > The \
ability to toggle decorations (light or dark) on an individual Window is a good point \
you're making. Perhaps we should have a global definition in the StyleTheme \
(whether the theme is light or dark) and a definition that can be set per Window.<br> \
> If you set it on the StyleTheme then all Windows will respect it, but you can \
override that value on each Window. If you override it on a specific Window, that \
definition would take precedence over the global StyleTheme one.<br> <br>
In general, StyleTheme is a very simple concept: it's a dynamic<br>
collection of stylesheets.<br>
I don't think the interface should force implementers to deal with<br>
anything other than stylesheets. If we did that, the following code<br>
wouldn't work any more:<br>
<br>
Application.setUserAgentStyleTheme(<br>
() -> List.of("stylesheet1.css", \
"stylesheet2.css");<br> <br>
Maybe we can add a new interface, for example DarkModeAware, and if an<br>
application theme is marked with this interface, JavaFX will try to<br>
respect dark/light mode for platform decorations:<br>
<br>
public class MyCustomTheme implements StyleTheme, DarkModeAware {<br>
@Override<br>
public List<String> getStylesheets() {<br>
return List.of("stylesheet1.css", \
"stylesheet2.css");<br> }<br>
}<br>
<br>
// Setting a DarkModeAware theme causes JavaFX to draw light or<br>
// dark platform decorations by default, depending on the current<br>
// platform preference. If the theme is not DarkModeAware, JavaFX<br>
// defaults to light decorations.<br>
//<br>
Application.setUserAgentStyleTheme(new MyCustomTheme());<br>
<br>
In any case, I think we can deliver this feature in a follow-on PR.<br>
<br>
<br>
> 4-<br>
>><br>
>> If we wanted to expose this front-and-center, we could add these<br>
>><br>
>> properties to the Platform.Properties interface:<br>
><br>
><br>
>> public interface Preferences extends ObservableMap<String, \
Object> {<br> >> ReadOnlyBooleanProperty \
darkModeProperty();<br> >> ReadOnlyObjectProperty<Color> \
accentColorProperty();<br> >> ...<br>
>> }<br>
><br>
><br>
> Yes, I think that would be great.<br>
<br>
Let's see what other people think.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div \
dir="ltr"><div>Pedro Duque Vieira - <a href="https://www.pixelduke.com" \
target="_blank">https://www.pixelduke.com</a></div></div></div> \
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" \
class="gmail_signature"><div dir="ltr"><div>Pedro Duque Vieira - <a \
href="https://www.pixelduke.com" \
target="_blank">https://www.pixelduke.com</a></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic