javafx at use.startmail.com
javafx at use.startmail.com
Tue Dec 5 23:55:10 UTC 2017
No Oracle plans !!!
My one sentence rant:
Interactive infographics are a cool way to represent complex
information and actgually represent a genuinely new way to communicate
information which in some cases is also the best way or all possible
ways, but there are at least two other ways that are also the best way
under some circumstances- mathematics and the printed word. You can't
possibly think you're going to release a GUI toolkit that doesn't fully
support the written word. The vast bulk of civilization goes forward on
the written word.
I would gladly do it or join an effort but I can't get JavFX to build
and after a real, full week or trying, gave up for-ev-vah and moved on
to other stuff. I am going to leverage Swing for my Fontly needs and am
brushing of my C++ in case it JavaFX never does it and Oracle
(foolishly!!!) deprecates Swing ....at which point it's abandon Java
(Really, it's not seen as practical to use the existing implementation
under the hood in FX ? Not even as a jumping off point? )
At the end of my WeekFromHellTryingToBuildJavaFX I had a couple of what
I considered to be insights, based on my limited knowledge of JavaFX ,
which I'm going to pretend I don't realize are likely of sub-zero
interest to readers of this forum and consequently share with you.
Yeah.... large, possibly huge, text documents are not the best fit for
the particular scene graph implementation that is JavaFX.
In short, JavaFX is *almost* a physics engine in the sense that a
change in the size of THAT Node a way over yonder could crerdibly cause
a repositioning of any or all Nodes in the scene graph as a result of
resizing and the reactions of layout managers to that resizing. What
that means for Big Text documents with LOts Of Text Nodes is a change
in any of the CSS property values (or mutation of the words themselves)
could kick off quite a process or recalculating where the CPU sucking
methods that show up in my profiler, mostly reclaculating Rectangular
bounds, are going to bring your program down.
I can get about 20k nodes to step lively in a program but 200k Nodes
makes the scene never render at all, much less be usable. That's the
scene graph. But documents have more than 200k words in them, If a
change in font or style delineates the boundaries of a (causes the
creation of a new) Text Node (it is) then it's just waaaay too easy to
generate waaay too many Nodes and, looking intothe future of Text
where whole chunks of it will be created by computers (AI) but consumed
by humans (analysis, digestion) TooManyNodes is only going to get
So there's that.
We devs have made quite a little problem for ourselves with respect to
being able to communicate to others of our kind the necessary and
siffcient conditions a machine must be in in order to build a pierce of
We really have no way to put an alien computer into a build-ready state
or even communicate the conditions it needs to be in in real actionable
detail. Talk about versions of this and defining system variables to be
that are at best partial, ad-hoc efforts doomed to fail for a large
number of people and ultimately backed by ignorance about the ACTUAL
state of our own machines and chock-o-block woth unwarranted
assumptions about the state of the would-be builder's machine. Variable
are defined randomly in build scripts and those variables are often
literally stitched together over widely separated statements from
variables' values assumed to be present on the machine and assumed to
hold certain values.
Build scripts are necessarily dependent on assumptions about the
specific internal state of third party software they have no control
over and that state is often temporary, en passant, shortly to become
literally unavailable to future devs.
Organizations can mothball the required versions of software, create
identical machines and have build vetrans available to troubleshoot the
build but even those savants have no way of communicating to others
what the magic is in their witches brew and they themselves are not
aware of everything that goes into a successful build.
It's as I said, a wicked problem.
On Tuesday, December 5, 2017 3:41 PM, Phil Race
<philip.race at oracle.com> wrote:
> This is a gap it would be nice to fill.
> Since it is not a small effort to do right there'd be a design side
> well as implementation so it can't be just 'slid in'.
> And I don't think just moving internal APIs to public is the way to
> approach it.
> There are no current plans to allocate Oracle resources to do that
> But this is an open source project, so if someone on this list is
> willing to design & contribute it - and of course
> fix the issues and long term maintain it - then that would be great.
> On 11/25/2017 03:40 PM, javafx at use.startmail.com wrote:
>> Hi, This is a question about the future of Text under Javafx.
>> Very briefly, Swing provided access to everything a dev could need
>> order to write a rich text editor from scratch. LineBreakMeasurers
>> HitTesting and everything.
>> In JavaFX these things are not directly available to the dev and
>> anyway, to the extent that they are, they cannot be used to write a
>> rich text editor..
>> There are many classes needed involving the measuring of glyphs and
>> text lines etc etc etc which would be needed for anyone who wanted
>> write their own rich text editor. They exist, but are under sun.com
>> and given the modularization of Java 9 are truly inaccessible to
>> I am aware of the existing Javafx controls. I am also aware of the
>> efforts available at GitHub and elsewhere to create a rich text
>> and all of them without exception are handicapped by this same lack
>> I am also aware of HTMLEditor in JavaFX but that 1) commits the dev
>> WebRenderer and 2) still doesn't provide access to the needed
>> and methods. It's not sufficient to suppose that HTML 5 or whatever
>> follows is the answer to all text layout challenges.
>> Formerly, Swing had all these missing features available as API and
>> many good text editors were created using those APIs.
>> For the sake of future planning, we really need to know- is there
>> recognition within Oracle that this is something which has to be
>> addressed? Is it on any hypothetical roadmap? Or is HTMLEditor as
>> much as JavaFX is going to provide ?
>> Thank you.
More information about the openjfx-dev