openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <>
Subject Re: Why is it so hard to make a Java program appear native?
Date Tue, 12 Aug 2014 07:34:00 GMT
On 11/08/14 20:25, jan i wrote:
> On 11 August 2014 20:12, Peter Kelly <> wrote:
>> On 11 Aug 2014, at 3:42 pm, Andre Fischer <> 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.


> 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
>> PGP key:
>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message