priorities

Abossolo Foh Guy guy.abossolo.foh at scientificware.com
Wed Oct 3 11:49:48 UTC 2018


Hi,

I'm also interested by adding Mathematic support to your list of 
features. I already do it with swing/text API.

I tried with TextArea but its document model is too simple to support 
that.
So I'm trying to port the swing document model to JavaFX. This work is 
in progress but I took a break to work on MathML issue in the JavaFX 
WebKit implementation.

Basing the work on swing/text with DOM could be very interresting for 
many persons who want to migrate to JavaFX.

As Johan said, some JavaFX applications already do this job :
By example Jordan Martinez posted a message on openjdk or openjfx mail 
list about RichTextFX, he was looking for a new maintener. Could a fork 
of this project integrate JavaFX ?

Best regards.

Guy.
-----------------------------
Le 2018-10-03 12:18, John-Val Rose a écrit :
> I also agree that full-featured text editing functionality would be
> highly advantageous.
> 
>> On 3 Oct 2018, at 19:36, Tom Schindl <tom.schindl at bestsolution.at> 
>> wrote:
>> 
>> Hi,
>> 
>> I should add (I already talked about that on twitter, ...) that we are
>> actively working on a PoC for the primary issue I mentioned below but 
>> I
>> think the technical discussion has to happen on openjfx-dev mailing 
>> list.
>> 
>> Tom
>> 
>>> On 03.10.18 11:30, Dirk Lemmermann wrote:
>>> I strongly agree with Tom and would like to add that the missing 
>>> support for rich text display and rich text editing is what caused me 
>>> by far the most problems in my last project. We actually had to use 
>>> Swing for this part of the UI.
>>> 
>>> Rich text here: bold, italic, foreground, background color, sup, sub, 
>>> different fonts, hyperlinks, images, tables.
>>> 
>>> Dirk
>>> 
>>>> Am 03.10.2018 um 11:17 schrieb Tom Schindl 
>>>> <tom.schindl at bestsolution.at>:
>>>> 
>>>> Hi,
>>>> 
>>>> For us (I speak for BestSolution and our customers who don't want 
>>>> their
>>>> name showing up in public :-(
>>>> 
>>>> The following things are imporant:
>>>> * Integration of Native-Rendering (OpenGL / DirectX / Metal) into 
>>>> JavaFX
>>>> applications where all information is kept on GPU and never escapes
>>>> that
>>>> 
>>>> * Performance (most importantly CSS)
>>>> 
>>>> Tom
>>>> 
>>>>> On 03.10.18 10:56, Johan Vos wrote:
>>>>> Every now and then people ask about the roadmap of JavaFX. Apart 
>>>>> from my
>>>>> general answer that the roadmap is mainly determined by the people 
>>>>> who
>>>>> contribute, here are some personal thoughts:
>>>>> 
>>>>> * JavaFX can be used in a large number of vertical markets, with 
>>>>> totally
>>>>> different requirements. We should be careful not to introduce
>>>>> API's/features that make JavaFX a conflicting component in some 
>>>>> markets.
>>>>> 
>>>>> * There are a number of third party libraries/frameworks (e.g. 
>>>>> ControlsFX,
>>>>> FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
>>>>> functionality. I think OpenJFX has to provide the foundation for 
>>>>> these
>>>>> specific frameworks, rather than include their functionality.
>>>>> 
>>>>> * hardware accelerated rendering is key. We have to keep up with 
>>>>> recent and
>>>>> future evolutions.
>>>>> 
>>>>> * cross-platform is key.
>>>>> 
>>>>> In summary, I think that we have to make sure that JavaFX provides 
>>>>> the most
>>>>> performant rendering, and the most useful API allowing third 
>>>>> parties to
>>>>> create libraries and applications on a variety of platforms.
>>>>> 
>>>>> - Johan
>>>>> 
>>>> 
>>>> --
>>>> Tom Schindl, CTO
>>>> BestSolution.at EDV Systemhaus GmbH
>>>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>>> 
>> 
>> --
>> Tom Schindl, CTO
>> BestSolution.at EDV Systemhaus GmbH
>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

-- 


More information about the openjfx-discuss mailing list