You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by jan i <ja...@apache.org> on 2015/03/06 11:40:05 UTC
Fwd: dfedit considerations and challenges.
HI.
We recently discussed Qt as a replacement for VCL, it might be of interest
that in corinthia we are working quite intensive on making a multiplatform
rendering engine for our editor.
This work could be extended to replace VCL engine (NOT the macros in the
application code). The biggest job would be to write a HTML5/CSS snippet
and a javascript snippet for each type of VCL macro and secondly write a
generator on top that combines the snippets with the macro calls and
generates executable HTML5/CSS/javascript code.
I am merely mailing this as information, since I am involved in both
projects, and wants to see both projects evolve.
rgds
jan I.
ps. Using Qt in corinthia is not a problem, since it only affects a little
part of the total code base, so no need to discuss that in here.
---------- Forwarded message ----------
From: jan i <ja...@apache.org>
Date: 6 March 2015 at 11:33
Subject: dfedit considerations and challenges.
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org
>
hi.
I have started the work on a new consumer dfedit, which will be a
standalone exe that on side side connects to DocFormats and on the other
side to our javascript editor code.
I have been doing some research and want to hear other opinions.
Prerequisites:
dfedit should be available on:
- IoS with safari providing the rendering engine
- MacOS with safari providing the rendering engine
- Windows with IE providing the rendering engine (as far as I can see IE
rendering engine is available even if IE exe is uninstalled and replaced by
e.g. firefox).
- Linux with Firefox providing the rendering engine.
These are to me, the minimum we need to support, supporting more is good,
but not an ultimate requirement.
Solutions:
I am lazy so I do not want to program directly against all those rendering
engines, instead I want to use a library...for that purpose I researched a
couple.
- WebKIT, has a real nice API, but requires safari to be installed on
windows, and will require a (maybe simple) port to e.g. ubuntu and freebsd.
- qtWebKit is discontinued (but still supported) and replaced by qtWebEngine
- qtWebEngine has a real nice API, but requires chrome to be installed
- Blink (google) is in java, and thus not very funny to integrate with
DocFormats (or IoS)
I have not found other interesting kits, so right now it seems I have to:
- support webkit
- support firefox engine
- support IE engine
This would mean I would write an abstraction layer, but maybe this is a
better long term solutiion.
Thoughs and ideas are more than welcome.
rgds
jan i.
Re: Fwd: dfedit considerations and challenges.
Posted by Kay Schenk <ka...@gmail.com>.
On 03/06/2015 02:40 AM, jan i wrote:
> HI.
>
> We recently discussed Qt as a replacement for VCL, it might be of interest
> that in corinthia we are working quite intensive on making a multiplatform
> rendering engine for our editor.
>
> This work could be extended to replace VCL engine (NOT the macros in the
> application code). The biggest job would be to write a HTML5/CSS snippet
> and a javascript snippet for each type of VCL macro and secondly write a
> generator on top that combines the snippets with the macro calls and
> generates executable HTML5/CSS/javascript code.
>
> I am merely mailing this as information, since I am involved in both
> projects, and wants to see both projects evolve.
>
> rgds
> jan I.
>
> ps. Using Qt in corinthia is not a problem, since it only affects a little
> part of the total code base, so no need to discuss that in here.
Ok, thanks for this. Please keep us apprised of this progress.
I hope *real soon* we can put some effort into a unifying user
environment like QT. We have many issues that I feel are due to user
interface differences, instead of the perceived core programming issues.
>
> ---------- Forwarded message ----------
> From: jan i <ja...@apache.org>
> Date: 6 March 2015 at 11:33
> Subject: dfedit considerations and challenges.
> To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org
>>
>
>
> hi.
>
> I have started the work on a new consumer dfedit, which will be a
> standalone exe that on side side connects to DocFormats and on the other
> side to our javascript editor code.
>
> I have been doing some research and want to hear other opinions.
>
> Prerequisites:
>
> dfedit should be available on:
>
> - IoS with safari providing the rendering engine
>
> - MacOS with safari providing the rendering engine
>
> - Windows with IE providing the rendering engine (as far as I can see IE
> rendering engine is available even if IE exe is uninstalled and replaced by
> e.g. firefox).
>
> - Linux with Firefox providing the rendering engine.
>
> These are to me, the minimum we need to support, supporting more is good,
> but not an ultimate requirement.
>
>
> Solutions:
>
> I am lazy so I do not want to program directly against all those rendering
> engines, instead I want to use a library...for that purpose I researched a
> couple.
>
> - WebKIT, has a real nice API, but requires safari to be installed on
> windows, and will require a (maybe simple) port to e.g. ubuntu and freebsd.
>
> - qtWebKit is discontinued (but still supported) and replaced by qtWebEngine
>
> - qtWebEngine has a real nice API, but requires chrome to be installed
>
> - Blink (google) is in java, and thus not very funny to integrate with
> DocFormats (or IoS)
>
> I have not found other interesting kits, so right now it seems I have to:
> - support webkit
> - support firefox engine
> - support IE engine
> This would mean I would write an abstraction layer, but maybe this is a
> better long term solutiion.
>
>
> Thoughs and ideas are more than welcome.
> rgds
> jan i.
>
--
-------------------------------------------------------------------------
MzK
"An old horse for a long, hard road,
a young pony for a quick ride."
-- Texas Bix Bender
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org