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