Re: [External] : Re: UI elements sizing in Modena.css
I don't know the internals of the JavaFX CSS parser but regarding the CSS
variable spec itself we could start by simply supporting numeric values as
well as colors. This would already allow developers to use variables
anywhere which would simplify and make managing stylesheets easier.
On Wed, Jul 10, 2024 at 6:24 PM Andy Goryachev
wrote:
> I agree - having CSS variables will definitely help. Personally, I would
> rather see a better way to create stylesheets programmatically, bypassing
> the whole parsing routine, but I am sure a lot of people would be more
> comfortable if things were similar to web css.
>
>
>
> Enabling CSS variables seems to me like a lot of work though, but I could
> be mistaken. Any ideas how to add support for CSS variables to JavaFX?
>
>
>
> -andy
>
>
>
> *From: *Pedro Duque Vieira
> *Date: *Tuesday, July 9, 2024 at 15:51
> *To: *Andy Goryachev
> *Cc: *openjfx-dev@openjdk.org
> *Subject: *[External] : Re: UI elements sizing in Modena.css
>
> .. one more reason to use the CSS variable spec that I forgot to mention:
>
> 5 - It's a spec that has been thoroughly thought of before it was added
> to CSS and it has stood the test of time.
>
>
>
> On Tue, Jul 9, 2024 at 11:04 PM Pedro Duque Vieira <
> pedro.duquevie...@gmail.com> wrote:
>
> Andy, if I understand the suggestion correctly, you want to set the Modena
> sizes using variables that can be easily overridden. To that effect
> variables must first be able to hold numeric values as, as it stands today
>
> JavaFX only allows colors to be used for CSS variables.
>
> So, you're also suggesting adding the ability for CSS variables to define
> inset values, is that correct?
>
>
>
> I think that's a good idea. I would, however, generalize that to allow CSS
> variables to hold numeric values that could be used anywhere. Or at least,
> starting to pave the ground for that.
>
>
>
> I would go even further and start to pave ground to add the CSS
> variable spec into javafx css:
> https://codersblock.com/blog/what-can-you-put-in-a-css-variable/
> <https://urldefense.com/v3/__https:/codersblock.com/blog/what-can-you-put-in-a-css-variable/__;!!ACWV5N9M2RV99hQ!JG_yI0ZU2mSJRD8IIa8A04SIQyiSaLmkkxdi65Y7JnmS-xaLYYxfHQr1AbFvjWh3DI0mYXqpcVPYrO4-WFHwnh4TwUIZ99I$>
>
>
>
> Why use the css web spec? Because of the following reasons:
>
> 1 - Designers already know how to work with the css web spec
>
> 2 - there are already many tools available that work with the css web spec
>
> 3 - there are already many examples on the web using CSS so developers can
> just copy paste those examples
>
> 4 - Developers coming from the web can easily start using javafx css with
> no friction and no need to learn it
>
>
>
> Thanks
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Jul 9, 2024 at 9:04 PM Andy Goryachev
> wrote:
>
> Since we touched the modena.css, I would like to ask the group's opinion
> on whether we should fix the way modena.css sizes UI elements. Please see
> https://bugs.openjdk.org/browse/JDK-8314683 for reference, where changing
> the font size also unexpectedly changed the scrollbar.
>
>
>
> What do you think about introducing a set of variables similar to -fx-base
> but for sizing/padding, placing them early on to depend on the font size in
> the .root selector instead of the font in the actual control? Something
> along the lines of
>
>
>
> .root {
>
> -fx-size-3px: 0.25em;
>
> ...
>
> }
>
>
>
> .scroll-bar:horizontal > .increment-button > .increment-arrow {
>
> -fx-padding: -fx-size-3px -fx-size-3px -fx-size-3px -fx-size-3px;
>
> }
>
>
>
> instead of
>
>
>
> .scroll-bar:horizontal > .increment-button > .increment-arrow {
>
> -fx-padding: 0.333em 0.167em 0.333em 0.167em; /* 4 2 4 2 */
>
> }
>
>
>
> This way we still permit the UI components resize with the main font,
> while keeping the sizes of all the control surfaces consistent?
>
>
>
> This will require a trivial change in InsetsConverter.
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
> --
>
> Pedro Duque Vieira (Duke) - https://www.pixelduke.com
> <https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!JG_yI0ZU2mSJRD8IIa8A04SIQyiSaLmkkxdi65Y7JnmS-xaLYYxfHQr1AbFvjWh3DI0mYXqpcVPYrO4-WFHwnh4TjKYj490$>
>
>
>
>
> --
>
> Pedro Duque Vieira (Duke) - https://www.pixelduke.com
> <https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!JG_yI0ZU2mSJRD8IIa8A04SIQyiSaLmkkxdi65Y7JnmS-xaLYYxfHQr1AbFvjWh3DI0mYXqpcVPYrO4-WFHwnh4TjKYj490$>
>
--
Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Re: UI elements sizing in Modena.css
.. one more reason to use the CSS variable spec that I forgot to mention:
5 - It's a spec that has been thoroughly thought of before it was added to
CSS and it has stood the test of time.
On Tue, Jul 9, 2024 at 11:04 PM Pedro Duque Vieira <
pedro.duquevie...@gmail.com> wrote:
> Andy, if I understand the suggestion correctly, you want to set the Modena
> sizes using variables that can be easily overridden. To that effect
> variables must first be able to hold numeric values as, as it stands today
> JavaFX only allows colors to be used for CSS variables.
> So, you're also suggesting adding the ability for CSS variables to define
> inset values, is that correct?
>
> I think that's a good idea. I would, however, generalize that to allow CSS
> variables to hold numeric values that could be used anywhere. Or at least,
> starting to pave the ground for that.
>
> I would go even further and start to pave ground to add the CSS
> variable spec into javafx css:
> https://codersblock.com/blog/what-can-you-put-in-a-css-variable/
>
> Why use the css web spec? Because of the following reasons:
> 1 - Designers already know how to work with the css web spec
> 2 - there are already many tools available that work with the css web spec
> 3 - there are already many examples on the web using CSS so developers can
> just copy paste those examples
> 4 - Developers coming from the web can easily start using javafx css with
> no friction and no need to learn it
>
> Thanks
>
>
>
>
>
> On Tue, Jul 9, 2024 at 9:04 PM Andy Goryachev
> wrote:
>
>> Since we touched the modena.css, I would like to ask the group's opinion
>> on whether we should fix the way modena.css sizes UI elements. Please see
>> https://bugs.openjdk.org/browse/JDK-8314683 for reference, where
>> changing the font size also unexpectedly changed the scrollbar.
>>
>>
>>
>> What do you think about introducing a set of variables similar to
>> -fx-base but for sizing/padding, placing them early on to depend on the
>> font size in the .root selector instead of the font in the actual control?
>> Something along the lines of
>>
>>
>>
>> .root {
>>
>> -fx-size-3px: 0.25em;
>>
>> ...
>>
>> }
>>
>>
>>
>> .scroll-bar:horizontal > .increment-button > .increment-arrow {
>>
>> -fx-padding: -fx-size-3px -fx-size-3px -fx-size-3px -fx-size-3px;
>>
>> }
>>
>>
>>
>> instead of
>>
>>
>>
>> .scroll-bar:horizontal > .increment-button > .increment-arrow {
>>
>> -fx-padding: 0.333em 0.167em 0.333em 0.167em; /* 4 2 4 2 */
>>
>> }
>>
>>
>>
>> This way we still permit the UI components resize with the main font,
>> while keeping the sizes of all the control surfaces consistent?
>>
>>
>>
>> This will require a trivial change in InsetsConverter.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> -andy
>>
>
>
> --
> Pedro Duque Vieira (Duke) - https://www.pixelduke.com
>
--
Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Re: UI elements sizing in Modena.css
Andy, if I understand the suggestion correctly, you want to set the Modena
sizes using variables that can be easily overridden. To that effect
variables must first be able to hold numeric values as, as it stands today
JavaFX only allows colors to be used for CSS variables.
So, you're also suggesting adding the ability for CSS variables to define
inset values, is that correct?
I think that's a good idea. I would, however, generalize that to allow CSS
variables to hold numeric values that could be used anywhere. Or at least,
starting to pave the ground for that.
I would go even further and start to pave ground to add the CSS
variable spec into javafx css:
https://codersblock.com/blog/what-can-you-put-in-a-css-variable/
Why use the css web spec? Because of the following reasons:
1 - Designers already know how to work with the css web spec
2 - there are already many tools available that work with the css web spec
3 - there are already many examples on the web using CSS so developers can
just copy paste those examples
4 - Developers coming from the web can easily start using javafx css with
no friction and no need to learn it
Thanks
On Tue, Jul 9, 2024 at 9:04 PM Andy Goryachev
wrote:
> Since we touched the modena.css, I would like to ask the group's opinion
> on whether we should fix the way modena.css sizes UI elements. Please see
> https://bugs.openjdk.org/browse/JDK-8314683 for reference, where changing
> the font size also unexpectedly changed the scrollbar.
>
>
>
> What do you think about introducing a set of variables similar to -fx-base
> but for sizing/padding, placing them early on to depend on the font size in
> the .root selector instead of the font in the actual control? Something
> along the lines of
>
>
>
> .root {
>
> -fx-size-3px: 0.25em;
>
> ...
>
> }
>
>
>
> .scroll-bar:horizontal > .increment-button > .increment-arrow {
>
> -fx-padding: -fx-size-3px -fx-size-3px -fx-size-3px -fx-size-3px;
>
> }
>
>
>
> instead of
>
>
>
> .scroll-bar:horizontal > .increment-button > .increment-arrow {
>
> -fx-padding: 0.333em 0.167em 0.333em 0.167em; /* 4 2 4 2 */
>
> }
>
>
>
> This way we still permit the UI components resize with the main font,
> while keeping the sizes of all the control surfaces consistent?
>
>
>
> This will require a trivial change in InsetsConverter.
>
>
>
> What do you think?
>
>
>
> -andy
>
--
Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Yes, you're right. Need to find time to file those issues. Though I want to finish the theme conversion to user agent stylesheets and then be sure it is a javafx bug. On Tue, Jul 9, 2024 at 8:34 PM Andy Goryachev wrote: > Thank you for clarification! > > > > Glad you were able to do what you wanted. But really, if there are bugs, > I would rather have them filed and fixed. > > > > -andy > > > > > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 12:26 > *To: *Andy Goryachev > *Cc: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Perhaps I should have been clearer. I mentioned that example merely to > make a point on how having a stylesheet set as an AUTHOR stylesheet can be > a problem (Modena or a custom theme library like JMetro) :-) . > It wasn't actually to create a new separate discussion. > > > > As for the other discussion not exactly related to the one in this thread > (having custom themes be user agent stylesheets) I think I have found a way > to make multiple stylesheets be a user agent stylesheet. > > That was my main problem as JMetro is composed of more than 1 stylesheet. > I'm also doing it while still just using the javafx standard API. Thus far > it's working except for some minor bugs (which I'm inclined to think are > bugs in JavaFX itself). > > > > Thanks! > > > > On Tue, Jul 9, 2024 at 8:17 PM Andy Goryachev > wrote: > > If your stylesheet defines the necessary variables, the "users" should be > able to redefine them, correct? > > > > Or maybe allow for programmatic control of the stylesheet, similar to > > > https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31 > <https://urldefense.com/v3/__https:/github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java*L31__;Iw!!ACWV5N9M2RV99hQ!JM0pqIGTO_sPclbb2MbtvHgeNEDFgduJbJorYQTyhqptr9KT3ceFnMAznrQH610hptO_dhJUC7Cp2dssqEcpNKskcKgEqM8$> > > > https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java > <https://urldefense.com/v3/__https:/github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java__;!!ACWV5N9M2RV99hQ!JM0pqIGTO_sPclbb2MbtvHgeNEDFgduJbJorYQTyhqptr9KT3ceFnMAznrQH610hptO_dhJUC7Cp2dssqEcpNKskOaoBCDc$> > > > > Alternatively, we would need a new public API to allow you to do what you > want how you want. Perhaps if you could tell us about the problem you are > trying to solve, exactly, and the APIs that are missing. > > > > -andy > > > > > > > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 12:00 > *To: *Andy Goryachev > *Cc: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > >> That's why now in the new theme I'm creating I'm setting everything > to be an user agent stylesheet. > > > > > and this is probably the right approach. > > > > Correct. That's why I agree with John and why the current behavior is > likely undesired. :-) > > > > On Tue, Jul 9, 2024 at 7:40 PM Andy Goryachev > wrote: > > > That's why now in the new theme I'm creating I'm setting everything to > be an user agent stylesheet. > > > > and this is probably the right approach. > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Tuesday, July 9, 2024 at 11:28 > *To: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Hi guys, > > > > I agree with John Hendrikx on this. > > > > The thing is not that you override the "css variable" value but that you > end up overriding the priority of the rules in Modena which the developer > won't likely want to. > > > > One other thing I'd add is that developers also like to use css > themselves. If modena rules suddenly start to have the priority of AUTHOR > this becomes much harder. They have to make their rules always more > specific than Modena's that now have increased priority besides the fact > that they need to be aware that this is actually happening and is the > problem (in my experience many developers won't know this). > > > > On a related note, I created a theme called JMetro. When implementing it I > made it so that it was composed of author stylesheets (there wasn't a way > to set it as a user agent stylesheet back when I started)
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Perhaps I should have been clearer. I mentioned that example merely to make a point on how having a stylesheet set as an AUTHOR stylesheet can be a problem (Modena or a custom theme library like JMetro) :-) . It wasn't actually to create a new separate discussion. As for the other discussion not exactly related to the one in this thread (having custom themes be user agent stylesheets) I think I have found a way to make multiple stylesheets be a user agent stylesheet. That was my main problem as JMetro is composed of more than 1 stylesheet. I'm also doing it while still just using the javafx standard API. Thus far it's working except for some minor bugs (which I'm inclined to think are bugs in JavaFX itself). Thanks! On Tue, Jul 9, 2024 at 8:17 PM Andy Goryachev wrote: > If your stylesheet defines the necessary variables, the "users" should be > able to redefine them, correct? > > > > Or maybe allow for programmatic control of the stylesheet, similar to > > > https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31 > > > https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java > > > > Alternatively, we would need a new public API to allow you to do what you > want how you want. Perhaps if you could tell us about the problem you are > trying to solve, exactly, and the APIs that are missing. > > > > -andy > > > > > > > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 12:00 > *To: *Andy Goryachev > *Cc: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > >> That's why now in the new theme I'm creating I'm setting everything > to be an user agent stylesheet. > > > > > and this is probably the right approach. > > > > Correct. That's why I agree with John and why the current behavior is > likely undesired. :-) > > > > On Tue, Jul 9, 2024 at 7:40 PM Andy Goryachev > wrote: > > > That's why now in the new theme I'm creating I'm setting everything to > be an user agent stylesheet. > > > > and this is probably the right approach. > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Tuesday, July 9, 2024 at 11:28 > *To: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Hi guys, > > > > I agree with John Hendrikx on this. > > > > The thing is not that you override the "css variable" value but that you > end up overriding the priority of the rules in Modena which the developer > won't likely want to. > > > > One other thing I'd add is that developers also like to use css > themselves. If modena rules suddenly start to have the priority of AUTHOR > this becomes much harder. They have to make their rules always more > specific than Modena's that now have increased priority besides the fact > that they need to be aware that this is actually happening and is the > problem (in my experience many developers won't know this). > > > > On a related note, I created a theme called JMetro. When implementing it I > made it so that it was composed of author stylesheets (there wasn't a way > to set it as a user agent stylesheet back when I started). That's also how > 90% of themes work. > > However this is an issue as developers wanting to override styles set by > JMetro will have a hard time figuring out how to make their rules > specificity in their CSS higher than JMetro's so they get overridden (I've > had complaints on this). That's why now in the new theme I'm creating I'm > setting everything to be an user agent stylesheet. > > > > Thanks, > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > <https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!NnLY0nSsEY93YxbhJsdC4TvA_CwObtH-KxcDs-JoCjZJZuX50rhGPjVRRbkZRNsLFo819RzmhmodWXd_NsA8s_UqbxTANLg$> > > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > <https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!NnLY0nSsEY93YxbhJsdC4TvA_CwObtH-KxcDs-JoCjZJZuX50rhGPjVRRbkZRNsLFo819RzmhmodWXd_NsA8s_UqbxTANLg$> > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Re: [External] : Re: CSS Lookups and their origins (possible regression)
>> That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. > and this is probably the right approach. Correct. That's why I agree with John and why the current behavior is likely undesired. :-) On Tue, Jul 9, 2024 at 7:40 PM Andy Goryachev wrote: > > That's why now in the new theme I'm creating I'm setting everything to > be an user agent stylesheet. > > > > and this is probably the right approach. > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Tuesday, July 9, 2024 at 11:28 > *To: *openjfx-dev@openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Hi guys, > > > > I agree with John Hendrikx on this. > > > > The thing is not that you override the "css variable" value but that you > end up overriding the priority of the rules in Modena which the developer > won't likely want to. > > > > One other thing I'd add is that developers also like to use css > themselves. If modena rules suddenly start to have the priority of AUTHOR > this becomes much harder. They have to make their rules always more > specific than Modena's that now have increased priority besides the fact > that they need to be aware that this is actually happening and is the > problem (in my experience many developers won't know this). > > > > On a related note, I created a theme called JMetro. When implementing it I > made it so that it was composed of author stylesheets (there wasn't a way > to set it as a user agent stylesheet back when I started). That's also how > 90% of themes work. > > However this is an issue as developers wanting to override styles set by > JMetro will have a hard time figuring out how to make their rules > specificity in their CSS higher than JMetro's so they get overridden (I've > had complaints on this). That's why now in the new theme I'm creating I'm > setting everything to be an user agent stylesheet. > > > > Thanks, > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Re: [External] : Re: CSS Lookups and their origins (possible regression)
Hi guys, I agree with John Hendrikx on this. The thing is not that you override the "css variable" value but that you end up overriding the priority of the rules in Modena which the developer won't likely want to. One other thing I'd add is that developers also like to use css themselves. If modena rules suddenly start to have the priority of AUTHOR this becomes much harder. They have to make their rules always more specific than Modena's that now have increased priority besides the fact that they need to be aware that this is actually happening and is the problem (in my experience many developers won't know this). On a related note, I created a theme called JMetro. When implementing it I made it so that it was composed of author stylesheets (there wasn't a way to set it as a user agent stylesheet back when I started). That's also how 90% of themes work. However this is an issue as developers wanting to override styles set by JMetro will have a hard time figuring out how to make their rules specificity in their CSS higher than JMetro's so they get overridden (I've had complaints on this). That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. Thanks, -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com
Aw: Re: Validation Support
Regarding the comment that the design of JavaFX is vastly superior to Swing.. I would argue against bluntly stating that (not criticizing who said that). There are obviously cons and pros to each approach. On the one side Swing was much easier for developers to extend and to add functionality on top whereas JavaFX is harder. JavaFX on the other hand can evolve in a more safe way since the implementation details are less exposed to developers. I wouldn't say one is better than the other, I guess it depends on the scenario you're in. There are pros and cons to each. There are certainly lots of developers that preferred the Swing approach (myself included) and others would probably prefer the JavaFX one (not sure which one the majority prefers). When the JavaFX team first made this decision there were some conditions that don't hold true anymore, so the underlying scenario has changed. Back then it was assumed that the user would be the one responsible for installing and updating the JRE that was going to be used in the app (so you were never sure which jre the user was on). That's no longer the case as almost all apps ship with its own JRE. More importantly, back then the javafx team was much bigger, so changes could be made at a faster pace. Yes JavaFX was closed but if the JavaFX team saw there was a need from developers for some feature/API it could be added much more quickly while still not exposing too much of the implementation. I wonder if in some parts we can compromise if we see there's a need. Like exposing some parts but adding a annotation or something saying that we're still experimenting or/and some scenarios might not be supported, so be careful using this, etc... (that's somewhat already happened in javafx 8 with the @treatAsPrivate annotation) Just some food for thought... I like the compromise that John Hendrikx suggested of copy pasting code and changing the copy pasted code (given the internal API usage is solved). I have done that sometimes. I just have one question though: does the license of JavaFX permit a commercial app to have that in its own app (copy pasted code from the JavaFX SDK)? I have already said that, but what I really would like JavaFX to provide would be more points of extension, things like the possibility to extend the CSS parser and add more CSS primitives, etc... Bottom line: make the API more powerful in terms of what the developer can do. Right now if you want to do something slightly less standard you're likely to hit a bunch of hurdles... My 2 cents.. -- Pedro Duque Vieira - https://www.pixelduke.com
Re: Proposal: RichTextArea Control (Incubator)
Hi, I agree with what others are saying that perhaps creating and adding this control is not a priority now for the JavaFX team. In an ideal world where the JavaFX team had more resources to implement things (like the team JavaFX had at the time of JavaFX 8 and before), this would make sense. Given the limited resources, IMHO time would be perhaps better spent elsewhere, adding much needed features to the core of JavaFX. Things that can only be implemented by the developers working on the SDK. Given this is a control that can be implemented by library developers and given there are already third parties that provide this I don't think creating this should be a priority. Providing more hooks for developers to extend javafx functionality (to counteract the fact that JavaFX is so closed up for extension), implementing missing features in the JavaFX SDK, perhaps even things that would make it easier for library developers to implement a RichTextArea, would IMHO be more of a priority. My 2 cents, Thanks, kind regards, -- Pedro Duque Vieira - https://www.pixelduke.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> Sem vírus.www.avg.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Re: Preview features for JavaFX
Hi, Just adding my 2 cents to the discussion. I think there's a precedent to this that the JavaFX team was using back in JavaFX 8 and before it. It wasn't for preview features, but it had a somewhat similar purpose. There was an "@treatAsPrivate" annotation. This annotation was used in methods that were only meant to be used internally by JavaFX itself. They were an implementation detail. They could be used by programmers, but they had a risk of being removed or their behavior later being changed entirely. That annotation seemed to be enough. Some developers used these methods (including myself), and I don't remember any issues with this. Developers were well aware these methods could get removed and some of them have actually been removed. (I think they were also marked with the "@Deprecated" annotation so that you had an extra warning from the IDE, and the @treatAsPrivate annotation also hid them from the javadocs). I like the idea of preview features. Some features need to be tested by programmers for a long time before we are sure they can be set in stone. Like others have said this could also allow features to come out quicker. Thanks! Kind regards, -- Pedro Duque Vieira - https://www.pixelduke.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> Sem vírus.www.avg.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Re: The crisp fonts saga
No you're not alone on this...
I've been complaining of poor text rendering quality on JavaFX for years
now. Though in my case, I was complaining about javafx font rendering on
Windows.
Some of the times I use to call this, that seems to improve font rendering
somewhat on some systems:
System.setProperty("prism.lcdtext", "false");
Javafx font rendering on Mac OS is better than on Windows.
When I worked for a very well known company here, we used to do all the
product screenshots on Mac because it would look noticeably better than on
Windows (I use Windows) because of the poor font rendering quality on that
OS. Given the majority of desktop users use Windows this is even more
of a problem.
My 2 cents. Cheers,
--
Pedro Duque Vieira - https://www.pixelduke.com
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Sem
vírus.www.avg.com
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
RE: My JavaFX Christmas Wishlist
In the spirit of Christmas and of this thread here is my wish list 1 - The number one thing I’d change would be to make JavaFX “more extendable”. By this I mean having more hooks to extend core areas of JavaFX (CSS parser, 3D, etc). The reason I ask for this is because it’s much easier for an outsider to add functionality to JavaFX by developing his own library that interfaces with the javafx platform than it is to actually contribute code to the core platform itself. For a number of reasons, like: the goals of the contributor might not align with the people managing the platform, it’s much more work and has a much stepper learning curve to contribute code to the platform, the core platform needs to maintain backwards compatibility, etc.. I believe this could make JavaFX evolve faster and more. Imagine if a JavaFX library developer could extend everything about the JavaFX CSS engine to add functionality like layout, animations, etc, etc (all the bells and whistles you now see in web css). Or imagine if you could more easily extend 3D with new 3D primitives, etc.. 2 – Add the possibility of specifying more than 1 stylesheet as the user agent stylesheet (also possible with the new StyleTheme API proposal). There’s a missing piece when it comes to allowing developers to create custom themes: you can’t specify more than 1 stylesheet to be the user agent stylesheet. This would be a rather easy change that I think could provide a big value. 3 – Pixel shaders. The most stunning things in the UI space nowadays are being created by leveraging pixel shaders. This is something that for instance Jetpack Compose (and Skia) provides and other UI frameworks have as well. 4 – Improve font rendering (seems to affect Windows more than Mac) 5 – Background blur 6 – JavaFX Skin having a better separation between view and controller part. Right now you have the model (the class extending from JavaFX Control) but you don’t have a clear View. In all javafx sdk controls both Controller and View are present in the same Skin class. 7 – New TableView Thanks! And Merry Christmas to everyone (although it's still more than 1 month till Christmas ) -- Pedro Duque Vieira - https://www.pixelduke.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> Sem vírus.www.avg.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Re: [External] : Re: [Request for Comments] Behavior / InputMap
Yes Input Map would be a welcome addition. -- Talking about the Skin discussion: Right now, I think Skins do both the Controller and View part of a Control, making it really difficult to replace, extend, etc a Control's Skin... I would have to think much more about this but I could see some kind of View class that Skin references. In this View class, we would define just how the control represents itself visually, that is, visual nodes, layout and animations. The Skin would take care of handling events from the View and updating the Model appropriately (the Model being the part that developers already interact with in a JavaFX Control - the class that extends Control), that is, just being a kind of Controller. Main purpose would be to make it as easy as possible for developers to update a Control's visuals (layout, animation, etc). Right now it's a really hard task and 99% of developers just prefer to create a whole new control altogether rather than replace its Skin (even if they just want to slightly tweak an existing control's visuals). In this case developers would replace the "View" class with their own implementation, adding new animations, new visuals, etc... This would allow for a much easier customization of visuals while still maintaining about the same code in the application (the application code being everything else except the Skins' code). This would also allow a new echo system of Skin libraries to start to appear. These libraries would be interchangeable and would allow developers to easily update and enhance the visuals of their apps by setting a skin library. This is what the library I've created FXSkins does ( https://github.com/dukke/FXSkins), that is, it allows a developer to enhance their app's visuals very easily without changing one line of code in their app. The difference is that if JavaFX Skins architecture were defined as I mentioned above it would be much easier for me to develop FXSkins and there would probably be more libraries like this, created by other developers. Thanks Andy! Kind regards, On Mon, Oct 16, 2023 at 6:51 PM Andy Goryachev wrote: > Thank you for clarification! > > > > I just want to mention that here we are straying into what looks like a > parallel discussion about skins (nothing wrong about it!). > > > > just the Skin part. This would likely be a big effort but perhaps it could > be split into smaller tasks till the end goal is achieved. > > > > Could you please expand upon this? What parts should skins be split into? > > > > As it currently stands, Skins have two responsibilities - visual > representation (the View in MVC paradigm) and handling of events, currently > represented by the private behavior implementation. In some sense, > behaviors and skins are tightly coupled - it would be hard, in my opinion, > to separate them without introducing large public API surface and > consequently solidifying certain aspects of one particular implementation. > > > > As far as I can tell, the input map proposal addresses the low hanging > fruit of simple customization like your case of unregistering all key > mappings from the ScrollPane. It is certainly not a call to a major > redesign. > > > > Cheers, > > -andy > > > > *From: *Pedro Duque Vieira > *Date: *Sunday, October 15, 2023 at 05:11 > *To: *Andy Goryachev > *Cc: *openjfx-dev@openjdk.org > *Subject: *[External] : Re: [Request for Comments] Behavior / InputMap > > Hi Andy, > > > > Sorry for the late reply but unfortunately I didn't have time to respond > to you earlier. > > > > Yes, you're right, Swing did allow for easier extension of controls' > themes and you did see people coming up with new theme libraries that > overwrote Controls appearance/behavior through code. > > > > I think the main issue with Skins being difficult to extend is that > they're taking on too much responsibility. They do both the View and > Controller part of the Controls (the model being the part that developers > interact with). When I talk about MVC here I mean it in a loose way, I'm > referring to any and all the MVC like patterns. If for instance there was a > clear class, in the Skin architecture, that just took care of how a Control > is displayed, and nothing else, it would be easier to overwrite, for > example, how the Control is displayed and hence override Skins. > > > >- What are the missing APIs in Skins that we can add to simplify >extension of skins? > > I think, as I said above, Skins would have to have a different > architecture. IMHO, their responsibilities would likely have to be split > into different classes each with a smaller set of concerns. I'm not talking > about changing the whole Control architecture, just the Skin part. This > would
Re: RFR: 8301302: Platform preferences API [v15]
Yes please keep this open. Having adequate Theme development support would be great and I think wouldn't require much effort (right now custom theme support in JavaFX is faulty IMO). Looking forward to the StyleTheme API so you can define multiple stylesheets as user agent stylesheets. (sorry to be annoying about this but as a long time custom theme developer I've been looking forward to this for ages) > >> Please read [this document]( > https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an > introduction to the Platform Preferences API, and how it interacts with the > proposed style theme and stage appearance features. > > > > Michael Strau? has updated the pull request incrementally with one > additional commit since the last revision: > > > > Handle key removals Let's keep this open. -- Pedro Duque Vieira - https://www.pixelduke.com
Re: [Request for Comments] Behavior / InputMap
Hi Andy, Sorry for the late reply but unfortunately I didn't have time to respond to you earlier. Yes, you're right, Swing did allow for easier extension of controls' themes and you did see people coming up with new theme libraries that overwrote Controls appearance/behavior through code. I think the main issue with Skins being difficult to extend is that they're taking on too much responsibility. They do both the View and Controller part of the Controls (the model being the part that developers interact with). When I talk about MVC here I mean it in a loose way, I'm referring to any and all the MVC like patterns. If for instance there was a clear class, in the Skin architecture, that just took care of how a Control is displayed, and nothing else, it would be easier to overwrite, for example, how the Control is displayed and hence override Skins. - What are the missing APIs in Skins that we can add to simplify extension of skins? I think, as I said above, Skins would have to have a different architecture. IMHO, their responsibilities would likely have to be split into different classes each with a smaller set of concerns. I'm not talking about changing the whole Control architecture, just the Skin part. This would likely be a big effort but perhaps it could be split into smaller tasks till the end goal is achieved. - Would this proposal (BehaviorBase + InputMap) prevent us from moving forward? Likely no. BTW, in the past I already had the need for this API (InputMap) for an application I was developing that's now in production. To do what I needed I had to call on private methods using reflection, etc, since there's no public API to achieve this yet. My use case was that I was creating a custom control, "inside" that control I used a ScrollPane but ScrollPane has a bunch of default key mappings, like SPACE, PAGE_UP, PAGE_DOWN, HOME that when pressed already do predefined things. I needed to remove those key mappings as in this application those keys were already meant to do something else other than what the default JavaFX ScrollPane does with them. Thnaks. Kind regards, On Mon, Oct 9, 2023 at 7:38 PM Andy Goryachev wrote: > Thank you for the feedback! > > > > You are right: even though Skins are public classes now, they are very > difficult to extend – at least, much more difficult that Swing UIs. It’s a > source of constant discussions within the team – how much of it should be > made public (protected) to allow for extension vs. how much of it should be > hidden as implementation detail to minimize the API surface and allow for > evolution. While opening it all up might alleviate developers’ pain when > extending, it poses a great(er) danger of introducing of all sorts of > compatibility issues with respect to bug fixes and other changes. > > > > If we speak about extending skins specifically, a good question might be: > what exactly is missing? Which APIs do we need to enable easier extension > of skins? > > > > One thing I would like to clarify is that the Behavior / InputMap proposal > is not about extending skins. It is also not about making the concrete > behaviors public (a task which is probably as large as adding missing > public APIs to skins). > > > > The main goal is to allow for extending and slightly modifying the > behavior – like altering the way navigation works in a text control, or > adding a new key binding. As a result, the overall proposal is smaller > than it could be. > > > > Having said that, nothing prevents us from exploring options to open up > skins, or making behaviors public. > > > > To summarize: > >- What are the missing APIs in Skins that we can add to simplify >extension of skins? >- Would this proposal (BehaviorBase + InputMap) prevent us from moving >forward? > > > > What do you think? > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Saturday, October 7, 2023 at 14:05 > *To: *openjfx-dev@openjdk.org > *Subject: *Re: [Request for Comments] Behavior / InputMap > > I second the opinions of others that JavaFX is too closed which, I think, > hinders the work of library and app developers. > > > > I wonder if the reasons that were used to make this design decision back > when JavaFX was being created still hold true. Back in the beginning there > were more developers involved in developing JavaFX, significant features > were added at a fast pace so the fact that it was closed wasn't such a big > drawback as things were changing quickly and missing features that were > spotted could be added relatively quick. > > > > Commenting more specifically on your question... I think Skins could > benefit generally from being easier to e
Re: [Request for Comments] Behavior / InputMap
I second the opinions of others that JavaFX is too closed which, I think, hinders the work of library and app developers. I wonder if the reasons that were used to make this design decision back when JavaFX was being created still hold true. Back in the beginning there were more developers involved in developing JavaFX, significant features were added at a fast pace so the fact that it was closed wasn't such a big drawback as things were changing quickly and missing features that were spotted could be added relatively quick. Commenting more specifically on your question... I think Skins could benefit generally from being easier to extend. The promise of skins is that you could easily replace a control behavior and visuals without changing its model (the model being the part of the control that developers usually interact with) but the problem is that the JavaFX SDK control's skins are very difficult to extend. Say, if you only want to add a specific visual feature (something that CSS can't do) it takes a significant effort. What you usually see is that developers opt to create completely new controls rather than just new skins. My attempt at providing new skins for existing javafx sdk controls is here: https://github.com/dukke/FXSkins Still it required quite a bit of effort.. at least more than it could ideally take (I think). The advantage of this kind of approach (providing new Skins) and the library I created "FXSkins" is that you can enhance the controls of your existing app very easily by setting new skins in the CSS stylesheet. You won't need to change anything directly in the code. Regarding the current state of the JavaFX SDK Skins, there isn't a clear MVC separation, the skin does the Controller and View part at the same time. Perhaps ideally there would be a clear View part that could easily be extended to add different advanced visuals to the control (by advanced I mean, anything that can't be done with CSS). And then perhaps also the Behavior part where you can easily change the control's functionality. I remember at some point Richard Bair saying that it was a goal to make Behaviors public. Thanks! -- Pedro Duque Vieira - https://www.pixelduke.com
Multiple stylesheets as user agent stylesheets feature
Hi all, One major pain point of developing custom themes is the fact that you can only specify 1 stylesheet as the user agent stylesheet. I develop custom themes to be used by application developers that are somewhat popular but this has been problematic for quite some time. Others, like Alessadro Parisi have also voiced their interest in having this (he developed MaterialFX also a quite popular theme). Any complex custom theme will at some point hit this issue. In my case JMetro / Transit have lots of CSS rules and 2 different styles (light and dark) making it very cumbersome (and not desirable or even feasible) to fit into 1 single stylesheet. What ends up happening in my case and probably others (90% of themes I know of use scene stylesheets rather than user agent stylesheet for the reasons mentioned) is that often users give up and just copy the stylesheet to their own app and tweak it. This is not ideal for various reasons, among them are: - Updates I do to my library will be hard to get through since they just copied the css code and tweaked it. They'll need to copy again and tweak again which most will probably not do. - Copyright and attribution. This breaks copyright, ideally they would use the library rather than copy the code into their app. - Themes are not just CSS and sometimes contain other things like custom skins, controls, etc.. Copy and Pasting is not ideal. (side note: Themes being composed of scene stylesheets means all styles set in code by the developer will be overridden by these stylesheets. Also these stylesheets will "compete" with stylesheets created by the developer in which case only the rules with the greatest specificity will win. This is a major hassle for app developers using these themes and why they sometimes prefer to just copy and tweak the stylesheets) I wonder, is this on the near future plans? This seems like it could be a quick win (?), i.e. instead of accepting just 1 stylesheet to be the user agent stylesheet, being able to accept multiple. This would also be one quick first step towards supporting the concept of Themes (there's already an issue that's meant to support it) or even if not supporting the concept of Themes would make a huge difference for custom Theme development. Thanks! -- Pedro Duque Vieira - https://www.pixelduke.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> Sem vírus.www.avg.com <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Re: Combining JavaFX with native UI and shaders?
There's this library: https://github.com/Teragam/JFXShader/ Hopefully JavaFX supports shaders in a near future. You can do incredible stuff with them and most recent UI libraries support them. :-) -- Pedro Duque Vieira - https://www.pixelduke.com
Re: RFR: 8301302: Platform preferences API [v3]
On Thu, 11 May 2023 14:38:01 GMT, Michael Strauß wrote: >> Hi all, >> >> First of all, thanks for the efforts to integrate this new API into JavaFX. >> As a style theme developer myself I think this API is missing nowadays and >> will be a good addition to the SDK! >> >> A comment not related to this specific PR but... the discussion about this >> new API was being held on the mailing list some time ago, I was also >> involved in that discussion. It stopped so I thought this wasn't going to go >> forward. I've only recently realized the discussion moved to here. So, my >> comment is: is there a centralized place to check on all the new >> developments in the javafx platform including ongoing efforts (I thought the >> mailing list was that place) ...? >> For instance, I was having a small discussion on Twitter with a prominent >> member of the JavaFX community about how having this kind of API would be of >> interest to JavaFX. I don't think anyone involved knows that this PR (that >> would add such a feature) is ongoing... they might also have interesting >> insights to add... > > @dukke I don't think there's a central place for all JavaFX discussions. I've > observed that high-level discussions seem to happen on the mailing list, > while discussions of concrete implementation proposals often happen on > GitHub. You didn't get any notifications on the mailing list for this PR > since it's still in the Draft state. > > That being said, this proposal seems to be stuck in the "do we want this in > JavaFX?" stage. @mstr2 I see minor bugs and minor features as well as implementation details being discussed in the mailing list. I think a centralized place to see all that's being done in the javafx sdk (including proposed features) would be nice. Personally, I feel that the ability to specify multiple user-agent stylesheets is a no-brainer. Right now, my javafx theme JMetro has to be composed of scene stylesheets which can be a hassle for many developers using it (given how it overrides styles set in code). The other features are also important and I would be happy to see them in the javafx sdk, especially since I'm a theme developer and I've been missing these features for a while. Perhaps if these features are discussed individually (for example only discussing the ability to have multiple user agent stylesheets) they would be "easier to sell"? And all the other ones, each in its own PR. At least they would be easier to discuss (as each PR would be less complex) and so potentially easier to sell. Without however missing the whole picture like you're doing here... - PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1544126580
Re: RFR: 8301302: Platform preferences API [v3]
On Thu, 2 Feb 2023 19:54:33 GMT, Michael Strauß wrote: >> Please read [this >> document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) >> for an introduction to the Platform Preferences API, and how it interacts >> with the proposed style theme and stage appearance features. > > Michael Strauß has updated the pull request with a new target base due to a > merge or a rebase. Hi all, First of all, thanks for the efforts to integrate this new API into JavaFX. As a style theme developer myself I think this API is missing nowadays and will be a good addition to the SDK! A comment not related to this specific PR but... the discussion about this new API was being held on the mailing list some time ago, I was also involved in that discussion. It stopped so I thought this wasn't going to go forward. I've only recently realized the discussion moved to here. So, my comment is: is there a centralized place to check on all the new developments in the javafx platform including ongoing efforts (I thought the mailing list was that place) ...? For instance, I was having a small discussion on Twitter with a prominent member of the JavaFX community about how having this kind of API would be of interest to JavaFX. I don't think anyone involved knows that this PR (that would add such a feature) is ongoing... they might also have interesting insights to add... - PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1543837458
Integrated: JDK-8090647: Mnemonics : on windows we should cancel the underscore latch when an app loses focus.
Hi, It's been a while (I've been on vacation, etc) but thank you very much for fixing this issue on such short notice! Thanks again, kind regards, -- Pedro Duque Vieira - https://www.pixelduke.com
Re: Alt key sticks even after app loses focus (JDK-8090647)
I'll try to convince them to allocate time to test this, otherwise I'll try
to see if I can test it in my free spare time.
Thanks,
On Sun, Feb 12, 2023 at 10:28 PM John Hendrikx
wrote:
> Well, it is not a permanent solution, just a way to test to see if it
> actually solves your problem.
>
> --John
> On 12/02/2023 23:23, Pedro Duque Vieira wrote:
>
> .. all in all of course, I'd prefer a solution that properly fixes this
> bug and not have to rely on hacks that are prone to break in the future or
> code that needs to circumvent encapsulation or the module system. So either
> one is unlikely to be a fix I'm happy with.
>
> Thanks for considering submitting a PR to properly fix this issue!
>
> Kind regards,
>
>
>
> On Sun, Feb 12, 2023 at 10:15 PM Pedro Duque Vieira <
> pedro.duquevie...@gmail.com> wrote:
>
>> John,
>>
>> Thank you very much for submitting a work around. Unfortunately, since
>> there were other higher priority bugs and features and we're very close to
>> a release, I wasn't allocated time to work on this much more than sending a
>> message to this mailing list to warn of the existence of this bug.
>> Not sure when I can get back to this. I'll submit your suggestion to the
>> dev team and if someone is allocated time to do it, I'll get back here and
>> let you know if it works.
>>
>> There's also this suggestion that I forgot to mention (I haven't been
>> able to test it though):
>> https://stackoverflow.com/questions/65765656/release-mnemonic-when-application-loses-focus
>>
>> Thanks again, kind regards,
>>
>>
>> On Sun, Feb 12, 2023 at 10:06 PM John Hendrikx
>> wrote:
>>
>>> I'm not sure if you are able to test this yourself, but I made a fix for
>>> this problem.
>>>
>>> You could potentially test it by copying the class `javafx.scene.Scene`
>>> in your project (without changing the package -- and if modules will allow
>>> it, I don't use them personally) and then using this piece of code:
>>>
>>> private void setWindowFocused(boolean value) {
>>> windowFocused = value;
>>>
>>> Node node = getFocusOwner();
>>> if (node != null) {
>>> node.setFocusQuietly(windowFocused, focusOwner.focusVisible);
>>> node.notifyFocusListeners();
>>> }
>>>
>>> if (windowFocused && accessible != null) {
>>> accessible.sendNotification(AccessibleAttribute.FOCUS_NODE);
>>> }
>>>
>>> if (!windowFocused) {
>>>
>>> getInternalEventDispatcher().getKeyboardShortcutsHandler().setMnemonicsDisplayEnabled(false);
>>> }
>>> }
>>>
>>> The last three lines are what I added. A quick test on Windows here
>>> shows that the mnemonics get disabled as soon as the window loses focus,
>>> and when returning, they're not responding as you'd expect.
>>>
>>> I'll submit a PR as well.
>>>
>>> --John
>>> On 12/02/2023 15:52, Pedro Duque Vieira wrote:
>>>
>>> The behavior on Windows is all over the place for different
>>>> applications.? I tested a few I've got running:
>>>
>>>
>>> Notepad, Notepad++, Eclipse:
>>>
>>>
>>> - Alt-down: Shows mnemonics on menu bar
>>>> - Alt-up: Highlights file menu on alt release
>>>> - Alt-tab: Shows mnemonics but doesn't highlight menu when it loses
>>>> focus; when returning, mnemonics still highlighted, but doesn't act on
>>>> them as menu not selected
>>>
>>>
>>> -> Looks buggy
>>>
>>>
>>> Thunderbird / Opera / Firefox:
>>>
>>>
>>> - Alt-down: nothing
>>>> - Alt-up: shows menu bar (it is hidden normally)
>>>> - Alt-tab: works as expected, no highlighting
>>>
>>>
>>> -> Looks well behaved
>>>
>>>
>>> Explorer / Excel / Wordpad:
>>>
>>>
>>> - Alt-down: nothing
>>>> - Alt-up: shows mnemonics
>>>> - Alt-tab: works as expected, no highlighting
>>>
>>>
>>> -> Looks well behaved
>>>
>>>
>>> Visual Studio Code:
>>>
>>>
>>> - Alt-down: Shows mnemonics on menu bar
>>>> - Alt-up: Highlights file menu on alt release
>>>> - Alt-tab: Shows mnemonics, but hides them once it loses focus; on
>>>> return doesn't show mnemonics
>>>
>>>
>
Re: Alt key sticks even after app loses focus (JDK-8090647)
.. all in all of course, I'd prefer a solution that properly fixes this bug
and not have to rely on hacks that are prone to break in the future or code
that needs to circumvent encapsulation or the module system. So either one
is unlikely to be a fix I'm happy with.
Thanks for considering submitting a PR to properly fix this issue!
Kind regards,
On Sun, Feb 12, 2023 at 10:15 PM Pedro Duque Vieira <
pedro.duquevie...@gmail.com> wrote:
> John,
>
> Thank you very much for submitting a work around. Unfortunately, since
> there were other higher priority bugs and features and we're very close to
> a release, I wasn't allocated time to work on this much more than sending a
> message to this mailing list to warn of the existence of this bug.
> Not sure when I can get back to this. I'll submit your suggestion to the
> dev team and if someone is allocated time to do it, I'll get back here and
> let you know if it works.
>
> There's also this suggestion that I forgot to mention (I haven't been able
> to test it though):
> https://stackoverflow.com/questions/65765656/release-mnemonic-when-application-loses-focus
>
> Thanks again, kind regards,
>
>
> On Sun, Feb 12, 2023 at 10:06 PM John Hendrikx
> wrote:
>
>> I'm not sure if you are able to test this yourself, but I made a fix for
>> this problem.
>>
>> You could potentially test it by copying the class `javafx.scene.Scene`
>> in your project (without changing the package -- and if modules will allow
>> it, I don't use them personally) and then using this piece of code:
>>
>> private void setWindowFocused(boolean value) {
>> windowFocused = value;
>>
>> Node node = getFocusOwner();
>> if (node != null) {
>> node.setFocusQuietly(windowFocused, focusOwner.focusVisible);
>> node.notifyFocusListeners();
>> }
>>
>> if (windowFocused && accessible != null) {
>> accessible.sendNotification(AccessibleAttribute.FOCUS_NODE);
>> }
>>
>> if (!windowFocused) {
>>
>> getInternalEventDispatcher().getKeyboardShortcutsHandler().setMnemonicsDisplayEnabled(false);
>> }
>> }
>>
>> The last three lines are what I added. A quick test on Windows here shows
>> that the mnemonics get disabled as soon as the window loses focus, and when
>> returning, they're not responding as you'd expect.
>>
>> I'll submit a PR as well.
>>
>> --John
>> On 12/02/2023 15:52, Pedro Duque Vieira wrote:
>>
>> The behavior on Windows is all over the place for different
>>> applications.? I tested a few I've got running:
>>
>>
>> Notepad, Notepad++, Eclipse:
>>
>>
>> - Alt-down: Shows mnemonics on menu bar
>>> - Alt-up: Highlights file menu on alt release
>>> - Alt-tab: Shows mnemonics but doesn't highlight menu when it loses
>>> focus; when returning, mnemonics still highlighted, but doesn't act on
>>> them as menu not selected
>>
>>
>> -> Looks buggy
>>
>>
>> Thunderbird / Opera / Firefox:
>>
>>
>> - Alt-down: nothing
>>> - Alt-up: shows menu bar (it is hidden normally)
>>> - Alt-tab: works as expected, no highlighting
>>
>>
>> -> Looks well behaved
>>
>>
>> Explorer / Excel / Wordpad:
>>
>>
>> - Alt-down: nothing
>>> - Alt-up: shows mnemonics
>>> - Alt-tab: works as expected, no highlighting
>>
>>
>> -> Looks well behaved
>>
>>
>> Visual Studio Code:
>>
>>
>> - Alt-down: Shows mnemonics on menu bar
>>> - Alt-up: Highlights file menu on alt release
>>> - Alt-tab: Shows mnemonics, but hides them once it loses focus; on
>>> return doesn't show mnemonics
>>
>>
>> -> Looks well behaved
>>
>>
>> Chrome / IntelliJ:
>>
>>
>> -> Looks well behaved, doesn't react to alt presses in any way
>>
>>
>> None of the applications tested reacted on a mnemonic key after
>>> regaining focus however, even though they may have them still
>>> highlighted (which I think is a bug).
>>
>>
>> In my opinion, the behavior of notepad/notepad++/eclipse is incorrect
>>> (they need to hide the mnemonics on focus lost, like Visual Studio Code
>>> does, but they don't).
>>
>>
>> There seems to be two correct ways of handling mnemonics in applications
>>> that use them, either:
>>
>>
>> a) shows mnemonics immediately on alt-down, but hide them on focus lost
>
Re: Alt key sticks even after app loses focus (JDK-8090647)
John,
Thank you very much for submitting a work around. Unfortunately, since
there were other higher priority bugs and features and we're very close to
a release, I wasn't allocated time to work on this much more than sending a
message to this mailing list to warn of the existence of this bug.
Not sure when I can get back to this. I'll submit your suggestion to the
dev team and if someone is allocated time to do it, I'll get back here and
let you know if it works.
There's also this suggestion that I forgot to mention (I haven't been able
to test it though):
https://stackoverflow.com/questions/65765656/release-mnemonic-when-application-loses-focus
Thanks again, kind regards,
On Sun, Feb 12, 2023 at 10:06 PM John Hendrikx
wrote:
> I'm not sure if you are able to test this yourself, but I made a fix for
> this problem.
>
> You could potentially test it by copying the class `javafx.scene.Scene` in
> your project (without changing the package -- and if modules will allow it,
> I don't use them personally) and then using this piece of code:
>
> private void setWindowFocused(boolean value) {
> windowFocused = value;
>
> Node node = getFocusOwner();
> if (node != null) {
> node.setFocusQuietly(windowFocused, focusOwner.focusVisible);
> node.notifyFocusListeners();
> }
>
> if (windowFocused && accessible != null) {
> accessible.sendNotification(AccessibleAttribute.FOCUS_NODE);
> }
>
> if (!windowFocused) {
>
> getInternalEventDispatcher().getKeyboardShortcutsHandler().setMnemonicsDisplayEnabled(false);
> }
> }
>
> The last three lines are what I added. A quick test on Windows here shows
> that the mnemonics get disabled as soon as the window loses focus, and when
> returning, they're not responding as you'd expect.
>
> I'll submit a PR as well.
>
> --John
> On 12/02/2023 15:52, Pedro Duque Vieira wrote:
>
> The behavior on Windows is all over the place for different
>> applications.? I tested a few I've got running:
>
>
> Notepad, Notepad++, Eclipse:
>
>
> - Alt-down: Shows mnemonics on menu bar
>> - Alt-up: Highlights file menu on alt release
>> - Alt-tab: Shows mnemonics but doesn't highlight menu when it loses
>> focus; when returning, mnemonics still highlighted, but doesn't act on
>> them as menu not selected
>
>
> -> Looks buggy
>
>
> Thunderbird / Opera / Firefox:
>
>
> - Alt-down: nothing
>> - Alt-up: shows menu bar (it is hidden normally)
>> - Alt-tab: works as expected, no highlighting
>
>
> -> Looks well behaved
>
>
> Explorer / Excel / Wordpad:
>
>
> - Alt-down: nothing
>> - Alt-up: shows mnemonics
>> - Alt-tab: works as expected, no highlighting
>
>
> -> Looks well behaved
>
>
> Visual Studio Code:
>
>
> - Alt-down: Shows mnemonics on menu bar
>> - Alt-up: Highlights file menu on alt release
>> - Alt-tab: Shows mnemonics, but hides them once it loses focus; on
>> return doesn't show mnemonics
>
>
> -> Looks well behaved
>
>
> Chrome / IntelliJ:
>
>
> -> Looks well behaved, doesn't react to alt presses in any way
>
>
> None of the applications tested reacted on a mnemonic key after
>> regaining focus however, even though they may have them still
>> highlighted (which I think is a bug).
>
>
> In my opinion, the behavior of notepad/notepad++/eclipse is incorrect
>> (they need to hide the mnemonics on focus lost, like Visual Studio Code
>> does, but they don't).
>
>
> There seems to be two correct ways of handling mnemonics in applications
>> that use them, either:
>
>
> a) shows mnemonics immediately on alt-down, but hide them on focus lost
>> (if the alt-down becomes an alt-tab, or probably any other alt
>> combination)
>
>
> b) only show mnemonics on a naked alt-up
>
>
> Ticket JDK-8090647 mentions a spec that has been updated, but I can't
>> find it.? It also mentions that the behavior for JavaFX should be what I
>> described in a), so I think this is a bug that can simply be fixed.
>
>
> --John
>
>
>
> Yap, there's quite different behaviors across apps. If you test on windows
> 11 you'll get yet another set of different behaviors.
>
> But all in all, if you: alt+tab (without release) and alt+tab again so
> your app regains focus, you'll have the mnemonic still activated, which, as
> you say, sounds like a bug no matter the difference in behaviors across
> apps.
>
> I agree with your suggestion: "a".
>
> My client was quite disappointed and started to rant about javafx. It
> didn't help that we were hit by a couple other bugs (perhaps bad
> luck). The fact that the bug was filed on 2013 (10 years later) and is
> still happening can be quite problematic.
> Perhaps it would make sense to review all bugs filed, giving highest
> priority to the bugs that were submitted longer ago?
>
> Thanks!
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>
>
--
Pedro Duque Vieira - https://www.pixelduke.com
Re: Alt key sticks even after app loses focus (JDK-8090647)
> > The behavior on Windows is all over the place for different > applications.? I tested a few I've got running: Notepad, Notepad++, Eclipse: - Alt-down: Shows mnemonics on menu bar > - Alt-up: Highlights file menu on alt release > - Alt-tab: Shows mnemonics but doesn't highlight menu when it loses > focus; when returning, mnemonics still highlighted, but doesn't act on > them as menu not selected -> Looks buggy Thunderbird / Opera / Firefox: - Alt-down: nothing > - Alt-up: shows menu bar (it is hidden normally) > - Alt-tab: works as expected, no highlighting -> Looks well behaved Explorer / Excel / Wordpad: - Alt-down: nothing > - Alt-up: shows mnemonics > - Alt-tab: works as expected, no highlighting -> Looks well behaved Visual Studio Code: - Alt-down: Shows mnemonics on menu bar > - Alt-up: Highlights file menu on alt release > - Alt-tab: Shows mnemonics, but hides them once it loses focus; on > return doesn't show mnemonics -> Looks well behaved Chrome / IntelliJ: -> Looks well behaved, doesn't react to alt presses in any way None of the applications tested reacted on a mnemonic key after > regaining focus however, even though they may have them still > highlighted (which I think is a bug). In my opinion, the behavior of notepad/notepad++/eclipse is incorrect > (they need to hide the mnemonics on focus lost, like Visual Studio Code > does, but they don't). There seems to be two correct ways of handling mnemonics in applications > that use them, either: a) shows mnemonics immediately on alt-down, but hide them on focus lost > (if the alt-down becomes an alt-tab, or probably any other alt combination) b) only show mnemonics on a naked alt-up Ticket JDK-8090647 mentions a spec that has been updated, but I can't > find it.? It also mentions that the behavior for JavaFX should be what I > described in a), so I think this is a bug that can simply be fixed. --John Yap, there's quite different behaviors across apps. If you test on windows 11 you'll get yet another set of different behaviors. But all in all, if you: alt+tab (without release) and alt+tab again so your app regains focus, you'll have the mnemonic still activated, which, as you say, sounds like a bug no matter the difference in behaviors across apps. I agree with your suggestion: "a". My client was quite disappointed and started to rant about javafx. It didn't help that we were hit by a couple other bugs (perhaps bad luck). The fact that the bug was filed on 2013 (10 years later) and is still happening can be quite problematic. Perhaps it would make sense to review all bugs filed, giving highest priority to the bugs that were submitted longer ago? Thanks! -- Pedro Duque Vieira - https://www.pixelduke.com
Alt key sticks even after app loses focus (JDK-8090647)
Hi, I'm developing an application for a customer and it seems like we've been hit by: JDK-8090647 <https://bugs.openjdk.org/browse/JDK-8090647> (?) Steps: 1 - press alt + tab to switch to another app 2 - press alt + tab again to switch to javafx app again 3 - type a key with an associated "mnemonic action" in the javafx app (no alt key being pressed) 4 - "mnemonic action" gets triggered even though it shouldn't So the problem is that the alt seems to "stick" after the javafx app loses and regains focus (through alt + tab) . I've tested this under Windows 10 and Windows 11. This is problematic to us since our users often use the keyboard to interact with our app and the previous version of our app (built in a different language than Java) didn't have this problem. -- Pedro Duque Vieira - https://www.pixelduke.com
Re: Style themes API
(I made a mistake and only replied to you, resending this email to the mailing list and you) > I've thought a bit about how we could have such a feature without > introducing Stage appearance to the StyleTheme interface (I think the > two concepts should remain separate). > Here's the updated design document with a proposal: > > https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#changing-the-default-stage-appearance > What do you think? I'm not entirely convinced that the added > complexity is worth the benefit that this feature brings. Thanks for proposing a new API. I really still think "appearance" should be part of the StyleTheme and I find that API, in the proposal, to be somewhat too complex. :-) I think at the base of our disagreement is that we have 2 distinct opinions of what a StyleTheme is. I see it as the concept of a theme and so anything that defines a theme should go in there (my opinion). Correct me if I'm wrong but you view StyleTheme as a collection of Stylesheets and nothing else. But then what's the advantage of it being just a collection of Stylesheets, why should we have that requirement, what do we gain with it? And why not call it StylesheetCollection instead (or something like that)? Or perhaps we could do it without introducing a new interface since it's just a collection of Stylesheet objects. I still think we should have the StyleTheme interface and my main points to having appearance be in StyleTheme is that: 1 - A theme being either dark or light is part of what a theme is. 2 - 99% of use cases are going to want to have all Windows (Dialogs, Windows, etc) to have either a light or dark appearance and I think we should make that easy to do, whereas with this API we make it more difficult since we force the developer to set the appearance on every Window he creates (plus the possibility of setting one of the windows to the wrong appearance). BTW, I'm not saying we can't have an appearance property in the Window (I think we should have it) but I'm also saying we should have appearance be in StyleTheme. I believe that a good API makes the more common use cases easier to do (and code) and so we should make it easy for developers to switch all Windows to either dark or light appearance. I like the term "appearance" precisely because it's rather generic. > Apple also likes to call it like that, so there's some precedent for > it. Ok that makes sense. If there's a precedent of Apple calling it appearance then we can adopt that! > If we have, at some point in the future, both a > `Application.userAgentStyleTheme` and `Application.styleTheme` > property, then users can decide whether they want the style theme to > have user-agent semantics, or author semantics. > Or do you want an option for style themes to decide for each indiviual > stylesheet whether it should have user-agent or author semantics? I would prefer an option in StyleTheme that says whether it's a user agent stylesheet or author stylesheet.. but my main point is, if we don't name it userAgentStylesheet we can, in the future, either do as you say or do as I say. It'll leave room for us to change our mind. I've roughly followed the JEP format with this enhancement proposal. > Added a clarification like you suggested to the Goals section. Sounds good! Thanks again, On Thu, Feb 2, 2023 at 8:42 AM Michael Strauß wrote: > On Thu, Feb 2, 2023 at 12:14 AM Pedro Duque Vieira > wrote: > > The fact that a theme is either dark or light is strongly correlated to > whether you as a developer want all window decorations to be light or dark. > I'd say that very few use cases will want to have some windows to be light > and others to be dark. > > As such, this API as it is, will force developers to set the window > decorations to either light or dark every time they spawn a new Window > (spawning a separate Window, a Dialog, etc). I'd say it would be a good > idea to set the window decorations based on what is defined in the > StyleTheme with the possibility to override them if you set it on the > Window itself. > > I've thought a bit about how we could have such a feature without > introducing Stage appearance to the StyleTheme interface (I think the > two concepts should remain separate). > Here's the updated design document with a proposal: > > https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#changing-the-default-stage-appearance > What do you think? I'm not entirely convinced that the added > complexity is worth the benefit that this feature brings. > > > > > Looking at the doc you created. Some comments: > > - I like the Preferences API > > - "Appearance" or "ThemeAppearance"? "Appearance" sounds like a rather > generic term that could mean anything.. > > - perhaps rename the
Re: Style themes API
t for them to be different, which can be problematic for users of those themes: styles set in code will be overridden, styles set in FXML, styles set in author stylesheets created by the developers if the specificity of those styles is lower than the themes styles.. On Wed, Feb 1, 2023 at 12:22 AM Michael Strauß wrote: > On Tue, Jan 31, 2023 at 6:14 PM Pedro Duque Vieira > wrote: > > 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. > > 1) Ease of migration should be an important consideration, but there > are also other considerations. I'd argue that getting the feature > stacking and mental model right is more important, and giving themes a > way to individually select if the stylesheets are user-agent or user > stylesheets makes it hard to understand why my locally-set property > value is being ignored by JavaFX in one theme, but not in the other. > > 2) The scenario you describe occurs when an application sets the value > of styleable properties from code, but the values are overridden by an > author stylesheet. Yes, that might happen, and I think it's up to the > application developers to fix that. The reason why I think we should > only support `Application.userAgentStyleTheme` in the first version of > this new feature is quite simple: I'd rather have the feature actually > make it into JavaFX than be stuck in review because it's too large and > too complex of a change. User-agent style themes are pretty easy to > implement (most of the code is already in place), while author style > themes are not. We can add author style themes as a follow-up > enhancement. > > > > > 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 &
Re: Style themes API
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.duquevie...@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. Perhap
Re: Style themes API
t;);
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 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ß
wrote:
> Hi Pedro,
>
> see my comments below.
>
>
> On Sat, Jan 21, 2023 at 5:19 PM Pedro Duque Vieira
> 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
Re: Style themes API
Hi again Michael,
2-
> Currently, the order of precedence is as follows (from highest to lowest):
> 1. Node.style
> 2. Parent.stylesheets
> 3. Scene.stylesheets
> 4. StyleableProperty values set from code
> 5. Application.styleTheme
> 6. Application.userAgentStylesheet
I understand you're suggesting that a style theme could effectively be
> inserted between 3 and 4, such that it overrides local values set from
> code, but not values set in Scene stylesheets.
> I'm not sure that the added complexity is worth the marginal benefits.
> As far as JavaFX has always had the concept of built-in "themes",
> users could reliably override any StyleableProperty value from code.
> Developers might be surprised to find out that they can't set the
> value of a StyleableProperty from code because an application-wide
> style theme overrides any local changes.
> The migration story from Scene stylesheets to a StyleTheme might be a
> little bit easier, but it complicates the mental model of how themes
> interact with the CSS cascade.
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.
3 -
> I agree that it would be nice to have a way to programmatically
> control the appearance of system-provided window decorations.
> It's not entirely related to style themes: a style theme is an
> application-wide concept, while window decorations are specific to
> each individual window.
> Maybe we could do this similarly to the Stage.initStyle method, which
> serves a similar purpose of setting up window decorations.
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.
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 {
> ReadOnlyBooleanProperty darkModeProperty();
> ReadOnlyObjectProperty accentColorProperty();
> ...
> }
Yes, I think that would be great.
Thanks again!
On Mon, Jan 16, 2023 at 11:28 PM Michael Strauß
wrote:
> Hi Pedro,
> see my comments below.
>
>
> On Mon, Jan 16, 2023 at 1:10 PM Pedro Duque Vieira
> wrote:
> >
> > No problem, I mentioned those in my first comment but probably got lost
> in this conversation.
> > 2 – I think the ability to specify in the StyleTheme whether it is a
> user agent stylesheet, or an author stylesheet could be of interest. Most
> of the themes I know are composed of author stylesheets (they use the
> getStylesheets() API in Scene) so migration to using the StyleTheme API
> would be easier if one could specify this. Conversely specifying that the
> StyleTheme is a user agent stylesheet will also be very useful in the cases
> where we’re creating a theme but don’t want it to override styles specified
> through code, etc.
> >
> > I'll now also add that you might want to create a theme, from the get
> go, that doesn't get trumped by any rule set through code, either code
> itself on in FXML files (which will be code anyway). So that the theme css
> is what always drives the presentation of
Re: RFC: new property in ToggleGroup
My 2 cents, I agree with Kevin, I don't see this as a common feature in User Interfaces. UX wise, like Kevin says, you usually start off with no radio button selected and then after one is selected the user can't usually deselect the radio buttons, he can only select another option in the group. How common a UI feature is being able to deselect the selected item in a > ToggleGroup via the UI such that no item is selected? I don't normally > see that in various apps or toolkits that I am familiar with. What I do > see is that either a default item is selected or no item is selected > initially (which is the one and only time that there will be no item > selected), but in both case, once you make a selection, there is no way > via the UI to deselect the current item. Absent a compelling need, I > think the current behavior (once the fix for JDK-8237505 is integrated) > is sufficient. What do other developers think?
Re: Style themes API
Hi again Michael, Thanks for taking the time to answer my comments. As always, it's easier to comment on and criticize than to do the actual work of implementing the feature. So thanks again for the patience. My comments below: I don't quite understand this. Can you elaborate on what the > advantages would be, and how (and for what purpose) users of the API > would use such a flag? No problem, I mentioned those in my first comment but probably got lost in this conversation. 2 – I think the ability to specify in the StyleTheme whether it is a user agent stylesheet, or an author stylesheet could be of interest. Most of the themes I know are composed of author stylesheets (they use the getStylesheets() API in Scene) so migration to using the StyleTheme API would be easier if one could specify this. Conversely specifying that the StyleTheme is a user agent stylesheet will also be very useful in the cases where we’re creating a theme but don’t want it to override styles specified through code, etc. I'll now also add that you might want to create a theme, from the get go, that doesn't get trumped by any rule set through code, either code itself on in FXML files (which will be code anyway). So that the theme css is what always drives the presentation of your app (it has priority). This is already possible by choosing to add your stylesheets to the Scene getStylesheets() method or by using the setUserAgentStylesheet() method. I don't think that we need any new API for dark mode window frames. > On macOS, the color of the window frame is already adjusted to match > the system-wide dark/light mode. > On Windows, this is not the case: https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/apply-windows-themes "Not all Win32 applications support Dark mode, so > Windows gives Win32 apps a light title bar by > default. If you are prepared to support Dark mode, > you can ask Windows to draw the dark title bar > instead when Dark mode is enabled." Since JavaFX already uses dark frames on macOS, why not do the same on > Windows? > We can simply enable this behavior in general, and provide a system > property to revert to the old behavior of always using light frames, > even if dark mode is enabled. Ok thanks for clarifying what happens on Mac. Yes on the Windows OS, JavaFX won't honor your system wide settings. If your system is in dark mode the frames will still be shown in light mode. But anyways, I think, the programmer should be able to toggle the dark/light mode setting irrespective of what is defined in the system. There are many apps where you, as a user, can choose dark or light mode in the app itself and it will honor it regardless of what you have defined in the system (e.g. Intellij, Slack, etc, etc). Some will allow you to set whether you want to use the system setting for light/dark mode or your own setting in the app. This can be of value in cases where you, as a user, prefer to use an app in dark mode and others in some other mode, so you can choose themes on an app by app basis. Or perhaps the developer wants to design an app that's just dark. In that case you'd want the ability to toggle the frame decorations to being dark (all the time). Here's a simple implementation that exposes dark mode and accent > coloring as JavaFX properties on a theme base class: > https://gist.github.com/mstr2/ba2f9cba659953788008fed1e9b2a031 We might consider adding something like this to JavaFX in the future, > but for the time being, I'd rather let third-party libraries explore > higher-level APIs first. Just to be clear I was just talking about how we would present this API (platform preferences). This property would be a way to more easily know if the system is in dark/light mode, the accent color, without needing to know the specific "key". Thanks again! On Mon, Jan 16, 2023 at 4:01 AM Michael Strauß wrote: > My comments below: > > On Sun, Jan 15, 2023 at 1:25 PM Pedro Duque Vieira > wrote: > > > > I think we could add that it has higher precedence than a user agent > stylesheets but that's it's not an author stylesheet. We can also possibly > briefly say what a user agent stylesheet and author stylesheet are or > perhaps better yet, point to the css reference doc section that states it? > > Sure, I'll add some additional documentation. > > > > > Yes, I think minimizing changes to the CSS subsystem is a good idea. > > I didn't mean we should make changes to the CSS subsystem, I > meant/proposed to add a flag or property in StyleThemes (the new API) that > programmers would then set in their StyleThemes and would define whether > the StyleTheme he's creating is a user agent stylesheet or an author > stylesheet. > > I don't quite understand this. Can you elaborate on what the > advantages would be, and how (and
Re: Style themes API
Hi Michael, Thanks again for taking the time to answer my questions/comments and for your efforts in coming forward with this new API proposal. And also thanks for your patience as I can be a bit annoying at times. :) There's of course a bunch of things I liked about your API proposal but for the sake of time I specifically only commented on what I thought could change and not on what I liked (I don't have much free spare time at the moment, unfortunately). There's of course your idea itself of adding a Theme API which I agree with. Answering your comments below: Theme stylesheets have a higher precedence than the application's > user-agent stylesheet, but a lower precedence than author stylesheets. > This is stated in the JavaFX CSS reference (cssref.html): * The JavaFX CSS implementation applies the following > * order of precedence: a style from a user agent style sheet or a > style theme has lower > * priority than a value set from code, which has lower priority than a > Scene > * or Parent style sheet. We could include similar language in the javadoc. I think we could add that it has higher precedence than a user agent stylesheets but that's it's not an author stylesheet. We can also possibly briefly say what a user agent stylesheet and author stylesheet are or perhaps better yet, point to the css reference doc section that states it? I deliberately wanted to minimize changes to the CSS subsystem in > order to prevent introducing regressions in that area of the codebase. > As a result, the proposed implementation treats theme stylesheets as a > list of user-agent stylesheets, and optionally adds the application's > user-agent stylesheet as the first item in that list. Note that > `javafx.css.StyleOrigin` is also unchanged; you won't know whether a > `StyleOrigin.USER_AGENT` stylesheet is the application's user-agent > stylesheet, or one of its theme stylesheets. Yes, I think minimizing changes to the CSS subsystem is a good idea. I didn't mean we should make changes to the CSS subsystem, I meant/proposed to add a flag or property in StyleThemes (the new API) that programmers would then set in their StyleThemes and would define whether the StyleTheme he's creating is a user agent stylesheet or an author stylesheet. There's a role for third-party libraries here, and I think APIs for > dark/light mode and other things can be done there. > Supporting dark/light window frames is quite independent from the > proposed style theme API, and should be done in a separate PR. > I understand that it might be nice to have a comprehensive dark/light > mode API in JavaFX, but there's a value in not going there and leaving > that to libraries instead. I'd rather keep this feature as simple as > it gets without sacrificing its unique capabilities. We can always > come back and add more API surface if it turns out that we're really > missing something. I disagree here. I think this would be too low level for third party apps to add support for, and as of today there isn't still yet any third party library that adds it (which can itself be an indication that it's not a good fit for third party libraries). You'd need third party libraries to call on native code to change the frame decoration of Windows that JavaFX spawns itself. This API will already add some nice support to query platform preferences (dark mode, accent color, etc) so I think it makes perfect sense to also add API here to set the programmers preferences about these properties, that JavaFX should then abide by. Yes we could come back later to add that API. As a theme developer and focusing on theme development only, this has been on top of my wish list for a while. :) Given that light/dark theme, etc feature is pervasive across all Oses I think it's a shame that JavaFX doesn't yet fully support the development of light/dark themes (especially dark themes). 4 - After reading Andy's comments I thought about a 4th point. I agree with him in the part that we could have some of the platform preference properties as Java properties. At least the things that are pervasive across platforms, like whether the platform is set to dark or light mode and the accent color. I mean this in addition to the API that queries for platform properties (i.e. I don't mean to remove the API you proposed to query for platform properties). Thanks again! -- Pedro Duque Vieira - https://www.pixelduke.com
Re: RFR: 8267546: Add CSS themes as a first-class concept [v18]
On Mon, 9 Jan 2023 18:33:40 GMT, Michael Strauß wrote:
>> This PR adds style themes as a first-class concept to OpenJFX. A style theme
>> is a collection of stylesheets and the logic that governs them. Style themes
>> can respond to OS notifications and update their stylesheets dynamically.
>> This PR also re-implements Caspian and Modena as style themes.
>>
>> ### New APIs in `javafx.graphics`
>> The new theming-related APIs in `javafx.graphics` provide a basic framework
>> to support application-wide style themes. Higher-level theming concepts (for
>> example, "dark mode" detection or accent coloring) are not a part of this
>> basic framework, because any API invented here might soon be out of date.
>> Implementations can build on top of this framework to add useful
>> higher-level features.
>> 1. StyleTheme
>> A style theme is an implementation of the `javafx.css.StyleTheme` interface:
>>
>> /**
>> * {@code StyleTheme} is a collection of stylesheets that specify the
>> appearance of UI controls and other
>> * nodes in the application. Like a user-agent stylesheet, a {@code
>> StyleTheme} is implicitly used by all
>> * JavaFX nodes in the scene graph.
>> *
>> * The list of stylesheets that comprise a {@code StyleTheme} can be
>> modified while the application is running,
>> * enabling applications to create dynamic themes that respond to changing
>> user preferences.
>> *
>> * In the CSS subsystem, stylesheets that comprise a {@code StyleTheme} are
>> classified as
>> * {@link StyleOrigin#USER_AGENT} stylesheets, but have a higher precedence
>> in the CSS cascade
>> * than a stylesheet referenced by {@link
>> Application#userAgentStylesheetProperty()}.
>> */
>> public interface StyleTheme {
>> /**
>> * Gets the list of stylesheet URLs that comprise this {@code
>> StyleTheme}.
>> *
>> * If the list of stylesheets that comprise this {@code StyleTheme} is
>> changed at runtime, this
>> * method must return an {@link ObservableList} to allow the CSS
>> subsystem to subscribe to list
>> * change notifications.
>> *
>> * @implSpec Implementations of this method that return an {@link
>> ObservableList} must emit all
>> * change notifications on the JavaFX application thread.
>> *
>> * @implNote Implementations of this method that return an {@link
>> ObservableList} are encouraged
>> * to minimize the number of subsequent list change
>> notifications that are fired by the
>> * list, as each change notification causes the CSS subsystem
>> to re-apply the referenced
>> * stylesheets.
>> */
>> List getStylesheets();
>> }
>>
>>
>> A new `styleTheme` property is added to `javafx.application.Application`,
>> and `userAgentStylesheet` is promoted to a JavaFX property (currently, this
>> is just a getter/setter pair):
>>
>> public class Application {
>> ...
>> /**
>> * Specifies the user-agent stylesheet of the application.
>> *
>> * A user-agent stylesheet is a global stylesheet that can be specified
>> in addition to a
>> * {@link StyleTheme} and that is implicitly used by all JavaFX nodes in
>> the scene graph.
>> * It can be used to provide default styling for UI controls and other
>> nodes.
>> * A user-agent stylesheets has the lowest precedence in the CSS cascade.
>> *
>> * Before JavaFX 21, built-in themes were selectable using the special
>> user-agent stylesheet constants
>> * {@link #STYLESHEET_CASPIAN} and {@link #STYLESHEET_MODENA}. For
>> backwards compatibility, the meaning
>> * of these special constants is retained: setting the user-agent
>> stylesheet to either {@code STYLESHEET_CASPIAN}
>> * or {@code STYLESHEET_MODENA} will also set the value of the {@link
>> #styleThemeProperty() styleTheme}
>> * property to a new instance of the corresponding theme class.
>> *
>> * Note: this property can be modified on any thread, but it is not
>> thread-safe and must
>> * not be concurrently modified with {@link #styleThemeProperty()
>> styleTheme}.
>> */
>> public static StringProperty userAgentStylesheetProperty();
>> public static String getUserAgentStylesheet();
>> public static void setUserAgentStylesheet(String url);
>>
>> /**
>> * Specifies the {@link StyleTheme} of the application.
>> *
>> * {@code StyleTheme} is a collection of stylesheets that define the
>> appearance of the application.
>> * Like a user-agent stylesheet, a {@code StyleTheme} is implicitly used
>> by all JavaFX nodes in the
>> * scene graph.
>> *
>> * Stylesheets that comprise a {@code StyleTheme} have a higher
>> precedence in the CSS cascade than a
>> * stylesheet referenced by the {@link #userAgentStylesheetProperty()
>> userAgentStylesheet} property.
>> *
>> * Note: this property can be
