corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: Proposal editor development framework.
Date Wed, 29 Jul 2015 16:31:24 GMT
> On 29 Jul 2015, at 10:56 pm, Dennis E. Hamilton <> 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

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

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