The next steps would be to send an email (you can reply to this thread),
with a clear description of your proposal.
The focus should be on what problem you are solving and on the proposed
public API and behavioral changes. I suggest not (yet) referring to code
changes in your PR except for illustrative purposes. Start with what the
current behavior is, what problem that is causing, and what your
proposed solution is. By way of a counter-example, the "computeIfAbsent"
code fragment you included in your email and PR description is an
implementation detail; the concept that should be discussed is the
presumed stability of a Region's userAgentStyleSheet. This presumed
stability is documented in the spec, so start there, not with the code.
If there is general agreement that this feature is a good thing to add
to JavaFX as public API, meaning it is something that would benefit
multiple app developers, the next step would be to review the proposed
API and behavioral changes. This can be done in the context of reviewing
the PR. The focus during this phase of review would be mainly on the
specification changes that would need to go into the API docs and be
included in the CSR.
The above is good general guidance for getting any new non-trivial
feature added to the JavaFX API.
As for the specifics of what you are proposing, the main things I would
like to see addressed during the initial discussion are:
* When and why do custom controls typically want to provide a dynamic
userAgentStylesheet?
* How should a control indicate that its userAgentStyleSheet is dynamic?
By a separate property (read-only?) that it provides as an override?
Should it be dynamic by default (I am skeptical, myself)?
* Does an application that uses a custom control need to know whether or
not that control uses a dynamic userAgentStylesheet? Can it affect the
answer (e.g., you mentioned theming, can you be more specific)?
-- Kevin
On 7/7/2021 10:43 AM, Alessandro Parisi wrote:
Sorry for the late reply, but I've been quite busy lately.
So, the code change that I suggested here #525
<https://github.com/openjdk/jfx/pull/525> is not only an improvement but
also a bug fix.
The improvement is that we can see this change as a little theming system
because if a control can provide an userAgentStylesheet depending on
certain conditions we can call this a theme system. This would be a good
improvement for devs like me who develop custom controls because as of now
the only way to provide such mechanism is to change the stylesheet list.
Let's say we have an enumerator for the style of a control and each enum
has the string url to the CSS file, the only way is to load the CSS and do
'control.getStylesheets().setAll(file)'
This, however, can cause nasty bugs and unexpected behaviors.
That's why I have overridden the 'invalidated()' method of the property, so
that when it changes, the control's style is re-computed correctly.
Regarding the 'StyleManager' the changes ensure that what's stored in
the 'weakRegionUserAgentStylesheetMap'
is the correct CSS file. In fact, using just the 'computeIfAbsent()' method
here Line 1667
<https://github.com/openjdk/jfx/pull/525/commits/3cffaccd7eaf11238e786e31f8c1b6fb16121471#diff-ca9344a33e4b346c9ac138a5e5d867acc3b0e53c761e8d207fd92026320792edR1667>
is not enough if the user agent changes.
The good thing about the user agent API change is that it is backward
compatible, libraries based on old JavaFX versions would still work because
as of now they override the 'getUserAgentStylesheet()' getter, and that
getter is still present but by default now returns the userAgenStylesheet
property value.
Let me know what do you think, I would really like to see this change
happen, implementing custom themes would be very easy
