corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Is Qt the right choice ??
Date Wed, 29 Jul 2015 23:01:24 GMT
On 29 July 2015 at 22:39, Dennis E. Hamilton <>

> I don't want to dive into this.  I do want to correct some misconceptions
> of my views.
> Key Point: When an LGPL dependence is made optional, I believe it is not
> that it is optionally removable/replaceable.  My understanding is that it
> is optionally introduceable.  Not optionally removed/replaced.
I get your point, and actually that is exactly how I described it....we
(the project) do NOT supply a layer 1 implementation, we supply a editor
framework WITHOUT layer 1 and layer 0. To make a proof of concept we supply
an EXAMPLE implementation of layer 1 using Qt as well as a NULL
implementation to be able to test the rest.

We do NOT introduce Qt or any other UI kit, we have an API that is neutral
and derived product can implement whatever they want.

> I am concerned that this view of "optional" will be seen as gaming the
> policy on Category X software when it is time to have a Corinthia release
> approved by the Incubator PMC.
Your concern is duly noted, but do you mind that we pass that road blocker
when we come it, and in the meantime develop corinthia !!

Should it really turn out to be a road blocker, we remove that source(s)
and only have the NULL implementation. I volunteer to keep the removed code
in my Git account as a derived product.

Please look at it from the projects POW and not from some might happen
theoretical view (which btw other people say is ok). We need to move as a
project, and if
it really turns out we made a mistake we move some source code, what is
your problem ?

> I don't understand the inference that I don't see an editor as part of
> Corinthia.  There is no basis for that inference.  I thought having an
> editor was the whole point of the Corinthia model and the architectural
> approach.  I have never said anything to the contrary.  I have opinions
> about the building of an editor and I would be very disappointed if
> Corinthia did not provide at least one portably-compilable/-deployable
> editor.

Well it seems you missed something fundamental in Corinthia. DocFormats the
library is the primary part. ALL consumers are nice to have addons.

But having said that, I also want corinthia to have an editor...and would
for sure like your positive input, instead of just hearing what cannot be

Peter already asked you, what is your suggestion ? I ask the same question.

I respect you have opinions, that is perfectly valid, but please try to
offer solutions instead of just telling what cannot be done.

jan i.

>  - Dennis
> PS: I am usually very careful to speak of source-code *releases* and
> binary *distributions.*  If I have not made that clear in speaking of
> binaries, it is a mistake on my part.  For example, when I say "Any
> project-provided binary distribution ..." I am not speaking of an Apache
> Project release, even when those are often produced in company with Apache
> releases.  I thought I had cleared that up in previous conversations
> somewhere.
> PPS: Jar files, a form of binaries, are often provided for Java-based
> Apache Projects.  These days, I would not be surprised to see signed
> libraries also be provided (i.e., DLLs and the ilk).
> -----Original Message-----
> From: jan i []
> Sent: Wednesday, July 29, 2015 10:53
> To:; Dennis Hamilton <
> Subject: Re: Is Qt the right choice ??
> On 29 July 2015 at 17:56, Dennis E. Hamilton <>
> wrote:
> [ ... ]
> > If an editor is to be a release from Corinthia, the challenge is to not
> > have a requirement for Qt, however that is accomplished.  I have not
> > suggested that having an editor be abandoned.  I have suggested that
> having
> > Qt be essential as the UI framework is a deal breaker.
> >
> You did not use the word "abandoned" but there were no doubt that you did
> not see an editor being part of corinthia
> Nobody have ever talked about making Qt essential, the word "optional" has
> always been used, because the implementation will of course be in a way
> that it
> can be replaced. It is however a misunderstand to assume that we have to
> provide multiple implementation for an optional component of the project.

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