You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Peter Kelly <ke...@gmail.com> on 2014/08/11 09:59:40 UTC
Why is it so hard to make a Java program appear native?
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).
Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI?
--
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)
Re: Why is it so hard to make a Java program appear native?
Posted by jan i <ja...@apache.org>.
On 11 August 2014 09:59, Peter Kelly <ke...@gmail.com> 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).
>
> Question: To what extent is the OO UI frontend code separate from the
> backend editing, file format handling, and rendering code? I'm thinking in
> particular here of mobile - which demands a completely different approach
> to user experience design than desktop. Could OO conceivably be adapted to
> mobile by replacing its UI?
>
If you look at especially module svl, you will see how we use a meta
language to define the UI items. We can change what the UI language
generates pretty easy, and it is also pretty easy to change the layout
itself.
However the semantic, the editing is buried deep in the process model of
AOO, there are no clear seperation between functionality and
representation, as you would do in a modern program.
rgds
jan I.
>
> --
> Dr. Peter M. Kelly
> Founder, UX Productivity
> peter@uxproductivity.co <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)
>
>
Re: Why is it so hard to make a Java program appear native?
Posted by Andre Fischer <aw...@gmail.com>.
On 11.08.2014 20:25, jan i wrote:
> On 11 August 2014 20:12, Peter Kelly <ke...@gmail.com> wrote:
>
>> On 11 Aug 2014, at 3:42 pm, Andre Fischer <aw...@gmail.com> wrote:
>>
>> Question: To what extent is the OO UI frontend code separate from the
>> backend editing, file format handling, and rendering code? I'm thinking in
>> particular here of mobile - which demands a completely different approach
>> to user experience design than desktop. Could OO conceivably be adapted to
>> mobile by replacing its UI?
>>
>>
>> Conceivably? Probably. But the problem is in the details. AOO has put a
>> lot of effort into separating UI from model and from underlying frameworks.
>> For example you can use the UNO API to access a lot of functionality
>> without bothering with the UI. You can run AOO headless (without any UI),
>> and you can run AOO on several different GUI frameworks (Windows, Mac OSX,
>> Linux with a mixture of X11 and Gnome/KDE). The problem is that there are
>> dependencies between UI and model or framework. Most of them not designed
>> but "grown" because of convenience or laziness.
>>
>> So, if you wanted to port AOO to another window system with basically the
>> same UI as today you would probably port VCL (the UI abstraction layer of
>> AOO). That would involve a lot of cursing but it is doable (it has been
>> done for OSX). For a mobile device you probably don't want the same UI but
>> something that can be operated with larger input devices then the typical
>> mouse pointer (i.e. fingers). One way to do that would be to write the GUI
>> from scratch and use the UNO API as a backend. I am not sure that that is
>> possible though. If you drop VCL, you don't have SFX2 with its view shells
>> (a mix of view and controller) or slots (a mix of remote procedure calls
>> and value passing). That means that a) a lot of functionality has to be
>> rewritten (not necessarily a bad thing when you consider the quality of the
>> existing implementation) and b) that that might break the UNO API (which
>> would be bad).
>>
>> Maybe we need an experiment to see what is possible?
>>
>>
>> I'll have a look into the code to understand the architecture better and
>> then hopefully be able to contribute some more informed thoughts about it.
>>
>> From what you've described, it sounds like there is a dependence from the
>> OO codebase to VCL, is that correct? If my initial understanding it is
>> correct, it sounds like it would be possible to port this to iOS/Android
>> with sufficient effort, though I think that writing a from-scratch UI would
>> be needed, as you suggested. That is, largely to address the much smaller
>> screen real estate and touch controls, and the types of UI layouts that are
>> common on phones/tablets.
>>
>> The fact that OO can run in headless mode sounds promising, since the
>> ability to access much of the functionality without any UI implies that a
>> totally different UI could be put in place on top of this.
>>
> I just wonder if the effort pays off. AOO contains tons of very good ideas
> (proven over time) but equally old code. Juergen have multiple times argued
> that it might be more efficient, to pick the ideas and write new code with
> modern tools, i tend to agree to that.
>
> Please remember AOO is a good mixture of C/C++/Java/Python/Perl (I might
> have missed something), whereas a new codebase would be simpler.
>
> We might be able to avoid the big bang, by using AOO in headless mode and
> change to new code part by part.
>
> But I agree with andre that an experiment, just moving a little part would
> be a nice proof.
Please don't get me wrong. I did not mean to advocate porting the
existing code base to iOS or Android. Only that if one where to try it,
then start with an experiment to avoid nasty surprises at a later stage.
If we would want to go towards mobile I would prefer a rewrite. We
could certainly salvage one or the other idea but I believe that we
should focus more on the mistakes that where made and try to avoid
them. Remember, AOO is based on a "design" that was made 15 to 20 years
ago. A lot of bug fixes where made and a lot of features added in the
meantime. But many limitations (like VCL providing rendering of UI
controls, behavior of them, event loop and some other things, or SFX2
with its slots, items and view shells) still exist.
Therefore I would start fresh with a limited feature set but with a
better design than before.
-Andre
>
> just my 2ct.
> rgds
> jan I.
>
>
>
>> --
>> 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)
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Why is it so hard to make a Java program appear native?
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 11/08/14 20:25, jan i wrote:
> On 11 August 2014 20:12, Peter Kelly <ke...@gmail.com> wrote:
>
>> On 11 Aug 2014, at 3:42 pm, Andre Fischer <aw...@gmail.com> wrote:
>>
>> Question: To what extent is the OO UI frontend code separate from the
>> backend editing, file format handling, and rendering code? I'm thinking in
>> particular here of mobile - which demands a completely different approach
>> to user experience design than desktop. Could OO conceivably be adapted to
>> mobile by replacing its UI?
>>
>>
>> Conceivably? Probably. But the problem is in the details. AOO has put a
>> lot of effort into separating UI from model and from underlying frameworks.
>> For example you can use the UNO API to access a lot of functionality
>> without bothering with the UI. You can run AOO headless (without any UI),
>> and you can run AOO on several different GUI frameworks (Windows, Mac OSX,
>> Linux with a mixture of X11 and Gnome/KDE). The problem is that there are
>> dependencies between UI and model or framework. Most of them not designed
>> but "grown" because of convenience or laziness.
>>
>> So, if you wanted to port AOO to another window system with basically the
>> same UI as today you would probably port VCL (the UI abstraction layer of
>> AOO). That would involve a lot of cursing but it is doable (it has been
>> done for OSX). For a mobile device you probably don't want the same UI but
>> something that can be operated with larger input devices then the typical
>> mouse pointer (i.e. fingers). One way to do that would be to write the GUI
>> from scratch and use the UNO API as a backend. I am not sure that that is
>> possible though. If you drop VCL, you don't have SFX2 with its view shells
>> (a mix of view and controller) or slots (a mix of remote procedure calls
>> and value passing). That means that a) a lot of functionality has to be
>> rewritten (not necessarily a bad thing when you consider the quality of the
>> existing implementation) and b) that that might break the UNO API (which
>> would be bad).
>>
>> Maybe we need an experiment to see what is possible?
>>
>>
>> I'll have a look into the code to understand the architecture better and
>> then hopefully be able to contribute some more informed thoughts about it.
>>
>> From what you've described, it sounds like there is a dependence from the
>> OO codebase to VCL, is that correct? If my initial understanding it is
>> correct, it sounds like it would be possible to port this to iOS/Android
>> with sufficient effort, though I think that writing a from-scratch UI would
>> be needed, as you suggested. That is, largely to address the much smaller
>> screen real estate and touch controls, and the types of UI layouts that are
>> common on phones/tablets.
>>
>> The fact that OO can run in headless mode sounds promising, since the
>> ability to access much of the functionality without any UI implies that a
>> totally different UI could be put in place on top of this.
>>
>
> I just wonder if the effort pays off. AOO contains tons of very good ideas
> (proven over time) but equally old code. Juergen have multiple times argued
> that it might be more efficient, to pick the ideas and write new code with
> modern tools, i tend to agree to that.
>
> Please remember AOO is a good mixture of C/C++/Java/Python/Perl (I might
> have missed something), whereas a new codebase would be simpler.
We can say that the office is using C++ and Java. Python is used for
mail merge only (if I remember correct) and is supported as scripting
language. Perl is used in the build environment only and not in the office.
Juergen
>
> We might be able to avoid the big bang, by using AOO in headless mode and
> change to new code part by part.
>
> But I agree with andre that an experiment, just moving a little part would
> be a nice proof.
>
> just my 2ct.
> rgds
> jan I.
>
>
>
>>
>> --
>> 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)
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Why is it so hard to make a Java program appear native?
Posted by jan i <ja...@apache.org>.
On 11 August 2014 20:12, Peter Kelly <ke...@gmail.com> wrote:
> On 11 Aug 2014, at 3:42 pm, Andre Fischer <aw...@gmail.com> wrote:
>
> Question: To what extent is the OO UI frontend code separate from the
> backend editing, file format handling, and rendering code? I'm thinking in
> particular here of mobile - which demands a completely different approach
> to user experience design than desktop. Could OO conceivably be adapted to
> mobile by replacing its UI?
>
>
> Conceivably? Probably. But the problem is in the details. AOO has put a
> lot of effort into separating UI from model and from underlying frameworks.
> For example you can use the UNO API to access a lot of functionality
> without bothering with the UI. You can run AOO headless (without any UI),
> and you can run AOO on several different GUI frameworks (Windows, Mac OSX,
> Linux with a mixture of X11 and Gnome/KDE). The problem is that there are
> dependencies between UI and model or framework. Most of them not designed
> but "grown" because of convenience or laziness.
>
> So, if you wanted to port AOO to another window system with basically the
> same UI as today you would probably port VCL (the UI abstraction layer of
> AOO). That would involve a lot of cursing but it is doable (it has been
> done for OSX). For a mobile device you probably don't want the same UI but
> something that can be operated with larger input devices then the typical
> mouse pointer (i.e. fingers). One way to do that would be to write the GUI
> from scratch and use the UNO API as a backend. I am not sure that that is
> possible though. If you drop VCL, you don't have SFX2 with its view shells
> (a mix of view and controller) or slots (a mix of remote procedure calls
> and value passing). That means that a) a lot of functionality has to be
> rewritten (not necessarily a bad thing when you consider the quality of the
> existing implementation) and b) that that might break the UNO API (which
> would be bad).
>
> Maybe we need an experiment to see what is possible?
>
>
> I'll have a look into the code to understand the architecture better and
> then hopefully be able to contribute some more informed thoughts about it.
>
> From what you've described, it sounds like there is a dependence from the
> OO codebase to VCL, is that correct? If my initial understanding it is
> correct, it sounds like it would be possible to port this to iOS/Android
> with sufficient effort, though I think that writing a from-scratch UI would
> be needed, as you suggested. That is, largely to address the much smaller
> screen real estate and touch controls, and the types of UI layouts that are
> common on phones/tablets.
>
> The fact that OO can run in headless mode sounds promising, since the
> ability to access much of the functionality without any UI implies that a
> totally different UI could be put in place on top of this.
>
I just wonder if the effort pays off. AOO contains tons of very good ideas
(proven over time) but equally old code. Juergen have multiple times argued
that it might be more efficient, to pick the ideas and write new code with
modern tools, i tend to agree to that.
Please remember AOO is a good mixture of C/C++/Java/Python/Perl (I might
have missed something), whereas a new codebase would be simpler.
We might be able to avoid the big bang, by using AOO in headless mode and
change to new code part by part.
But I agree with andre that an experiment, just moving a little part would
be a nice proof.
just my 2ct.
rgds
jan I.
>
> --
> 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)
>
>
Re: Why is it so hard to make a Java program appear native?
Posted by Peter Kelly <ke...@gmail.com>.
On 11 Aug 2014, at 3:42 pm, Andre Fischer <aw...@gmail.com> wrote:
>> Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI?
>
> Conceivably? Probably. But the problem is in the details. AOO has put a lot of effort into separating UI from model and from underlying frameworks. For example you can use the UNO API to access a lot of functionality without bothering with the UI. You can run AOO headless (without any UI), and you can run AOO on several different GUI frameworks (Windows, Mac OSX, Linux with a mixture of X11 and Gnome/KDE). The problem is that there are dependencies between UI and model or framework. Most of them not designed but "grown" because of convenience or laziness.
>
> So, if you wanted to port AOO to another window system with basically the same UI as today you would probably port VCL (the UI abstraction layer of AOO). That would involve a lot of cursing but it is doable (it has been done for OSX). For a mobile device you probably don't want the same UI but something that can be operated with larger input devices then the typical mouse pointer (i.e. fingers). One way to do that would be to write the GUI from scratch and use the UNO API as a backend. I am not sure that that is possible though. If you drop VCL, you don't have SFX2 with its view shells (a mix of view and controller) or slots (a mix of remote procedure calls and value passing). That means that a) a lot of functionality has to be rewritten (not necessarily a bad thing when you consider the quality of the existing implementation) and b) that that might break the UNO API (which would be bad).
>
> Maybe we need an experiment to see what is possible?
I'll have a look into the code to understand the architecture better and then hopefully be able to contribute some more informed thoughts about it.
From what you've described, it sounds like there is a dependence from the OO codebase to VCL, is that correct? If my initial understanding it is correct, it sounds like it would be possible to port this to iOS/Android with sufficient effort, though I think that writing a from-scratch UI would be needed, as you suggested. That is, largely to address the much smaller screen real estate and touch controls, and the types of UI layouts that are common on phones/tablets.
The fact that OO can run in headless mode sounds promising, since the ability to access much of the functionality without any UI implies that a totally different UI could be put in place on top of this.
--
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)
Re: Why is it so hard to make a Java program appear native?
Posted by Andre Fischer <aw...@gmail.com>.
On 11.08.2014 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/
I know that the answer to this is not really important, but just in
case. This gives you not 100% native rendering but maybe 80%:
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>
> (and yes I realise OO doesn't use Java for it's UI, but the points
> raised apply to all cross-platform UI toolkits).
>
> Question: To what extent is the OO UI frontend code separate from the
> backend editing, file format handling, and rendering code? I'm
> thinking in particular here of mobile - which demands a completely
> different approach to user experience design than desktop. Could OO
> conceivably be adapted to mobile by replacing its UI?
Conceivably? Probably. But the problem is in the details. AOO has put
a lot of effort into separating UI from model and from underlying
frameworks. For example you can use the UNO API to access a lot of
functionality without bothering with the UI. You can run AOO headless
(without any UI), and you can run AOO on several different GUI
frameworks (Windows, Mac OSX, Linux with a mixture of X11 and
Gnome/KDE). The problem is that there are dependencies between UI and
model or framework. Most of them not designed but "grown" because of
convenience or laziness.
So, if you wanted to port AOO to another window system with basically
the same UI as today you would probably port VCL (the UI abstraction
layer of AOO). That would involve a lot of cursing but it is doable (it
has been done for OSX). For a mobile device you probably don't want the
same UI but something that can be operated with larger input devices
then the typical mouse pointer (i.e. fingers). One way to do that would
be to write the GUI from scratch and use the UNO API as a backend. I
am not sure that that is possible though. If you drop VCL, you don't
have SFX2 with its view shells (a mix of view and controller) or slots
(a mix of remote procedure calls and value passing). That means that a)
a lot of functionality has to be rewritten (not necessarily a bad thing
when you consider the quality of the existing implementation) and b)
that that might break the UNO API (which would be bad).
Maybe we need an experiment to see what is possible?
Regards,
Andre
>
> --
> Dr. Peter M. Kelly
> Founder, UX Productivity
> peter@uxproductivity.com <ma...@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)
>
Re: Why is it so hard to make a Java program appear native?
Posted by Peter Kelly <ke...@gmail.com>.
On 11 Aug 2014, at 3:14 pm, Jürgen Schmidt <jo...@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)
Re: Why is it so hard to make a Java program appear native?
Posted by Jürgen Schmidt <jo...@gmail.com>.
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.
>
> Question: To what extent is the OO UI frontend code separate from the
> backend editing, file format handling, and rendering code? I'm thinking
> in particular here of mobile - which demands a completely different
> approach to user experience design than desktop. Could OO conceivably be
> adapted to mobile by replacing its UI?
The answer is probably yes but the effort is of course very high. The
reason is that it is not so clearly separated as it should be. VCL is
used deeply in the writer core as far as I know.
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.
Probably others can give more details
Juergen
>
> --
> Dr. Peter M. Kelly
> Founder, UX Productivity
> peter@uxproductivity.com <ma...@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)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org