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