corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: Proposal editor development framework.
Date Wed, 29 Jul 2015 18:00:46 GMT
On 29 July 2015 at 19:17, Peter Kelly <pmkelly@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 <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