You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by jan i <ja...@apache.org> on 2015/07/29 14:45:26 UTC
Proposal editor development framework.
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.
Re: Proposal editor development framework.
Posted by jan i <ja...@apache.org>.
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 <ja...@apache.org> wrote:
>
>
> On 29 July 2015 at 17:56, Dennis E. Hamilton <de...@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:jani@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.
>>
>> [ ... ]
>>
>>
>
Re: Proposal editor development framework.
Posted by jan i <ja...@apache.org>.
On 29 July 2015 at 17:56, Dennis E. Hamilton <de...@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:jani@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.
>
> [ ... ]
>
>
Re: Proposal editor development framework.
Posted by Peter Kelly <pm...@apache.org>.
> On 30 Jul 2015, at 3:39 am, Dennis E. Hamilton <de...@acm.org> wrote:
>
> While Corinthia is in the incubator, all releases, once approved by the project, must be reviewed and approved by the Incubator PMC.
>
> For the first release there will be great scrutiny on IP provenance in the source code. It is then expected that a mechanism to continue having clean IP provenance will be sustained throughout incubation and into the future whenever Corinthia becomes a Top-Level Apache Project (TLP). This scrutiny also includes dealing with the presence of third party software, or dependence on third-party software, essential to use of a built version of the software. (There is no problem with tools used to build the software, so long as they don't impose license conditions on what is built.)
I don’t anticipate including the desktop app in the first release - I think the main (if not exclusive) focus should be on DocFormats, given that’s had the most attention from participants to date.
And if my understanding of the rules is correct, there is no problem with us including sample code that demonstrates one way in which someone might construct an editor, *even if* that was entirely dependent on Qt (which it won’t be, as outlined int he framework).
> Part of the reason for incubation is to provide a learning curve for the new project with respect to how ASF projects operate and the basic principles and, in some cases, specific policies.
>
> It is not at all unusual that there will be some deconstruction of natural inclinations and suppositions when the constraints on being an Apache Project are encountered and then dealt with.
My natural inclination is to find solutions to problems so that the goals of whatever projects I’m working on can be achieved. This is one such case, and what myself and others in this discussion are doing is trying to move forward, rather than just give up at the first hurdle. I’m not going to have that particular natural inclination being “deconstructed” or “dealt with”. And I’m not going to abandon Apache because of this, because as has been explained elsewhere, there are ways in which we can achieve our goals while complying with the rules.
—
Dr Peter M. Kelly
pmkelly@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)
Re: Proposal editor development framework.
Posted by jan i <ja...@apache.org>.
On 29 July 2015 at 22:39, Dennis E. Hamilton <de...@acm.org>
wrote:
> While Corinthia is in the incubator, all releases, once approved by the
> project, must be reviewed and approved by the Incubator PMC.
>
correct.
>
> For the first release there will be great scrutiny on IP provenance in the
> source code. It is then expected that a mechanism to continue having clean
> IP provenance will be sustained throughout incubation and into the future
> whenever Corinthia becomes a Top-Level Apache Project (TLP). This scrutiny
> also includes dealing with the presence of third party software, or
> dependence on third-party software, essential to use of a built version of
> the software. (There is no problem with tools used to build the software,
> so long as they don't impose license conditions on what is built.)
>
That is new to me (as IPMC member). We did do a IP clearance earlier, and
passed. Of course EVERY release is controlled of which libraries we use.
For the first release, I anticipate (but being only one of many PPMC I
cannot say) that we will not release all of trunk, I aim at releasing only
docFormats, which sort of makes your point a bit strange.
>
> Part of the reason for incubation is to provide a learning curve for the
> new project with respect to how ASF projects operate and the basic
> principles and, in some cases, specific policies.
>
correct.
>
> It is not at all unusual that there will be some deconstruction of natural
> inclinations and suppositions when the constraints on being an Apache
> Project are encountered and then dealt with.
>
My english cannot cope with what you imply here.
>
> - Dennis
>
> PS: There is not scripture or holy writ anywhere that compels successful
> open-source projects to be Apache Projects.
>
huh?
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Wednesday, July 29, 2015 10:17
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Proposal editor development framework.
>
> 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.
>
> 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.
> [ ... ]
>
>
>
Re: Proposal editor development framework.
Posted by Dave Fisher <da...@comcast.net>.
(1) When the first release of Corinthia is reviewed by the IPMC we need to make certain we have our source and dependencies properly explained. Regardless it may cause debate from a committee of 100.
I see no concerns that this won't be done properly.
(2) I think if our features are both pluggable and built in then we will have created a very cool product from our project.
There is an Apache project worth looking at - Apache Flex. Work there has been proceeding towards FlexJS and HTML5.
Regards,
Dave
Sent from my iPhone
> On Jul 29, 2015, at 1:39 PM, Dennis E. Hamilton <de...@acm.org> wrote:
>
> While Corinthia is in the incubator, all releases, once approved by the project, must be reviewed and approved by the Incubator PMC.
>
> For the first release there will be great scrutiny on IP provenance in the source code. It is then expected that a mechanism to continue having clean IP provenance will be sustained throughout incubation and into the future whenever Corinthia becomes a Top-Level Apache Project (TLP). This scrutiny also includes dealing with the presence of third party software, or dependence on third-party software, essential to use of a built version of the software. (There is no problem with tools used to build the software, so long as they don't impose license conditions on what is built.)
>
> Part of the reason for incubation is to provide a learning curve for the new project with respect to how ASF projects operate and the basic principles and, in some cases, specific policies.
>
> It is not at all unusual that there will be some deconstruction of natural inclinations and suppositions when the constraints on being an Apache Project are encountered and then dealt with.
>
> - Dennis
>
> PS: There is not scripture or holy writ anywhere that compels successful open-source projects to be Apache Projects.
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Wednesday, July 29, 2015 10:17
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Proposal editor development framework.
>
> 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.
>
> 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. [ ... ]
>
>
RE: Proposal editor development framework.
Posted by "Dennis E. Hamilton" <de...@acm.org>.
While Corinthia is in the incubator, all releases, once approved by the project, must be reviewed and approved by the Incubator PMC.
For the first release there will be great scrutiny on IP provenance in the source code. It is then expected that a mechanism to continue having clean IP provenance will be sustained throughout incubation and into the future whenever Corinthia becomes a Top-Level Apache Project (TLP). This scrutiny also includes dealing with the presence of third party software, or dependence on third-party software, essential to use of a built version of the software. (There is no problem with tools used to build the software, so long as they don't impose license conditions on what is built.)
Part of the reason for incubation is to provide a learning curve for the new project with respect to how ASF projects operate and the basic principles and, in some cases, specific policies.
It is not at all unusual that there will be some deconstruction of natural inclinations and suppositions when the constraints on being an Apache Project are encountered and then dealt with.
- Dennis
PS: There is not scripture or holy writ anywhere that compels successful open-source projects to be Apache Projects.
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Wednesday, July 29, 2015 10:17
To: dev@corinthia.incubator.apache.org
Subject: Re: Proposal editor development framework.
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.
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. [ ... ]
Re: Proposal editor development framework.
Posted by jan i <ja...@apache.org>.
On 29 July 2015 at 19:17, Peter Kelly <pm...@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
> pmkelly@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 <pm...@apache.org> wrote:
> >
> >> On 29 Jul 2015, at 10:56 pm, Dennis E. Hamilton <
> dennis.hamilton@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
> > pmkelly@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)
> >
>
>
Re: Proposal editor development framework.
Posted by Peter Kelly <pm...@apache.org>.
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.
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.
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.
I think Jan’s proposal provides a good solution, and hope we can move forward with that.
—
Dr Peter M. Kelly
pmkelly@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 <pm...@apache.org> wrote:
>
>> On 29 Jul 2015, at 10:56 pm, Dennis E. Hamilton <de...@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
> pmkelly@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)
>
Re: Proposal editor development framework.
Posted by Peter Kelly <pm...@apache.org>.
> On 29 Jul 2015, at 10:56 pm, Dennis E. Hamilton <de...@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
pmkelly@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)
RE: Proposal editor development framework.
Posted by "Dennis E. Hamilton" <de...@acm.org>.
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.)
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 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.
Is this in line with the intention for this framework?
- Dennis
-----Original Message-----
From: jan i [mailto:jani@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.
[ ... ]
Re: Proposal editor development framework.
Posted by jan i <ja...@apache.org>.
On 29 July 2015 at 18:22, Peter Kelly <pm...@apache.org> 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
> pmkelly@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 7:45 pm, jan i <ja...@apache.org> 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.
>
>
Re: Proposal editor development framework.
Posted by Peter Kelly <pm...@apache.org>.
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.
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.
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.
—
Dr Peter M. Kelly
pmkelly@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 7:45 pm, jan i <ja...@apache.org> 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.