Text classes

[javafx at use.startmail.com]

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.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 
> 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, 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 
>> 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.