openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer <awf....@gmail.com>
Subject Re: Why is it so hard to make a Java program appear native?
Date Mon, 11 Aug 2014 08:42:02 GMT
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 <mailto: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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message