On 27 July 2015 at 20:33, Peter Kelly <[email protected]> wrote: > > On 27 Jul 2015, at 5:20 pm, jan i <[email protected]> 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 > [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) > >
