corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: Is Qt the right choice ??
Date Mon, 27 Jul 2015 18:33:39 GMT
> On 27 Jul 2015, at 5:20 pm, jan i <> wrote:
> Hi Peter
> sorry for top posting, but I try to answer both of your mails in one.
> The licensing problem is a bit more complicated.
> Apache source is not allowed to depend on third party libraries that uses
> e.g. LGPL if you
> want to read details you can find it here:
> disc
> In general there are a number of loopholes:
> - if the library is part of the OS we don´t care (think of Microsoft
> SDK/MFC, OS-X core libraries and glibc), so webkit on OS-X is not a problem
> - if the component is optional we don´t care in case of LGPL

So much for open source/free software as an antidote to the “walled gardens” that Apple
and the like are often criticised for. In FOSS we have walls of a different form dividing
those who favour the GPL/LPL and similar licenses, and those who favour more liberal licenses
like MIT/BSD/Apache, with the licenses limiting what would otherwise be beneficial code sharing

I understand there are perfectly valid and well-considered reasons for the rules you’ve
mentioned that have been reached as a result of consensus at Apache, and there’s little
point in trying to argue against that. And we can certainly ship a Qt-based editor as an optional
component. So really I’m interested in the practical steps we can take to come up with something
that’s as useful as possible within these limitations.

1. Which UI toolkit is best for Apache project, and that other projects are already using?
I had a brief look around at lists of potential candidate UI toolkits but didn’t find anything
that was both good quality/mature and with a friendly license. But I’ve quite possibly missed
something. Are there other ASF project that provide a desktop app (and aren’t in Java) that
we can learn from and take a similar path to them?

2. Perhaps we should consider implementing as much as possible of the desktop editing app
in a way that is independent of Qt. Parts of the code do not involve UI code at all (e.g.
logic for loading/saving files, doing calculations regarding stylesheet properties, building
a data structure representing the document outline). These are “model” classes, and could
use some basic utility classes for strings, dictionaries, expandable arrays etc that we currently
use in Qt (in fact we already have some of these in DocFormats, e.g. DFHashTable). Then the
UI part of the (main) editor app could be implemented in Qt, but others could use Objective
C/Swift on Mac, C# on Windows etc. to implement a platform-specific UI layer.

3. I just realised after I sent my last mail that I don’t think I’ve fully articulated
the nature of what is required on the “native” side to supplement the JS editing library
to produce a fully-working application. Some of the things the native app needs to provide

- Loading/saving of documents, including selection of files (using the system’s open/save
- Menus and toolbars for providing access to commands
- Dialogs for things like inserting a table, adding a picture, changing all formatting properties
(colour wheels, line width selectors, font lists, control over paragraph borders etc.)
- Spell checking
- Find & replace
- Word count
- A style editor, including all major CSS properties (using the formatting controls above)
- Interacting with the API calls in the JS library for mouse and keyboard events for cursor
placement & movement, selection, text insertion/deletion, and copy/paste
- Error reporting dialogs
- Splash screen, about box, help etc.

As you can see from this list, there’s a *lot* more than simply bringing up a web view and
displaying a HTML-based UI - the design all along (which comes from the goals of UX Write)
was to provide a native UI for the best user experience, and only use the web view as a place
to render documents.

This breakdown could be revisited, however - many of the above things could be implemented
as a web UI and displayed through a web view (assuming a suitable one is present, e.g. WebKit
on OS X and IWebBrowser2 on Windows). In fact we really need to do this anyway for the browser-based
version of the editor. It wouldn’t feel as “native”, but would at least give a large
portion of the above functionality.

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