<div dir="ltr"><div class="gmail_quote"><div>Hi,</div><div><br></div><div>Interesting remarks. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>Hello,</p>
<p>>> A 3rd party control, RichTextFX already exists -- what
is this new proposal adding that RichTextFX does not have?<br>
<br>
It uses the standard JavaFX VirtualFlow API and and does not need
to work with reactive streams. RichtextFX depends on several long
unmaintained libs: ReactFX (last commit 8 years ago),
WellBehavedFX (last commit 6 years ago), UndoFX (last commit 3
years ago). To say it's actively maintained is a big exaggeration.<br></p></div></blockquote><div><br></div><div>What do you think about our Rich Text Area project? <a href="https://github.com/gluonhq/rich-text-area">https://github.com/gluonhq/rich-text-area</a></div><div>I hear your concerns about depending on unmaintained libs, and it is one of my own primary filter criteria to either use or not use software</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
>> What (if anything) is stopping a 3rd party from building
a RichTextArea themselves?<br>
<br>
- The lack of a standard API. The Behavior API has been discussed
for ages, but is still not implemented. Moreover, WellBehavedFX is
literally a rejected JEP/CSR implementation.<br></p></div></blockquote><div>I agree a standard behavior API would be helpful, but I don't think it is needed for a third party control. I rather hope to see more third party controls being developed using different approaches, so that the community in general gets more experience with the different approaches, as that would give useful feedback on an approach to standardize it in OpenJFX. You know how it goes with projects in OpenJDK: once something is in, it has to be maintained and supported for a very long time and it is really hard to change it.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
- The closedness of JavaFX in general. All internals are
explicitly private and final. A few simple examples. The date
picker popup uses a private API to calculate its width based on
text size, but you're forbidden to do the same thing. All i18n
resources are not exported, you're forbidden to use them to create
a context menu. You're not encouraging 3rd party libs, you're
going in the opposite direction (for the sake of stability of
course).<br></p></div></blockquote><div>Valid point. And it should be addressed. I wasn't part of the discussions where the decision was to close as much as possible, but I believe the idea was to close almost everything, and then to open API's when needed, after it was clear that opening the API would benefit the ecosystem without giving up stability. This happened a number of times in the past years, but I agree there is still much room for improvements. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
- The JavaFX community is very small. The "tens of thousands of
developers" you talk about don't exist. Even famous projects are
poorly maintained or not maintained at all, including ControlsFX
and ScenicView. You have fewer features -> you have fewer
users/market share -> you have less promotion -> you have
fewer committers -> you have fewer features. It's that simple.<br></p></div></blockquote><div>I think this is partly true, but it's more nuanced I believe. I am aware of a number of real large JavaFX projects, with many developers working on them. Most of these large projects are developed after closed walls, with lots of duplicated code that could go in a library. For the ecosystem as a whole, that's not good. It would be much better if we were in a situation where individual developers or companies would create and maintain libraries that would then be used in those big projects. For non-technical reasons, this is unfortunately not the case.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
- There's literally no docs about creating new controls. Even Skin
API is badly documented. You can only learn from existing control
libs.<br></p></div></blockquote><div>This is a very valid concern. And I believe it is more important for us (openjfx-dev) to fix this, rather than do everything ourselves in the OpenJFX core. We need to encourage developers to create new controls, and provide more documentation, tutorials etc,... In the early days of JavaFX, there was a big team (it would now be called devrel I guess) that was working on this, helping developers and the ecosystem, but we know what happened next. That gap is not yet filled, and this is the price we are still paying for it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
This particular feature would be a HUGE step forward. I'm really
glad to see it. Hopefully it won't get buried under a bunch of
pointless abstract discussions like the CSS theme CSR. Just get
some feedback and implement it the way you want. It's a million
times better than doing nothing.</p></div></blockquote><div>Well, it's not that we're doing nothing. We are doing a number of things:</div><div><br></div><div>1. inside openjfx: keep it working. This should not be underestimated. With the fast and not always logical changes in platforms/OS code, there is lots of code under the hood that needs to be maintained and improved. A number of people on this list are extremely active on this, and spending lots of time on it. Unfortunately, this doesn't make headlines as the result of the hard work is often that "existing things keep working". Apart from keeping it working, I feel we are moving forward and making gradual progress. Over the past year, I saw more people contributing to OpenJFX and to this list, resulting in improvements in specific directions, and I am optimistic about that evolution.</div><div><br></div><div>2. outside openjfx: as I said, with Gluon we created this RTA (<a href="https://github.com/gluonhq/rich-text-area">https://github.com/gluonhq/rich-text-area</a>). Because people wanted it, and because it would be good to experiment with it, without jeopardizing the OpenJFX stability.</div><div><br></div><div>As for the pointless abstract discussions: we are somehow linked to the OpenJDK umbrella, where quality is valued much higher than adding hip features, and we try to stick to that principle as well (granted, I wouldn't call things like "tray support" a hip feature, so we are definitely not yet where we need to be).</div><div>As a consequence, we do have lots of discussions before something gets in. For projects that deliver the foundations to an ecosystem, it is often better to not do something than to do it wrong. I know this is often unpopular, but being on the first row to fix things that were wrong from the beginning, I learned the hard way that this statement makes sense.</div><div>That is not to say that we should not do anything. On the contrary, I'd love it if we could do more. But in the right place. Stability and basic features inside OpenJFX, experiments and libraries in the ecosystem.</div><div><br></div><div>- Johan</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div>On 23/02/2024 14.45, Johan Vos wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">I fully agree with John on this.
<div><br>
<div>A RichTextArea is something that can "easily" be
developed outside OpenJFX .</div>
<div>There are a number of examples already, e.g.
RichTextFX, and our (Gluon) RichTextArea at </div>
<div><a href="https://github.com/gluonhq/rich-text-area" target="_blank">https://github.com/gluonhq/rich-text-area</a><br>
</div>
<div><br>
</div>
<div>In the past, we clearly said that this was not a focus
for OpenJFX.</div>
<div><br>
</div>
<div>
<div>There are a huge amount of outstanding issues in JBS
that can only be fixed in the OpenJFX "core". Developers
(of custom components/controls) rely on the core OpenJFX
development to address those issues. That is what this
group (the openjfx-dev list) is supposed to do.</div>
</div>
</div>
<div><br>
</div>
<div>I highly encourage developers to create custom components
and controls, but not as part of OpenJFX. As others noted as
well, we have many other things to fix that can only be
fixed in OpenJFX, and that is where the priorities of
OpenJFX should be, imho.</div>
<div><br>
</div>
<div>- Johan</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Feb 23, 2024 at
2:48 AM John Hendrikx <<a href="mailto:john.hendrikx@gmail.com" target="_blank">john.hendrikx@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">
<div>
<p>Hi,<br>
</p>
<p>Far be it from me to tell the FX team what it should
do, I am still wondering the following:</p>
<p>- A 3rd party control, RichTextFX already exists --
what is this new proposal adding that RichTextFX does
not have?<br>
- What (if anything) is stopping a 3rd party from
building a RichTextArea themselves?<br>
</p>
<p>In other words, I think the FX team ought to focus on
**facilitating** the building of complex controls like
RichTextArea, by identifying gaps in the current Control
API that is **stopping** 3rd parties from doing this
themselves in the same integrated manner as a "native"
FX control.</p>
<p>Enabling thousands or tens of thousand of developers to
build more complicated controls seems to me like a much
better investment than what I think will be a
significant investment in one of the most complex
controls imaginable. RichTextFX was actively developed
over a 4 year period, with 45 contributors and over 1400
commits (for comparison, JavaFX had 250 commits in the
past year). If it will be significantly less
complicated, then what does it offer over RichTextFX?</p>
<p>--John<br>
</p>
<div>On 21/02/2024 19:07, Andy Goryachev wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span>Dear JavaFX developers:</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>We would like to propose a
new feature - rich text control, RichTextArea,
intended to bridge the functional gap with Swing
and its StyledEditorKit/JEditorPane. The main
design goal is to provide a control that is
complete enough to be useful out-of-the box, as
well as open to extension by the application
developers.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>This is a complex feature
with a large API surface that would be nearly
impossible to get right the first time, even after
an extensive review. We are, therefore,
introducing this in an incubating module, <b>javafx.incubator.richtext</b>.
This will allow us to evolve the API in future
releases without the strict compatibility
constraints that other JavaFX modules have.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Please take a look at the
proposal [0], a list of discussion points [1], and
the API Specification (javadoc) [2]. While the
proposed API is ready for review, it isn't
complete nor set in stone. We are looking for
feedback, and will update the proposal based on
the suggestions we receive from the community. We
encourage you to comment either in the mailing
list, or by leaving comments inline in a draft
pull request [3]. For context, the links to the
original RFE [4] and a list of missing APIs
related to rich text [5] are provided below.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>Sincerely,</span></p>
<p class="MsoNormal"><span>Your friendly JavaFX
development team.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>References</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>[0] Proposal: <a href="https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md" target="_blank">
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md</a></span></p>
<p class="MsoNormal"><span>[1] Discussion points: <a href="https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md" target="_blank">
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md</a></span></p>
<p class="MsoNormal"><span>[2] API specification
(javadoc): <a href="https://cr.openjdk.org/~angorya/RichTextArea/javadoc" target="_blank">https://cr.openjdk.org/~angorya/RichTextArea/javadoc</a></span></p>
<p class="MsoNormal"><span>[3] Draft Pull Request for
API comments and feedback: <a href="https://github.com/openjdk/jfx/pull/1374" target="_blank">https://github.com/openjdk/jfx/pull/1374</a></span></p>
<p class="MsoNormal"><span lang="DE">[4] RichTextArea
RFE: <a href="https://bugs.openjdk.org/browse/JDK-8301121" target="_blank">https://bugs.openjdk.org/browse/JDK-8301121</a></span></p>
<p class="MsoNormal"><span>[5] Missing APIs related to
rich text control: <a href="https://bugs.openjdk.org/browse/JDK-8300569" target="_blank">https://bugs.openjdk.org/browse/JDK-8300569</a></span></p>
<p class="MsoNormal"><span> </span></p>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote></div></div>