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. > > [ ... ] > >
