corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <pmke...@apache.org>
Subject Re: Proposal editor development framework.
Date Wed, 29 Jul 2015 17:17:18 GMT
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 <pmkelly@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)
> 


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