> On 29 Jul 2015, at 10:56 pm, Dennis E. Hamilton <dennis.hamil...@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 pmke...@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)
