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.