On 11 Aug 2014, at 3:14 pm, Jürgen Schmidt <jogischm...@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 pe...@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)
signature.asc
Description: Message signed with OpenPGP using GPGMail
