I think we should continue with Qt, for the following reasons: 1. I’m not aware of any other cross-platform GUI toolkits that are of the same level of quality as Qt. I consider Qt to be an excellent toolkit, and very easy to work with. An alternative may be GTK, but I’m not sure how well this works on Windows and OS X - last time I used it (many years ago) it had to run through an X-Windows app on both, but this may have changed. I’m happy to be advised if this is no longer the case, or if there are any other (good) toolkits with suitable licenses someone can suggests.
2. If we use the native UI toolkit for each platform, then given a fixed amount of developer resources, we’re going to end up with three separate applications that are each 1/3 of the quality/functionality that we’d have with Qt. Even if we can get three times as many people involved (and, in practice, it needs to be more than that anyway as there’s not even enough work going on for the one Qt version), keeping them in sync feature-wise and UI-wise is going to be a huge amount of work. 3. WebKit is LGPL regardless of the platform. On OS X, it’s distributed as part of the system. As far as I’m aware, it’s perfectly valid to link against an LGPL library in any application, regardless of license, including closed-source apps (Safari being an example). LGPL only imposes restrictions on modifications to the LPGL library itself, not code that links against it. 4. It’s my understanding that the only “official” Apache releases are in source form - is this correct? If so, then the source for the Qt app itself would still validly be under the Apache license. The distributed app which combines the open source edition of Qt plus the Corinthia code would necessarily be GPL. If someone wished to produce a closed-source, commercial product based on the desktop app part of Corinthia, they could purchase a Qt commercial license and do so, within the terms of the Apache license. Granted, this is less ideal than being able to do so without the requirements of purchasing a Qt license. In an extreme case, someone could produce a “wrapper” library which emulates the subset of Qt APIs that the Corinthia desktop uses, to allow it to run on a given target platform. In fact, this is exactly what Apple did in 2002 when they ported khtml to OS X, and renamed it to WebKit (the codebase started off as part of the KDE project). I think the most pertinent issue is #2 - I really think moving away from Qt is going to create more problems that it solves in terms of the significant extra work it’ll require. In fact it puts the project at risk due to there not being enough people or people with enough time to complete a functioning GUI on all major desktop platforms. With Qt we have a decent chance, and I think it will be easier to attract new people (e.g. Capstone project) when we have one codebase instead of three. — 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) > On 26 Jul 2015, at 5:16 pm, jan i <j...@apache.org> wrote: > > Hi > > I am currently updating the cmake files to cover e.g. the editor and see > some problems. > > I know we decided to use Qt, but I would like to take the discussion again. > > If we use Qt the editor will never be a released product, it will remain an > optional product, and > I think we will want to position the editor as a main feature of corinthia. > > There is an alternative to Qt, which is a little more work but not much. If > we look at how peter > currently uses Qtwebkit it is pretty simple and static. > > Webkit is builtin on OS-X, therefore we can use it, without thinking too > long about the licenses > (we do not ask people to download extra libraries, so it is at the same > level that we also depend on windows sdk-api). > > We cannot use webkit on windows because it is LGPL (same as Qt), but we can > use mshtml or IWebBrowser2. My idea is to make a simple set of wrapper > functions, so that > the editor as such does not see the difference. That would allow us > to have the editor as a main feature. > > thoughts ? > > rgds > jan i.
