You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by jan i <ja...@apache.org> on 2015/03/06 11:33:12 UTC
dfedit considerations and challenges.
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: dfedit considerations and challenges.
Posted by Peter Kelly <pm...@apache.org>.
> On 6 Mar 2015, at 5:33 pm, jan i <ja...@apache.org> wrote:
>
> - qtWebKit is discontinued (but still supported) and replaced by qtWebEngine
>
> - qtWebEngine has a real nice API, but requires chrome to be installed
http://doc.qt.io/qt-5/qwebview.html <http://doc.qt.io/qt-5/qwebview.html> doesn’t mention anything about deprecation - is this different from that you meant with qtWebKit? AFAIK this has been a standard part of Qt for years and looks to be still supported in 5.4 (I haven’t used it; just going on a quick glance at the documentation).
Also of note is http://doc.qt.io/qt-5/qwebframe.html <http://doc.qt.io/qt-5/qwebframe.html> which has information about evaluating javascript code in the context of the loaded HTML page, which we’ll need to interface with the JS editing library.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
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
Fwd: dfedit considerations and challenges.
Posted by jan i <ja...@apache.org>.
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: dfedit considerations and challenges.
Posted by Peter Kelly <pm...@apache.org>.
> On 6 Mar 2015, at 5:33 pm, jan i <ja...@apache.org> wrote:
>
> 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.
Excellent! Although I would suggest we use a different name - the ‘df’ prefix was intended to refer to DocFormats specifically (it’s just one of several libraries that an end-user application would use), and it was also chosen as a poor-mans namespacing mechanism (e.g. using ‘dfconvert’ instead of ‘convert’, the latter already having been taken my ImageMagick, which is often installed on many Linux distributions).
So I think we need to come up with a friendly and easily-rememberable name for the app. Perhaps we could simply call it ‘Corinthia’, though that does risk confusion between the application and the project (the latter being of much broader scope). But we need something sexy here.
> 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.
It’s important here to make a distinction between a web browser and a rendering engine. Safari, IE, and Firefox, and other web browser are applications which utilise a particular library for displaying web content (respectively, WebKit, Trident/MSHTML, and Gecko). Any editing application we build would not be using the former, but would instead be using the latter.
Under iOS, there is a view class called UIWebView which can be used to display web content. It uses WebKit, but that’s just an implementation detail. UX Write uses this class.
OS X provides a similar class simply called WebView, which also uses WebKit behind the scenes.
As of fairly recently it’s now possible to get broader access to more of the actual WebKit API on iOS (see http://nshipster.com/wkwebkit/ <http://nshipster.com/wkwebkit/>) whereas it used to be quite limited. OS X, to the best of my knowledge, has always provided applications with the full WebKit API.
Windows has, since the 90s, provided an API for using Trident/HTML to applications. I’m not familiar with the API (and actually I suspect there’s more than one, at minimum one for C++ and one for .NET - maybe Dennis might know more about this than me).
It seems very odd to think about it now, but as some of you will remember, the US Department of Justice held an antitrust case against Microsoft in the late 90s, arguing that distributing IE as part of windows was anti-competitive (Netscape being the main victim at the time). Part of Microsoft’s argument was that it couldn’t simply remove it altogether, as there were many third-party applications which use the MSHTML API for either displaying web pages or their own HTML-generated content. I remember doing something like this back in 1996 or 1997 in Delphi, which provided it’s own wrapper around the APIs.
On Linux, I’m even less sure about what the situation is. I assume there are versions of WebKit that could be used directly as such (that is, without libraries that wrap around it like Qt), and similarly for Gecko. The only such project I can think of off the top of my head is WebKitGtk+ (https://wiki.gnome.org/action/show/Projects/WebKitGtk?action=show&redirect=WebKitGtk <https://wiki.gnome.org/action/show/Projects/WebKitGtk?action=show&redirect=WebKitGtk>).
It’s disappointing to hear that qtWebKit has been discontinued, and I think it’s unfortunate that they require the existence of Chrome on a machine to make it work. Nonetheless, I think this would still be the best approach for targeting cross-platform desktop apps.
Regarding iOS and Android: I think that a cross-platform application which runs on both desktops and mobile operating systems using the same UI is a flawed idea, due to the vastly different form factors and ways in which people use tablets and mobile phones. Just look at LibreOffice’s attempts at porting to Android, and MS Office 2013 running in a windows surface. Mobile versions should have interfaces specifically designed for the form factor. Hence the reason for having multiple independent libraries that can be used to build different applications on top of.
> 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.
I would suggest Qt - since this already provides an abstraction layer (albeit at the cost of requiring chrome installation). Other than that, sadly, I think the answer is that yes, you would need an abstraction layer. But we still need a UI toolkit, and Qt seems to be a good choice.
Having said that, having a “sample” app targeted at each might be a useful demonstration of the versatility of the libraries that are part of our project. Though that’s a separate task from building the main editing application itself.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: dfedit considerations and challenges.
Posted by jan i <ja...@apache.org>.
Hi again.
A little update, after a couple of hints (opinions) from Peter I am
progressing well on playing with Qt for the editor.
The code will be made so that different platforms can have different
layout, but the same basic functionality.
I have now reached a point where I need to take a design decision, and I
wanted to hear the opinions of others.
Regarding the editor itself, I can
1) Implement the editor as HTML5 with the JS directly integrated. The text
to be edited would be in an independent iframe. The currect JS code seems
to go in this direction.
The Qt glue code, would in this case contain call back functions that
catches e.g. click events in the editor.
2) Implement the editor as Qt eleements and only the text to be edited is
in the HTML window. When a Qt element is clicked on, the corresponding JS
code will be executed in the HTML window.
The main difference is merely design. In the first we only use HTML5
whereas in the second we use Qt. The second seems to give us better design
posibilities.
In both cases we will (later) isolate the Qt elements we use, have a
library with exactly those as Catagory B source.
thoughts ?
rgds
jan I.
On 7 March 2015 at 00:39, Andrea Pescetti <pe...@apache.org> wrote:
> Dennis E. Hamilton wrote:
>
>> I've installed Linux desktop distributions that also include Chrome
>> by default, so FireFox might not be that ubiquitous. I don't have
>> any Linux installs at the moment, so I can't tell you
>>
>
> Nothing in Linux is ubiquitous, except some basic components. That's a
> sign of freedom/independence after all. But Firefox is surely available for
> almost all distributions, and Chromium (not Chrome) can be found on most
> modern distributions too.
>
> Regards,
> Andrea.
>
Re: dfedit considerations and challenges.
Posted by Andrea Pescetti <pe...@apache.org>.
Dennis E. Hamilton wrote:
> I've installed Linux desktop distributions that also include Chrome
> by default, so FireFox might not be that ubiquitous. I don't have
> any Linux installs at the moment, so I can't tell you
Nothing in Linux is ubiquitous, except some basic components. That's a
sign of freedom/independence after all. But Firefox is surely available
for almost all distributions, and Chromium (not Chrome) can be found on
most modern distributions too.
Regards,
Andrea.
RE: dfedit considerations and challenges.
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I've installed Linux desktop distributions that also include Chrome by default, so FireFox might not be that ubiquitous. I don't have any Linux installs at the moment, so I can't tell you which those were.
- Dennis
PS: And of course node.js uses the Chrome JavaScript engine, but independent of Chrome being installed.
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Friday, March 6, 2015 04:24
To: dev@corinthia.incubator.apache.org
Subject: Re: dfedit considerations and challenges.
[ ... ]
I am a bit concerned about depending on chrome, at least I would need to
test that on my ipad first.
rgds
jan I.
[ ... ]
Re: dfedit considerations and challenges.
Posted by Peter Kelly <pm...@apache.org>.
> On 6 Mar 2015, at 7:23 pm, jan i <ja...@apache.org> wrote:
>
> I am a bit concerned about depending on chrome, at least I would need to
> test that on my ipad first.
Does the QWebView class listed in the Qt docs say that it depends on Chrome? I couldn’t see any mention of that; my (possibly very out of date) understanding was that they had their own version of webkit which was built in to Qt - that is, all you need is the Qt library itself.
qtWebKit and qtWebEngine appear to be separate things from QWebView.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: dfedit considerations and challenges.
Posted by jan i <ja...@apache.org>.
On 6 March 2015 at 13:09, Peter Kelly <pm...@apache.org> wrote:
> > On 6 Mar 2015, at 7:07 pm, Peter Kelly <pm...@apache.org> wrote:
> >
> >> On 6 Mar 2015, at 5:33 pm, jan i <jani@apache.org <mailto:
> jani@apache.org>> wrote:
> >>
> >> - Blink (google) is in java, and thus not very funny to integrate with
> >> DocFormats (or IoS)
> >
> > Actually I’m pretty sure Blink is in C++, since it’s a fork of WebKit. I
> haven’t been following it’s development in the split, but unless they’ve
> decided to rewrite all of WebKit in Java over the past year (highly
> unlikely) I don’t think this is the case.
> >
> > The API for using web views in Android is in Java however (as are all
> the user interface APIs on Android).
>
> And here’s a C++ API for Blink: http://www.chromium.org/blink/public-c-api
> <http://www.chromium.org/blink/public-c-api>
>
Thanks, seems I searched on another path, where they had a JAVA API and
called a ported version of webkit.
I am just trying to sum up, sorry if I forget something.
I agree that the look and fell on different platform need to be different,
but I would like to have 1 editor code (whatever we call the exe). I think
the differences is more in the layout and not in the actual function
implementation. So maybe having different HTML5 start code, would do the
job.
I also agree on your point about browser, this is why I wrote rendering
engine. IE uses something internal in windows 7 and 8, that does the
rendering. Firefox (or mozilla) has a development package similar to
webkit, this package is built into the firefox browser and (at least on
windows) available as dll.
I am a bit concerned about depending on chrome, at least I would need to
test that on my ipad first.
rgds
jan I.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: dfedit considerations and challenges.
Posted by Peter Kelly <pm...@apache.org>.
> On 6 Mar 2015, at 7:07 pm, Peter Kelly <pm...@apache.org> wrote:
>
>> On 6 Mar 2015, at 5:33 pm, jan i <jani@apache.org <ma...@apache.org>> wrote:
>>
>> - Blink (google) is in java, and thus not very funny to integrate with
>> DocFormats (or IoS)
>
> Actually I’m pretty sure Blink is in C++, since it’s a fork of WebKit. I haven’t been following it’s development in the split, but unless they’ve decided to rewrite all of WebKit in Java over the past year (highly unlikely) I don’t think this is the case.
>
> The API for using web views in Android is in Java however (as are all the user interface APIs on Android).
And here’s a C++ API for Blink: http://www.chromium.org/blink/public-c-api <http://www.chromium.org/blink/public-c-api>
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: dfedit considerations and challenges.
Posted by Peter Kelly <pm...@apache.org>.
> On 6 Mar 2015, at 5:33 pm, jan i <ja...@apache.org> wrote:
>
> - Blink (google) is in java, and thus not very funny to integrate with
> DocFormats (or IoS)
Actually I’m pretty sure Blink is in C++, since it’s a fork of WebKit. I haven’t been following it’s development in the split, but unless they’ve decided to rewrite all of WebKit in Java over the past year (highly unlikely) I don’t think this is the case.
The API for using web views in Android is in Java however (as are all the user interface APIs on Android).
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)