proposal for asynchronous compatability with SwingJS

[BobHanson]

I'll be adapting OpenChemLib for JavaScript/SwingJS. It's all working there, as discussed in issue #83, with the exception of modal dialogs. I have those working as well, but it requires some additional classes and adjustments -- specifically:

1. exposing the mDialog field of CustomAtomDialogBuilder (and perhaps other related dialogs),
2. allowing for the chaining of event handlers, and
3. addition of an GenericEditorArea.showCustomAtomDialog extension with optional OK and Cancel java.lang.Runnable parameters

In addition, at least for now (maybe address this when I have a bit more time), I'm bypassing the Glyph font business. Honestly, I can't see any difference there on my machine when I replace that with standard fonts. Is there some particular reason to use the Glyph fonts?

This seems to be all I need.

I'm thinking I will fork the repo anyway, so that I can have a "OCL-SwingJS" branded repo, but I was wondering if you want to provide me a branch in addition to that so that you can see exactly what is involved.

Let me know what you think best. I will start on the fork right now; hope to have this all done tomorrow.

OCL has been a great contribution to JME-SwingJS (and, consequently, Jmol-SwingJS). Just lovely. You can thank Bruno Bienfeit for introducing me to OCL.

BTW - I realize that SwingJS is not for everyone, but it is certainly proving to be up to everything I throw at it in Java 8 and some in Java 11+ (but the coverage there is very minimal, just on demand). Probably about 30-40% the speed of Java. Plenty of speed for everything I have needed on web pages. Decently small footprint and transfer size. (JME with OCL is 750K transferred by gzip -- maybe a second or two of startup.) Relatively full files system and Swing capabilities; asynchronous, even with modal dialogs.

As we are seeing with OpenChemLib, the "adjustment" to JavaScript doesn't impact the Java at all -- or actually, in many cases, the bit of asynchronous business actually makes the Java much more transparent. (See, for example, OpenSource Physics, Falstad physics applets, OSP, and Tracker. In that project, the process of adapting to JavaScript made the Java hugely more efficient as well and took literally seconds off the Java start-up loading by the time we were done with it all.)

And it is so delightful to simultaneously test in both Java and JavaScript on the fly. So fun!

Bob

[BobHanson]

If you are interested, the fork is at BobHanson/OCL-SwingJS. It was about a day's work. Not by any means well tested. But the basics are there.

[BobHanson]

(See the closed issues for commentary

[BobHanson]

Final development note on this is at BobHanson#12