corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Proposal editor development framework.
Date Wed, 29 Jul 2015 18:07:18 GMT
On 29 July 2015 at 17:56, Dennis E. Hamilton <>

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

jan i.

>  - Dennis
> -----Original Message-----
> From: jan i []
> Sent: Wednesday, July 29, 2015 05:45
> To:
> 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.
> [ ... ]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message