(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ß <michaelstr...@gmail.com> wrote: > On Thu, Feb 2, 2023 at 12:14 AM Pedro Duque Vieira > <pedro.duquevie...@gmail.com> 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 Stage appearance property to something like: > "frameDecorations", e.g. "setFrameDecorations(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. > > > > > - " A future enhancement may refactor the built-in themes to make color > definitions swappable". This is already possible. Modena has its color > definitions given by css variables which can be easily overridden in CSS. > That's also a strong part of how I currently switch JMetro to either dark > or light version without having to duplicate every style definition. Side > note: JMetro is composed of several stylesheets (more than 1) so it would > be a nightmare or impossible to make JMetro be a user agent stylesheet with > the current state of the JavaFX API (+1 for this new API :-) ). > > - Perhaps rename "Application.userAgentStylesheetXX" to > "Application.styleThemeXX" and keep the semantics? If we make it be > "userAgentStylesheetXX" it means we can no longer in a future version make > StyleTheme have a property to define whether they are to be user agent > stylesheets or author stylesheets. It gives less room for us to be able to > change our minds in the future. > > 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? > > > > > - Perhaps instead of the section "Goals" being named "Goals" we could > name it "Advantages of this API" or something along those lines and have it > be the first topic. I think the first question people will ask is: "what's > the advantage of this new feature?".. so I think it would be nice if it's > the first topic so that we grab people's attention from the start. > > - instead of "Promote CSS user-agent themes from an implementation > detail to a first-class concept.", perhaps something more clear? Something > like: "Allow easier creation of themes that are composed of user agent > stylesheets (like Modena and Caspian). These themes may be composed of more > than 1 user agent stylesheet which isn't possible with the current javafx > API". Also perhaps make reference to the fact that 90% (rough estimate) of > themes out there are composed of author style sheets and it's difficult 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.. > > I've roughly followed the JEP format with this enhancement proposal. > Added a clarification like you suggested to the Goals section. > -- Pedro Duque Vieira - https://www.pixelduke.com
