On 29 July 2015 at 18:22, Peter Kelly <[email protected]> wrote: > I think this sounds like a good proposal. Separating out the “model” > classes in the editor makes these totally non-dependent on any third-party > code (either directly of via an abstraction layer). And a clear abstraction > (in particular, I envisage a set of base classes/interfaces) allows for > multiple implementations of the underlying “platform”, in a similar manner > to how there are multiple implementations of POSIX. > > The one thing I would add to this is the JS editing library (i.e. what’s > in the Editor); I’m not sure where this would fit in the layered structure > - perhaps as part of Level 3, along with the DocFormats API. A key concern > here is that the APIs are all in javacsript (due to the requirement to run > within the context of a web view), and thus they require a mechanism to > invoke these in a particular web view API. I’ve already got a C++ version > of this API implemented in consumers/corinthia/src/JSInterface.h - these > use several Qt types, but they are all basic things like QString and QRect, > which we can easily replace with our own classes. > good catch, I have it one my note paper, but forgot to include. HTML/CSS/JS is all art of layer 3
> > As far as the layer 1 goes, we should try to minimise the necessary > surface area. With what I started coding up earlier today (which is largely > an experiment which I’m not of how it will evolve right now) I was thinking > of the possibility of having an Objective C/Cocoa (OS X) implementation as > well as a Qt implementation. This would then give us at least one platform > (OS X) on which the app can be built and run while relying only on > functionality already provided by the operating system. A similar thing > could be done for windows. Linux may be a little more tricky, since the > main candidate GUI toolkits seem to be GTK and Qt, though I’m not sure > whether the fact that these are often bundled as parts of distributions > counts as “no external components required” in the same sense as a wrapper > around Cocoa on OS X. > Please remark UI creation (the UI design xml file) is part of layer 1, that at least simplifies the interface a lot. The UI design file should be ALv2 licensed (which is no problem even if it is generated by Qt) > > In UX Write, the parts of the code that were independent of the user > interface I implemented in Objective C using the Foundation class (which is > common to both OS X and iOS); the two have different APIs for the actual > graphical UI stuff. Foundation on Apple platforms is roughly equivalent to > Qt core - it provides things like strings, collection classes, filesystem > interfaces, regular expression support, and all that. A while ago I began > translating these model classes into C++ which I didn’t finish yet, but > will likely come back to that surely. > > To support this, I think I’ll focus initially on the framework classes > necessary for non-UI stuff, as I’ve just put in > consumers/corinthia/src/framework. I’ve got a basic reference counting in > place for use by all classes, and the next step is to implement collection > classes (sets, dictionaries, and lists). I’ll do this while keeping the > existing Qt code in place, and then after that look at abstracting the UI > parts. > > I suggest that once we’ve come to an agreement, we run it past legal to > get their feedback and see if it’s likely to be in compliance with the > rules. > I suggest we do that unofficially to save months of arguments, I have good contacts there and can will do that anyhow. 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) > > > On 29 Jul 2015, at 7:45 pm, jan i <[email protected]> wrote: > > > > Hi > > > > Mark the title, this is not the editor, but a framework so an editor can > be > > made. > > > > Some people use their energy to tell others what cannot be done. I took a > > different route, > > I tasked myself to find a way where we legally (in ASF terms) could use > Qt. > > In order to > > accomplish that task, I have had a couple of discussions with people > > involved in legal, and > > who for sure know more about licensing than I do. > > > > First let me give a couple of reflections they gave me: > > - Apache ONLY makes source releases, therefore binaries "run it" are not > > considered > > - Anybody can take our source and make a binary that can depend on foo, > > that is > > no concern for our release because it is a derived product > > - Qt code cannot be part of the source release, independent if it is > > optional or not > > - Source code using Qt headers and linking with Qt libraries can be > > included in > > the source release, provided they are truly optional (as in example > > code, or 1 of > > n consumers). > > > > Given those restraints I designed a framework (presented below), and just > > to be sure > > I checked it with another project (albeit java) who have similar > problems. > > > > Framework (layers are bottom up) > > > > - Layer 0, Actual graphic implementation > > Operating system libs, Qt runtime, webkit etc. > > These are and cannot be part of our source release > > > > - Layer 1, glue kit and UI design > > This layer has 2 main functions: > > a) It reads a UI design specification (which happens to have Qt XML > format), > > and creates the connection to layer 0 > > b) It contains an API and callbacks to the higher layers. > > > > Remember we only use a very limited part of a full scale UI, which > reduces > > the size > > of this layer dramatically. This is the real critical point, if we cannot > > do a major reduction > > this framework will not work. > > > > We implement an example of this layer, and by accident we use Qt. Other > > developers > > might (and most importantly for license reasons "can do it") implement > e.g. > > webkit. > > > > For test purposes we also implement a NULL version of this layer, thereby > > the editor can > > link without and third party source. > > > > We supply this source as EXAMPLE source, clearly marked as such. > > > > - Layer 2, UI handling > > This layer implements the actual handling, in correspondence with the XML > > UI design file. > > > > - Layer 3, Docformat API > > Something we need to have for the docformats lib. > > > > - Layer 4, Docfomat with filters > > Our main "product". > > > > > > I recommend we develop along this idea/framework. It has several > advantages: > > - we can continue our current development undisturbed > > - we can make releases without problem > > - we do not get sidetracked by having to write our own UI kit. > > > > Should some of us believe we still run into problems when releasing, then > > we can > > simply release the framework without layer 1 and be very pure (more than > > most projects > > actually). In this case "libreCorinthia" would consist of layer 1. > > > > But based on the discussions I have had, I am sure we will not have any > > other problems, > > than those we create ourself. > > > > thoughts? > > rgds > > jan I. > >
