Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hello Maxime and Michael,

       Personally (what with time-to-market etc.) I think we should target the
latest android API version - ie. API level 9 - which gives us a lot of
nice (pre-wrapped) C APIs for talking to the system.

Shouldn't we use the lastest API level 11, of Android 3.0 platform?
Details at http://developer.android.com/sdk/android-3.0.html

Regards,
--
Korrawit Pruegsanusak



2011/3/25 Michael Meeks <michael.meeks@novell.com>

Hi Maxime,

On Thu, 2011-03-24 at 23:13 -0400, Maxime Côté wrote:
My name is Maxime Côté, I'm a student from Québec. I'm interested in
participating in the GSOC this year with LibreOffice. To be more
precise I'm interested in porting it to Android as I already have good
knowledge of Java, C++ and a basic knowledge of Android, but I really
want to learn more about it and the same goes for LibreOffice.

       Wonderful ! :-)

Now what I would like to know is, could JNI (Java Native Interface) be
use to interface with the core library

       Well - I assume we should use the Android NDK:

       http://developer.android.com/sdk/ndk/index.html

       Personally (what with time-to-market etc.) I think we should target the
latest android API version - ie. API level 9 - which gives us a lot of
nice (pre-wrapped) C APIs for talking to the system.

       Sadly these seem hard to browse on-line ;-) but if you poke around in
the downloaded SDK from above:

       platforms/android-9/arch-arm/usr/include/android/bitmap.h

       eg. - I guess a start would be digging around and writing a little code
to convert a LibreOffice basebmp/ BitmapDevice into an android
equivalent.

       Hopefully that handles much of the rendering ;-) Then of course we will
need the critical main-loop integration, to hook the Android loop into
VCL's - ie.

       platforms/android-9/arch-arm/usr/include/android/looper.h

       And, I would copy the approach used in the gtk+ integration (with the
glib mainloop g_main_context etc.) work - should be easy to spot
the_underscore_glib_methods vs. TheStdlCaps LibreOffice ones :-) that
code is in vcl/unx/gtk/app/gtkdata.cxx

 or you see something else, what exactly will need to be ported. Also
I would like to know where do I start in LibreOffice's code, where
could I begin hacking to help me understand the code that will need
porting.

       Sure - so I think the first thing to do, is to get a build, and to
submit your first simple easy hack :-) that should give a flavour for
how LibreOffice is to work on cf.

       http://wiki.documentfoundation.org/Development/Easy_Hacks

       Also, in part the build process checks out and downloads the full
source tree, which will take some time.

       The code to start digging at is in vcl/ - in particular:

       vcl/unx/headless/svpgdi*

       which -should- already implement much of the code to do our backend
rendering to bitmaps [ which is what we'll need for Android I think ].
That uses the code in basebmp/ extensively, and may need some
improvement (of course), as well as sub-classing for Android [ and the
web project - hopefully if we get someone for that too, there is some
shared overlap here :-].

       So - I hope those are enough pointers to get started in the research.

       It is certainly an exciting project to consider :-)

       ATB,

               Michael.

--
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot


_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.