LibreOfficeLight / iOS
Sophia Schröder
sophia.schroeder at libreoffice.org
Fri Dec 29 17:23:57 UTC 2017
BTW:
from the marketing perspective (where I came from) I love the name you
gave your babe:
I would also love to have two apps, for Android the existing "Viewer"
what it isn't anymore with the new possibilities for editing e.g. and
for iOS your awesome work, both as "LibreOfficeLight".
Given they have mainly the same functionalities and maybe have some less
or more differences here and there.
Am 29.12.2017 um 16:43 schrieb 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
> <mailto: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
> <mailto: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.
>
>
>
>
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
--
Regards / Mit freundlichen Grüßen
Sophia Schröder
---
German Language Team
LibreOffice.org
IRC: SophiaS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20171229/e68ddadc/attachment.html>
More information about the LibreOffice
mailing list