writing a rich text editor

[David Simkulette]

Hi everyone,

OK, so, I waited for a rich text editor ala Swing's JEditorPane to surface in Java 8 and now Java 9. The talk had been it would be in 8. Now I am starting to realize that what Oracle wants is for us to use HTMLEditor as the base for all rich editor controls.
I have clients who aren't going go for that because fundamentally HTMLEditor loads a WebPage into WebView effectively turning any editor I write using HTMLEditor into a possibly, and easily, internet-connected document. That's a security risk they're not going to swallow.

What I am wondering is- is this it? Is this where devs are being dropped off in terms of future text editor development?

I know about all the various rich text editor attempts out there and they are one of two things- an extension of HTMLEditor or an attempt to extend Text to make it support rich formatting.

The thing is, with Java 9, Oracle has effectively cut us off from access to the libraries we need to write a text editor from, more or less, scratch. I am talking about the libraries which were in Swing like LineBreakMeasurer and access to the native libraries for (mouse event) hit testing (upon characters) and many many others.

Previously, in Swing there was something approaching a 1:1 correspondence between Java classes and the native libraries needed. Now it's more like a curated view to those native libraries indirectly through HTMLEditor, Text and TextFlow (a read only view of text).

The way I am looking at it this morning is: if I want to write a rich text editor, I can turn my back on my years of Java programming, go native, make friends again with C++, and develop the needed UIs with each platform's respective UI toolkits.

That's a bad morning.

[Campbell Ritchie]

Don't know much about it myself, but I have had that sort of problem myself.

And welcome to the Ranch

[Paul Clapham]

Welcome to the Ranch, David!

I'm not surprised that Oracle hasn't produced a rich text editor yet. It's been clear for a while that GUI apps haven't been their priority. And then I heard that JNLP was being deprecated in Java 9. So I think you're right -- don't wait for Oracle to do anything for you in the GUI sphere.

I'm sorry not to brighten your morning.  

[David Simkulette]

Paul Clapham wrote:Welcome to the Ranch, David!

I'm not surprised that Oracle hasn't produced a rich text editor yet. It's been clear for a while that GUI apps haven't been their priority. And then I heard that JNLP was being deprecated in Java 9. So I think you're right -- don't wait for Oracle to do anything for you in the GUI sphere.

I'm sorry not to brighten your morning.  

LOL yeah. My limited understanding of the fate of JNLP is it is to be replaced with Java devs packaging the unique closure (profile) of Java 9 modules which is particular to their app. The app and those modules are expected to be bundled and there will be no more general runtime (jre). I am not sure how the literal launching of the app's main method will be achieved.



I have searched for a way to express the heart of the issue with being restricted to using only HTMLEditor if you want to write a rich text editor, but I can't find a formulation that doesn't sound like snark.

Sure, the scene graph approach to rendering informational widgets is cool; I acknowledge that, but something else is at stake here that's bigger than cool, responsive infographics.

Here is my best shot at expressing that- all of civilization goes forward on the basis of written text.

What Oracle seems to be implying is all we'll ever need henceforth is HTML for all text-based documents which also appear in electronic form. That's assuming a lot, but especially, the age of innovation wrt to text on screen is o-vah.

It's one thing to have available to you HTML as a possible format / model for a text-based application, but that's not what we have here. JavaFX proposes to force us to drag the entirety of WebKit - or whatever replaces it- into all our text-based applications.

There are so many things just fundamentally wrong with that I don't quite know where to begin. If you want me to elaborate I can, but right now I'm just hoping someone sees a flaw in my analysis.

I've programmed with Java for a long, long time now and have a correspondingly huge technical investment in it, but even I am preparing to abandon ship.  A language that cuts its devs off from the building blocks of text rendering is I'm afraid headed for a slow and painful death.

[Rob Spoor]

Can't you use a security policy to prevent the HTMLEditor from accessing the big bad Internet? Or are security policies overhauled as well right now?

[David Simkulette]

Rob Spoor wrote:Can't you use a security policy to prevent the HTMLEditor from accessing the big bad Internet? Or are security policies overhauled as well right now?

It's a good point. I do know there are customers who wouldn't accept it but that aside, dragging the entirety of WebView and its future fate into the project, all for no benefit to the project, seems crazy.

It's going to bring a huge number of bugs which may or may not ever be addressed and if they are, in what may or may not be a timely manner.   Any one of those bugs can  effect us in unknown, possibly critical, ways, again for exactly zero benefit. I don't want to end up with an application that's subject to and, really, just another realization of,  browser quirks mode when it fundamentally has nothing to do with browsers. I don't want to load it down with all of HTML 5 and javascript and everything those imply.

We just want to put text of our own design on the screen, lay it out as we have need to and get mouse, keyboard and container messages such that we can change that text in response.

HTMLEditor is of course a flow pane in spirit and right away that's not what we want although we'll look at it once we decide whether we're going to use it at all.

At first I thought HTMLEditor was merely an editor whose  formatting default and presentation default was HTML. That would have been OK, even helpful. But it's sooo much more involved and busy.

I am not even certain that this is the end point for the text abilities in JavaFX. Will they bring back the capabilities found in Swing? I can't get an answer from any of the principals involved and the roadmap says nothing about it. Since the "rich text editing control" was due to be released in 8, I have to bleieve that yeah, this is it.

But am I just wrong or am I looking at it the wrong way?  

[John Damien Smith]

The best thing I know of in terms of a native rich text editor for JavaFX is the third party RichTextFX control:
 https://github.com/FXMisc/RichTextFX
There is some info on that here:
 http://fxexperience.com/2013/02/interview-with-tom-schindl-2/
I think the original developer stopped developing it, but it is possible that somebody else from the community picked it up.
I'm sure your research would have brought up RichTextFX, so I'm not sure why you didn't mention it in your posts.

As alternatives you could consider:
 A markdown based editor (there are numerous JavaFX projects for that).
 Use a SwingNode and embed a Swing based editor (such as one of the ones found in the open source Intellij or NetBeans projects), or event a SWT editor (such as the one found in Eclipse).
 A WebView based solution using either the in-built JavaFX HTML editor or a third party JavaScript based rich text editor (of which there are many, many open source projects of varying quality).

I understand that WebView or JavaFX HTMLEditor based is not really what you want based upon your previously posted concerns about that.
My suggestion would be first to investigate RichTextFX and see if it would be a useful solution for you, and, if not consider either the Markdown or embedded Swing based solutions.

----

>Since the "rich text editing control" was due to be released in 8, I have to bleieve that yeah, this is it.

I've been following JavaFX for a while, and I never heard before that such a control was due to be released in 8.  I guess it may have been on some ancient roadmap somewhere, but I doubt its been in the roadmap for the core JavaFX libraries for many years (there is no published roadmap anymore as far as I know).  Pretty much anything which might be on what would resemble a roadmap is likely in Jira.  So you could work out a roadmap by looking at what new features are planned to be implemented in upcoming versions based upon querying Jira.  I looked up rich text editor for JavaFX in jira and it came up with:
  https://bugs.openjdk.java.net/browse/JDK-8091043
That feature request is not targeted for any upcoming release, so it would be unlikely to be implemented within the core JavaFX libraries at any time soon (if indeed ever).
If you have questions about it you can ask on http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev.

-----

> My limited understanding of the fate of JNLP is it is to be replaced with Java devs packaging the unique closure (profile) of Java 9 modules which is particular to their app. The app and those modules are expected to be bundled and there will be no more general runtime (jre). I am not sure how the literal launching of the app's main method will be achieved.

I don't really think there is (or will be) a real replacement for JNLP.  And IMO I think that is OK, as JNLP never IMO provided a good application delivery experience and never was going to ever become a good experience.

I think instead the closest thing (and it is not the same, it is different), is the self-contained application packaging:
 https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html
This uses native tools to bundle together an app and a runtime as a native installer package, so that the user installs your app exactly as they would any other app they install on their OS.
Or the third party Gluon mobile which (I am guessing) provides the same capabilities for mobile environments:
 http://gluonhq.com/products/mobile/

----

> Now I am starting to realize that what Oracle wants is for us to use HTMLEditor as the base for all rich editor controls.

They provide the HTMLEditor but I don't think they care much what is used by others as the basis for their rich editor controls.  I'm not sure it is something they should care much about anyway unless they are able to devote the appropriate resources to support it (which I'm guessing they have decided that they cannot at the current moment).  But, I think the greater issue is whether or not the APIs currently exposed by the core JavaFX libraries in Java 9 is sufficient for somebody else to build and maintain such an editor (assuming that that other entity can also support that effort).  I don't know the answer to that question, I'm guessing that it might be either difficult or not possible, though RichTextFX does currently exist and (if that thing runs on Java 9), then it may prove that such an editor may be possible.

----

> Will they bring back the capabilities found in Swing?

Unlikely (IMO).

----

> But am I just wrong or am I looking at it the wrong way?  

No and perhaps yes.  Certainly waiting "for a rich text editor ala Swing's JEditorPane to surface in Java 8 and now Java 9" is the wrong way...

----

> The thing is, with Java 9, Oracle has effectively cut us off from access to the libraries we need to write a text editor from, more or less, scratch. I am talking about the libraries which were in Swing like LineBreakMeasurer and access to the native libraries for (mouse event) hit testing (upon characters) and many many others.
> Previously, in Swing there was something approaching a 1:1 correspondence between Java classes and the native libraries needed. Now it's more like a curated view to those native libraries indirectly through HTMLEditor, Text and TextFlow (a read only view of text).

Yeah, I don't know, this could be a genuine issue.  I'm guessing you could get around it by packaging as a self-contained app and custom hacking the core JavaFX libs to expose the APIs you need, but that doesn't really sound like a recommended approach ;-)

----

> if I want to write a rich text editor, I can turn my back on my years of Java programming, go native, make friends again with C++, and develop the needed UIs with each platform's respective UI toolkits.

I don't think you really need to do that. That would only really be something that you would do if it was something that you wanted to do.  Technically, there are already ways to get rich editors under the JVM, even if it may mean using a Swing or SWT based solution to get what you want (if RichTextFX or HTMLEditor or WebView based javascript coded editors are not for you).

[David Simkulette]

John Damien Smith wrote:The best thing I know of in terms of a native rich text editor for JavaFX is the third party RichTextFX control:
 https://github.com/FXMisc/RichTextFX
There is some info on that here:
 http://fxexperience.com/2013/02/interview-with-tom-schindl-2/
I think the original developer stopped developing it, but it is possible that somebody else from the community picked it up.
I'm sure your research would have brought up RichTextFX, so I'm not sure why you didn't mention it in your posts.

Yeah I looked at RichTextFX and even more I looked at TextLayout which has what we need access to. Unfortunately there is no path to access to an implmentation of TextLayout , in my case PrismTextLayout  (all the relevant methods are public in this class- but you can't get an instance of it) ) because it's locked inside com.sun and as of Java 9 the module it's in,  graphics, does not export, at least to us.

So it's not that the information we need doesn't exist, it's that it's not in a package we can use. That means we cant do hit testing, for example. We can't  do custom glyph layouts or text justification or obtain the logical-to-visual translations (and back again) between what we see on the screen and our backing store of characters. There's no programmatic control over the cursor or the logiical cursor etc etc.  There's just not the information available to write a word processor.  

I know about RichTextFX and essentially they're an extension of Text and achieve something like AttributedText is in Swing. They also have a demo that uses HTMLEditor (SmashEditor or something).  

John Damien Smith wrote:
As alternatives you could consider:
 A markdown based editor (there are numerous JavaFX projects for that).
 Use a SwingNode and embed a Swing based editor (such as one of the ones found in the open source Intellij or NetBeans projects), or event a SWT editor (such as the one found in Eclipse).
 A WebView based solution using either the in-built JavaFX HTML editor or a third party JavaScript based rich text editor (of which there are many, many open source projects of varying quality).

These are all fine efforts. However, for our purposes, it's still as above.

John Damien Smith wrote:

I've been following JavaFX for a while, and I never heard before that such a control was due to be released in 8.  I guess it may have been on some ancient roadmap somewhere, but I doubt its been in the roadmap for the core JavaFX libraries for many years (there is no published roadmap anymore as far as I know).  Pretty much anything which might be on what would resemble a roadmap is likely in Jira.  So you could work out a roadmap by looking at what new features are planned to be implemented in upcoming versions based upon querying Jira.  I looked up rich text editor for JavaFX in jira and it came up with:
  https://bugs.openjdk.java.net/browse/JDK-8091043
That feature request is not targeted for any upcoming release, so it would be unlikely to be implemented within the core JavaFX libraries at any time soon (if indeed ever).
If you have questions about it you can ask on http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev.

It seems as though request for a rich text was considered fixed in release 8. Following up on the useful links you provided, you can see the FIXED assignment to the issue. The real text APIs do exist already and appear to include everything needed but, for whatever reason, they're not public(ly available) .

This might be because releasing a public API is a huge ontological commitment that will folow you to your grave and for some reason, they anticipate changes to it or feel API isn't ready, but they're working on it.  It could be that they don't want to release it for strategic or commerical reasons. You can't get them to comment on it, so we have zero information and eveything  is speculation.

-----

John Damien Smith wrote:
I don't really think there is (or will be) a real replacement for JNLP.  And IMO I think that is OK, as JNLP never IMO provided a good application delivery experience and never was going to ever become a good experience.

I think instead the closest thing (and it is not the same, it is different), is the self-contained application packaging:
 https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html
This uses native tools to bundle together an app and a runtime as a native installer package, so that the user installs your app exactly as they would any other app they install on their OS.
Or the third party Gluon mobile which (I am guessing) provides the same capabilities for mobile environments:
 http://gluonhq.com/products/mobile/

I think this is right.

John Damien Smith wrote:
> Now I am starting to realize that what Oracle wants is for us to use HTMLEditor as the base for all rich editor controls.

though RichTextFX does currently exist and (if that thing runs on Java 9), then it may prove that such an editor may be possible.

It runs but it doesn't have access to the APIs would need to deliver what we need.  You could never write a CJK layout or other languages, like Mongolian or Arabic which to get a decent layout needs custom layout.  RichTextFX is, when all is said and done, essentially a wrapper around and extension of Text.

Your recommendation to use Swing is spot on. The only issue is whether or not Oracle is going to EOL Swing. It's hard to believe they'd do that, at least before they provided access to the APIs I referred to. For one that would EOL Netbeans IntelliJ and Android Studio, all in one day. I'd say if there's even a hint that they're going to do that there will be a mass defection away from Swing (of course) but also JavaFX and Java wrt to frontend GUI development would be done.

I have a huge commitment to Java from Swing 1.0 forward but nevertheless I am defensively brushing off my c++ and preparing to maintain three libraries for each platform so I am not caught holding the bag if Oracle deprecates Swing and continues to keep the text APIs behind lock and key.

----

John Damien Smith wrote:
> Will they bring back the capabilities found in Swing?

Unlikely (IMO).

Here's hoping you're wrong.

John Damien Smith wrote:
Yeah, I don't know, this could be a genuine issue.  I'm guessing you could get around it by packaging as a self-contained app and custom hacking the core JavaFX libs to expose the APIs you need, but that doesn't really sound like a recommended approach ;-)

This is being considered. What are they going to say if we use their code as a learning tutorial to roll our own? We own text rendering ?

John Damien Smith wrote:
I don't think you really need to do that. That would only really be something that you would do if it was something that you wanted to do.  Technically, there are already ways to get rich editors under the JVM, even if it may mean using a Swing or SWT based solution to get what you want (if RichTextFX or HTMLEditor or WebView based javascript coded editors are not for you).

The two concerns are fear of an ever-growing Swing/JavaFX interoperability quirks mode and long term support of Swing. That's where the FUD is coming from.

[Frits Walraven]

Congratulations David Simkulette,

Your question has made it to our Journal  

Have a Cow!