LibreOfficeLight / iOS

[jan iversen]

Please do not misunderstand my comments, I am open to any enhancements
especially on the linking process of the app...but I would like to see a
benefit of the changes.

rgds
jan I.

On 29 December 2017 at 09:36, Jon Nermut <jon.nermut at gmail.com> wrote:

> Thanks for the reply Jan.
>
> My main point about BridgeLOKit was that you don't really need to add
> another FFI on top of the existing LibreOfficeKit.h FFI.
> Swift can import and use the existing _LibreOfficeKit /
> _LibreOfficeKitClass and _LibreOfficeKitDocument /
> _LibreOfficeKitDocumentClass structs and their functions just fine. Swift
> actually has excellent C integration (and non-existent C++). To do so I
> just added:
>
> #define LOK_USE_UNSTABLE_API 1
>
> #import "../../../include/LibreOfficeKit/LibreOfficeKit.h"
>
> Into lokit-Bridging-Header.h, and the struct types mentioned above are
> usable directly within Swift without anymore C needed
> - LibreOfficeKitWrapper.swift is an example of using the functions from
> these structs directly, and wrapping the C struct pointers in swift
> classes, making them encapsulated and easier to use.
> The exception being the lok_init functions, which need to be included and
> called from within a C file.
>
> >> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but
> I will need to check that.
>
> Oh, I couldn't find it... where is it supposed to be generated to? I
> changed the the path settings in LibreOfficeLight.xcodeproj like this:
>
> - LIBRARY_SEARCH_PATHS = /Users/jani/LO/core/ios/generated/;
> + LIBRARY_SEARCH_PATHS = $PROJECT_DIR/../generated/;
>
> I tried a few settings on the linking, couldn't make it better. Need to
> find a way to work out what its doing... I'll have more of a play.
> My suggestion is to split the C integration, and it's swift wrappers, into
> a separate Framework project, and let that produce a dylib.
> That should link pretty much instantly to the app, and should only rebuild
> and link when the libreoffice lib changes, or the code in the Framework
>
> Cheers
>
> Jon
>
>
> On Fri, Dec 29, 2017 at 6:38 PM, jan iversen <jani at apache.org> wrote:
>
>> Hi
>>
>> adding dev list to reply, so that others might benefit from the info.
>>
>> Hope you don't mind the unsolicited email, I figured you were the guy to
>>> talk to about this from the git commits.
>>>
>> I am working actively on creating a version of LO for the iPad.
>>
>> So I got it compiling via lode, with just a couple of hitches (had to
>>> install libassuan, had to make sure to use the make out of lode, and there
>>> is a hard coded LIBRARY_SEARCH_PATH to /Users/jani/... in the ios project
>>> file)
>>>
>> I do not understand why you had to install extra libraries. I work on
>> high sierra with xcode 9 and have not installed that library.
>>
>> The LIBRARY_SEARCH_PATH should be overwritten by the xcconfig file, but I
>> will need to check that.
>>
>> There are 2 projects, but I assume you talk about the kit project?
>>
>>>
>>> 1. The app doesnt actually attempt to render yet? Were you planning on
>>> using CATiledLayer for that? I've used it a couple of times (for PDFs)...
>>> it's fun
>>>
>>
>> No it doesn’t. As you probably have seen the render function is near
>> empty, I am strugling to find out what the tiled calls returns and how to
>> use that in the swift app.
>>
>> 2. The static lib, and the compiled app, are pretty fat. (At least in
>>> debug for the simulator - ~400mb, I havent tried the release build yet).
>>> Too fat to embed in my app, it would have to be a separate app. Any insight
>>> as to whether this could ever be cut down to a reasonable size?
>>>
>> Well is it actually quite reduced. LO is simply big.
>>
>> 3. The link time on the app is outrageously slow at the moment - at least
>>> on my macbook pro - I guess this is related to the size and number of
>>> symbols in the static lib. That's what the dummy.c file is all about? Needs
>>> to be quarantined from the app somehow.  Perhaps by keeping it in a
>>> Framework project? Or cutting down its size. I was too scared to turn on
>>> LTO...
>>>
>> The link time is my biggest problem, linking the kit is a fraction of
>> linking the app, and It seems to be the swift interface that is the problem.
>>
>> dummy.c is to link without the kit, and it is automatically quarantined,
>> look in build phases, where you will see it is not being compiled.
>>
>> 4. Just wondering the reasoning for starting a new C interface into
>>> LibreOfficeKit (eg BridgeLOkit_* )?
>>>
>> How else would you make a C/C++ interface for swift ?
>>
>> I had success in talking to the main LibreOfficeKit.h file directly from
>>> swift by including it in the bridging file. Using it directly would take
>>> away a lot of duplication needed to flesh out BridgeLOkit. Granted the main
>>> C api isnt that friendly to use, but IMHO it would be better to do the
>>> wrapping and making the API friendly on the Swift side, rather than another
>>> layer of C, which then still needs swift friendly classes around it.
>>> The main problem is with the way LibreOfficeKitInit works (which seems
>>> weird...), for which I reused BridgeLOkit_Init and added a func to get
>>> the pointer to kit out.
>>> See the attached LibreOfficeKitWrapper.swift file - it has just a couple
>>> wrapped functions done but you can see what I mean. Needs the rest filled
>>> in and memory handling done.
>>>
>> Functions not declared in the bridge are unlikely to work in swift
>> (according to the swift documentation).
>>
>>
>>> I've done this before for Pdfium - which also has a C based FFI. We
>>> created a framework called PdfiumSwift which had swift classes like
>>> PDFDocument, PDFPage etc which wrapped the C interface and made consuming
>>> it easy in Swift. We hooked the memory management off the swift deinit()
>>> etc.  It used an internal private module to consume the C API so it was
>>> just the Swift API exposed outside of the framework / module.
>>>
>> this is basically the same the kit project does, except it does not use
>> classes.
>>
>> rgds
>> jan i
>>
>>>
>>> Once the basic wrapping is done, then these classes provide a good place
>>> to add stuff like converting the raw tiles into iOS friendly bitmaps etc.
>>>
>>> Anyway, good job on getting it this far, and happy new year.
>>>
>>> Cheers
>>>
>>>
>>> Jon Nermut
>>>
>> --
>> Sent from My iPad, sorry for any misspellings.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20171229/dd8065a8/attachment.html>