corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: Is Qt the right choice ??
Date Mon, 27 Jul 2015 19:00:17 GMT
On 27 July 2015 at 20:33, Peter Kelly <pmkelly@apache.org> wrote:

> > On 27 Jul 2015, at 5:20 pm, jan i <jani@apache.org> 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:
> > http://www.apache.org/legal/resolved.html
> > 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?
>
I have searched for quite sometime also because AOO thought about changing,
and did not find a better multiplatform library.

>
> 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.
>
+1, We should be able to isolate the Qt part to a single source of ours.


>
> 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 are:
>
> - Loading/saving of documents, including selection of files (using the
> system’s open/save dialog)
> - 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.
>
I had most of this in mind, but it still boils down to a pretty simple
interface between
Our application code -> UI (ex. QT) -> Web/JS integration.

Risking being told otherwise, I would say the lines of code would be 80% -
15% - 5%


>
> 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.
>
That is an alternative I have been playing with, it might be a good
compromise.

I suggest we suggest we continue as you have started with Qt, try to
isolate the Qt in a single file, and then we take the discussion as we go
along.

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

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