Just put the proposal in its pure form in wiki: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61309925
let keep the discussion in here, and make the actual changes in the wiki rgds jan i. On 29 July 2015 at 20:07, jan i <j...@apache.org> wrote: > > > On 29 July 2015 at 17:56, 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? >> > Correct, you can say the API of layer 1 is the ALv2 interface....below > might or might not be ALv2. > >> >> 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.) >> > If you keep thinking that, then please come with some alternatives ? Peter > and I could not find any. > > but it is correct that anyone could build that. My suggestion is clear we > build a Qt version (as an EXAMPLE) and a test version, where the buttons > etc are activated from > e.g. config files. > >> >> 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. >> > why the word "need". Why do you care how difficult it is ? that is not our > concern, our concern is solely to show that we have a clear separation > between the Qt > example implementation and the rest of corinthia. > > The licenses does not care about how difficult things are, or if we proof > the interface. > > >> >> 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. >> > the XML UI design file is ALv2 licensed, so no problem for layer 2. > > the NULL is a standard way to test UI applications, when you do not have > people sitting in front of the screen. You replace each API call with a > test module, that e.g. read interactions from a file. > >> >> Is this in line with the intention for this framework? >> > pretty much. > > rgds > jan i. > >> >> - Dennis >> >> -----Original Message----- >> From: jan i [mailto:j...@apache.org] >> Sent: Wednesday, July 29, 2015 05:45 >> To: dev@corinthia.incubator.apache.org >> Subject: Proposal editor development framework. >> >> [ ... ] >> I designed a framework (presented below), and just to be sureI 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. >> >> [ ... ] >> >> >
