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 16:22:30 GMT
I think this sounds like a good proposal. Separating out the “model” classes in the editor
makes these totally non-dependent on any third-party code (either directly of via an abstraction
layer). And a clear abstraction (in particular, I envisage a set of base classes/interfaces)
allows for multiple implementations of the underlying “platform”, in a similar manner
to how there are multiple implementations of POSIX.

The one thing I would add to this is the JS editing library (i.e. what’s in the Editor);
I’m not sure where this would fit in the layered structure - perhaps as part of Level 3,
along with the DocFormats API. A key concern here is that the APIs are all in javacsript (due
to the requirement to run within the context of a web view), and thus they require a mechanism
to invoke these in a particular web view API. I’ve already got a C++ version of this API
implemented in consumers/corinthia/src/JSInterface.h - these use several Qt types, but they
are all basic things like QString and QRect, which we can easily replace with our own classes.

As far as the layer 1 goes, we should try to minimise the necessary surface area. With what
I started coding up earlier today (which is largely an experiment which I’m not of how it
will evolve right now) I was thinking of the possibility of having an Objective C/Cocoa (OS
X) implementation as well as a Qt implementation. This would then give us at least one platform
(OS X) on which the app can be built and run while relying only on functionality already provided
by the operating system. A similar thing could be done for windows. Linux may be a little
more tricky, since the main candidate GUI toolkits seem to be GTK and Qt, though I’m not
sure whether the fact that these are often bundled as parts of distributions counts as “no
external components required” in the same sense as a wrapper around Cocoa on OS X.

In UX Write, the parts of the code that were independent of the user interface I implemented
in Objective C using the Foundation class (which is common to both OS X and iOS); the two
have different APIs for the actual graphical UI stuff. Foundation on Apple platforms is roughly
equivalent to Qt core - it provides things like strings, collection classes, filesystem interfaces,
regular expression support, and all that. A while ago I began translating these model classes
into C++ which I didn’t finish yet, but will likely come back to that surely.

To support this, I think I’ll focus initially on the framework classes necessary for non-UI
stuff, as I’ve just put in consumers/corinthia/src/framework. I’ve got a basic reference
counting in place for use by all classes, and the next step is to implement collection classes
(sets, dictionaries, and lists). I’ll do this while keeping the existing Qt code in place,
and then after that look at abstracting the UI parts.

I suggest that once we’ve come to an agreement, we run it past legal to get their feedback
and see if it’s likely to be in compliance with the rules.

—
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 7:45 pm, jan i <jani@apache.org> wrote:
> 
> Hi
> 
> Mark the title, this is not the editor, but a framework so an editor can be
> made.
> 
> Some people use their energy to tell others what cannot be done. I took a
> different route,
> I tasked myself to find a way where we legally (in ASF terms) could use Qt.
> In order to
> accomplish that task, I have had a couple of discussions with people
> involved in legal, and
> who for sure know more about licensing than I do.
> 
> First let me give a couple of reflections they gave me:
> - Apache ONLY makes source releases, therefore binaries "run it" are not
> considered
> - Anybody can take our source and make a binary that can depend on foo,
> that is
>  no concern for our release because it is a derived product
> - Qt code cannot be part of the source release, independent if it is
> optional or not
> - Source code using Qt headers and linking with Qt libraries can be
> included in
>   the source release, provided they are truly optional (as in example
> code, or 1 of
>   n consumers).
> 
> Given those restraints I designed a framework (presented below), and just
> to be sure
> I checked it with another project (albeit java) who have similar problems.
> 
> Framework (layers are bottom up)
> 
> - Layer 0, Actual graphic implementation
> Operating system libs, Qt runtime, webkit etc.
> These are and cannot be part of our source release
> 
> - Layer 1, glue kit and UI design
> This layer has 2 main functions:
> a) It reads a UI design specification (which happens to have Qt XML format),
>    and creates the connection to layer 0
> b) It contains an API and callbacks to the higher layers.
> 
> Remember we only use a very limited part of a full scale UI, which reduces
> the size
> of this layer dramatically. This is the real critical point, if we cannot
> do a major reduction
> this framework will not work.
> 
> We implement an example of this layer, and by accident we use Qt. Other
> developers
> might (and most importantly for license reasons "can do it") implement e.g.
> webkit.
> 
> For test purposes we also implement a NULL version of this layer, thereby
> the editor can
> link without and third party source.
> 
> We supply this source as EXAMPLE source, clearly marked as such.
> 
> - Layer 2, UI handling
> This layer implements the actual handling, in correspondence with the XML
> UI design file.
> 
> - Layer 3, Docformat API
> Something we need to have for the docformats lib.
> 
> - Layer 4, Docfomat with filters
> Our main "product".
> 
> 
> I recommend we develop along this idea/framework. It has several advantages:
> - we can continue our current development undisturbed
> - we can make releases without problem
> - we do not get sidetracked by having to write our own UI kit.
> 
> Should some of us believe we still run into problems when releasing, then
> we can
> simply release the framework without layer 1 and be very pure (more than
> most projects
> actually). In this case "libreCorinthia" would consist of layer 1.
> 
> But based on the discussions I have had, I am sure we will not have any
> other problems,
> than those we create ourself.
> 
> thoughts?
> rgds
> jan I.


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