Re: LibreOfficeLight / iOS

Happy new year, very interesting work.

I have just updated my master, and now I see your problem with libassuan,
which I am trying to solve. It is being build locally but not copied to the
right place. I did a couple of commits yesterday to a.o. include your idea
on how to make LIBRARY_PATH relative, thanks for that.

> try the -r flag which is for prelinking. you can see that in the .mk file

> Couldn't get that to do anything. I also tried -flto=thin which supposedly
> can do incremental linking, but again little effect

Look in iOS/CustomTarget_iOS_prelink.mk, there you will find

        $(IOSLD) -r -ios_version_min 11.1 \

            -syslibroot $(MACOSX_SDK_PATH) \

            -arch `echo $(CPUNAME) |  tr '[:upper:]' '[:lower:]'` \

            -o $(IOSOBJ) \

            $(WORKDIR)/CObject/ios/source/LibreOfficeKit.o \

            `$(SRCDIR)/bin/lo-all-static-libs` \

            $(call gb_StaticLibrary_get_target,iOS_kitBridge)

        $(AR) -r $(IOSKIT) $(IOSOBJ)

which does prelinking (different from incremental linking). You can see it
generated and .o file, which is then put into an archive.


> Nah it would be very difficult if not impossible to get a swift Framework
> built through make - one thing that I've learnt in iOS development is don't
> fight XCode. You'ld end up just calling xcodebuild anyway, which still
> needs the project set up correctly.
??? xcode runs perfect on the command line, so I do not understand why you
say it is impossible.


>
* The linking of the framework takes just as long as the app did. But once
> you have it built, as long as you don't touch the framework, rebuilds of
> the app are fast
This is as expected. The framework is basically a dylib so of course
linking to that is a lot faster.

I am still not convinced making a framework is a better solution than just
linking a dylib directly, at least I do not see the advantages and at least
one disadvantage, one more xcode project to maintain.


> * It's only been tested on the simulator. Needs some more stuffing about
> to link the correct lib for device.

dylib works very well in the simulator, my first test on my iPad (iOS 11.2)
did not turn out very well. I am also looking into another problem, it
seems that the App Store, still only allows upload of statically linked

*** The way it's set up in the app at the moment with 3 schemes isn't as it
> should be - you should have just one scheme, and use Configuration is for
> debug/release, and platform/arch for simulator vs device. This will work ok
> in the app once the framework is configured to link the correct .a file.
> Which I will sort out if you move forward with this

The reason for using different schemes, is that the xcode doc recommends
it, and it make the use simpler, since you just have to select a scheme.

Why do you think just having 1 scheme is better ?


> * I built out the Swift wrappers to cover all of the LibreOfficeKit
> functions. Have a look at Document.swift in particular. The next step would
> be to make an extension of Document to make iOS friendly methods for eg
> rendering to a UIImage

It is a different approach, but one I like, we do however still need the C
file.



> * I tried to get a tile rendering both in the test and the app. No good.
>
> Firstly I was trying to pass a byte buffer to paintTile as per the method
> signature, but it force casts that param to a CGContextRef a couple of
> layers down...
> But even after creating one of those to render into a image, it crashes
> with an uncaught exception of type com::sun::star::container::NoSuchElementException
> (see pic of stack trace below)
> Which took me deep into debugging core LibreOffice, which I didn't really
> want to be, and was a bit frustrating. Maybe I'm missing some init code, or
> passing the wrong params.
> Feels like it might be bitrot of this tiling code that was written as a
> POC in 2015 or so? I wonder when the last time it worked was. You mentioned
> that you couldn't get it working either?
My problem was more how to use the returned array in order to render it
effectively.

The paintTile code is used both in the android version (see core/android)
and the online (separate git repo), so it works.

You might have run into a problem with swift delivering a false type of
array.


> Anyway, I really think splitting into a Framework is the way to go - I
> think the rendering problems are probably independent of this.
> It provides a good separation between app and library, and makes the app
> be able to be pure swift.
> It would certainly make using LOK in another app much much easier, than
> trying to unpick the example app.
Which example app ?

The old example app have been removed because it was very outdated.

keep up the good work, I will get around to integrate part of it soon.

rgds
jan I.