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
for me.
(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.
One was-
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
worse.
So there's that.
Another was:
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
software.
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.r...@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
as
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
work.
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.
-phil.
On 11/25/2017 03:40 PM, jav...@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
in
order to write a rich text editor from scratch. LineBreakMeasurers
and
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
to
write their own rich text editor. They exist, but are under sun.com
and given the modularization of Java 9 are truly inaccessible to
developers.
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
editor
and all of them without exception are handicapped by this same lack
of
API.
I am also aware of HTMLEditor in JavaFX but that 1) commits the dev
to
WebRenderer and 2) still doesn't provide access to the needed
classes
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
any
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.
