> On 6 Mar 2015, at 5:33 pm, jan i <[email protected]> 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 [email protected] 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)
