<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Courier New";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">my two drachmas (in addition to the comments in the PR and elsewhere):<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">#3 I think this API should be unidirectional, i.e. limited to reporting the platform preferences and their runtime changes to the application (the key set is immutable, and values
cannot be put by the application). Whenever the applications requires changing of some values by the user/app, the app can create a separate property.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">#4 I am ok with Appearance enum as long as it's one of the attributes and is present on every supported platform.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">#5 in my case (programmatic generation of a stylesheet on top of standard modena.css), it can be used to generate derived colors as well as proper effects and highlights.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">In addition to the questions Kevin asked, I'd like to as<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">6) Is high contrast mode encoded as another attribute, or does it need two more values in Appearance (high contrast light, high contrast dark)?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">7) Is there a way to provide a type-safe interface for retrieving the values from the preferences map? Alternatively, there should be a table for each platform enumerating keys,
value types, nullability, and, ideally, a description.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">Thank you,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">openjfx-dev <openjfx-dev-retn@openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth@oracle.com><br>
<b>Date: </b>Wednesday, June 14, 2023 at 11:48<br>
<b>To: </b>openjfx-dev <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Platform preferences API<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">I'm finally catching up on the platform preferences API discussion, most
<br>
of which is in Draft PR #1014 [1]. The information captured here [2] <br>
provides a good summary of the API.<br>
<br>
A PR isn't really the best place to discuss the question of whether this <br>
feature is useful and whether the API is heading in the direction we <br>
want, so I wanted to have a high level discussion of that here.<br>
<br>
First of all, I do see the value in having some way to provide the <br>
platform-specific properties like colors, etc, to the user. I'm less <br>
sure that the same class should also allow overriding those properties, <br>
but I can see the value of providing *some* way for the application to <br>
override them.<br>
<br>
In order to move this forward, we need to answer the following questions:<br>
<br>
1. Is this functionality something we want in the core of JavaFX? I <br>
think the answer is "yes", and it seems like others agree.<br>
<br>
2. What is the best way to expose this capability? Currently it is <br>
proposed as an interface that extends ObservableMap (meaning that it <br>
*is* a Map rather than *contains* a map or has some other map-like <br>
representation). This seems fine to me, based on the discussion in the PR.<br>
<br>
3. Should the platform preferences API provide the ability to set the <br>
properties (to override them) or should that capability be provided some <br>
other way (e.g., by some other class)? Perhaps this belongs as part of <br>
an eventual theming API, possibly via a "user preferences" class that <br>
extends or wraps the platform preferences class? At least the currently <br>
proposed API moved away from the odd "override" semantics and uses the <br>
standard "put" semantics. That, coupled with the two "reset" methods is <br>
a reasonable API, but I'm still not convinced that the core platform <br>
preferences class is the place for it. Please consider whether having a <br>
separate user / theme preferences interface / class, in addition to the <br>
(read-only) system preferences, might be better.<br>
<br>
4. Is an Appearance enum the best way to provide the indication of LIGHT <br>
vs DARK? Do we need it as part of the Preferences API or should it wait <br>
until one of the later RFEs?<br>
<br>
5. How do you anticipate this be used by an application prior to having <br>
CSS themes?<br>
<br>
-- Kevin<br>
<br>
[1] <a href="https://github.com/openjdk/jfx/pull/1014">https://github.com/openjdk/jfx/pull/1014</a><br>
<br>
[2] <br>
<a href="https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences">https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548#platform-preferences</a><o:p></o:p></span></p>
</div>
</div>
</body>
</html>