> On 27 Jul 2015, at 5:20 pm, jan i <j...@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? 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 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. 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 pmke...@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)
