On 29 July 2015 at 19:17, Peter Kelly <pmke...@apache.org> wrote: > 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. > +1
> > 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. > me too, which is why I made the above suggestion. > > 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. > +1 > > I think Jan’s proposal provides a good solution, and hope we can move > forward with that. > thanks > > — > 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) > > > >
