openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <kelly...@gmail.com>
Subject Re: Why is it so hard to make a Java program appear native?
Date Mon, 11 Aug 2014 18:26:45 GMT
On 11 Aug 2014, at 3:14 pm, J├╝rgen Schmidt <jogischmidt@gmail.com> wrote:

> On 11/08/14 09:59, Peter Kelly wrote:
>> An interesting discussion I came across today:
>> 
>> http://arstechnica.com/information-technology/2014/08/why-is-it-so-hard-to-make-a-java-program-appear-native/
>> 
>> (and yes I realise OO doesn't use Java for it's UI, but the points
>> raised apply to all cross-platform UI toolkits).
> 
> indeed and as far as I know it was always a big challenge to make it
> working on all supported platforms. Well I am no expert in this area but
> we have the VCL layer (visual class library) with an API used all over
> in the code and certain backends wrapping the API to native calls (where
> necessary) on the different platforms.

I think there's two aspects to this. One is the APIs for drawing things - bitmaps, shapes,
text, etc. and the other is the APIs for working with widges.

When I ported XeTeX to iOS I had to do the former; the old code used some APIs (AAT, Apple
Advanced Typography)  that are now deprecated on OS X and completely absent from iOS. On both
platforms (which are much the same), this is CoreGraphics, CoreImage, and CoreText.

The widget side of things is a more complex issue to address. Looking at the GSL/VCL description
at https://www.openoffice.org/gsl/, there's APIs for things like a file picker, which up to
and including iOS 7 aren't present on the platform; though thankfully this is introduced in
iOS 8.

> For the support of mobile I believe a much better separation would be
> necessary to have the core independent of the UI or at least have the UI
> part accessed via a clean API that the UI part can be easier exchanged.

I think it would be useful to have a clear separation between the drawing APIs and the widgets.
Basically I see it as a stack, where you have the following (higher-numbered layers depending
on lower-numbered).

4. Application-specific UI
3. Widget toolkit
2. Editing & rendering code
1. Drawing APIs

To maximise portability, it would be useful to take just layers 1 and 2, and then be able
to use whatever widget toolkit is appropriate for the platform (typically, the native one).
So on iOS for example, layer 1 is covered by the three libraries I mentioned above, and layer
3 is provided by UIKit (aka Cocoa Touch). Significantly, the layer 1 libraries are (almost)
identical across iOS and OS X, and are exposed purely via C. Layer 3 differs between the two;
OS X has an API called AppKit (aka Cocoa) in place of UIKit/Cocoa Touch.

So with VCL, would an Apple-like separation of 1 and 3 be possible?

--
Dr. Peter M. Kelly
Founder, UX Productivity
peter@uxproductivity.com
http://www.uxproductivity.com/
http://www.kellypmk.net/

PGP key: http://www.kellypmk.net/pgp-key
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)


Mime
View raw message