corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: dfedit considerations and challenges.
Date Fri, 06 Mar 2015 11:59:15 GMT
> On 6 Mar 2015, at 5:33 pm, jan i <> 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

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 <>) 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+ (

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

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message