One other thought on the issue of Qt: I think we need to be careful to balance the goals of getting to a functioning reference implementation, and ensuring that we have an app that can be built without depending on any LGPL libraries. Actually I thought the whole point of LGPL was that you can use it in applications under any circumstance, and only need to distribute any changes to the library itself. This is the first instance in which I’ve been aware that it carries other obligations (which I’m still confused about).
Right now I think the discussion has turned too far towards the latter licensing issue. We’re here to build great software (or at least, I am) - that’s the goal, everything else is in support of that. Yes, we do need to ensure that anything that we mark as part of the “core” (non-optional) part of the codebase can be built by depending only on Apache-licensed code or operating-system libraries. But to be honest, I see this issue as a block on development. If we get too caught up in religiously following rules at the expense of development speed, we put the project at risk - either by taking to long to eventually get something done, or potentially alienating new or existing contributors. That last point should not be taken lightly - look at what happened with the OpenOffice/LibreOffice split. So I’d like to politely suggest that we keep the big picture in mind and not let it derail the project. I’m personally quite frustrated by this situation, but I’m putting up with it and trying to work towards a solution which will keep everybody happy while also not getting too much in the way of development progress. As far as my own involvement is concerned, getting to something that works well and benefits people is the thing that motivates me. I think Jan’s proposal provides a good solution, and hope we can move forward with that. — 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 29 Jul 2015, at 11:31 pm, Peter Kelly <pmke...@apache.org> wrote: > >> On 29 Jul 2015, at 10:56 pm, Dennis E. Hamilton <dennis.hamil...@acm.org> >> wrote: >> >> I think this is an interesting idea. >> >> I want to test my understanding. >> >> An important provision is the API and callbacks of layer 1, since code above >> layer 1 will rely on it, yes? >> >> Then anyone could build a layer 1 implementation and substitute it for >> whatever the default/reference is. (I keep thinking that the default should >> not depend on Qt. I will not worry about that for now, so long as someone >> could build a branch that uses a different layer 1 that is fully ALv2 >> licensed.) > > That’s the idea, yes. You can sort of think of it like the POSIX APIs - there > are many different ways to implement these in an operating system, but any > application that conforms to the spec will run on a properly functioning > implementation. Well perhaps POSIX isn’t the best example of that ;) But you > get the idea. > >> A test of the design would need to be demonstration that non-Qt layer 1 are >> not too difficult and that they need not be disadvantaged relative to use of >> a Qt-based layer 1. > > I’ve done a reasonable amount of work in the past with Cocoa on OS X, along > with other GUI toolkits, and I’m currently looking into what would be > involved in doing a native OS X layer for it. Do you have any familiarity > with the Windows API that might be of use in seeing how we could cover that > as well? > > At any rate, I think a Qt version is would be a good “reference > implementation”, so to speak. We can say “here’s an example of how you can > implement an editor using the Corinthia libraries”. It doesn’t necessarily > have to be a front-facing product, but could be marked as sample code. > > Also one thing I forgot to mention in my previous mail was a web-basd version > of the editor. Franz was looking into this a while back, but (correct me if > I’m wrong) had yet to get to the client side of things. Such a version would > be entirely in javascript (including all UI components), and independent of > any C++ code. It would however use DocFormats on the server. So this is > essentially another editing app that’s built on the same foundation (i.e. > DocFormats and the JS editing library). > >> I am unclear how layer 2 and above work independently, because of the stated >> relationship to an XML UI design file. I also don't quite see how a NULL >> version is testable as an editor, so that remains to be figured out as well. > > We can use the Qt XML format for specifying the UI; this doesn’t depend on Qt > itself as we can write our own code to interpret it and build up the > necessary classes. It’s either that or inventing our own format; I think > using the existing one is a sensible approach (at least to start with), as it > will facilitate getting things up and running in the first instance. The XML > files themselves, as I understand, are created by and therefore the copyright > of developers, and are independent of any Qt licensing conditions, in the > same way that OOXML/RTF has nothing to do with Microsoft licenses. > > — > 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) >
