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.ner...@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 <j...@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. >> > >
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
