Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.