Age | Commit message (Collapse) | Author |
|
Change-Id: I538db88f8477dd2d2ad25c372928fec6c11d979d
Reviewed-on: https://gerrit.libreoffice.org/72105
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
not before vowels with a consonant sound so its a url not an url
Change-Id: Ic27ff3bee67469284d460c31ced6f63cb3633db2
Reviewed-on: https://gerrit.libreoffice.org/72062
Reviewed-by: Jens Carl <j.carl43@gmx.de>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1893d52df505bc43428c37a624ca05c569ba1bc0
Reviewed-on: https://gerrit.libreoffice.org/70958
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
I wonder wheter we should just include all of instdir/share. Seems
that I have to add more and more of it all the time anyway. I don't
remember why I thought (many years ago) that an app would need just a
subset. (Maybe I thought that an app would not, at least not
initially, have functionality that would use most of the stuff in
shre. But that has changed now.)
Change-Id: I62f935e3ab9c4709373fad11ed120ecca033b4aa
|
|
That is apparently what we want.
Change-Id: I900c26873de02495cac7918b0c453f4fdcb6c3e6
|
|
Otherwise we get a warning dialog about a missing
internal/idxexample.odt when inserting a table of contents.
Change-Id: Id30be100906ea3292b9acd9e983ef7ae39ef63a2
|
|
Change-Id: I460a71f363eb3b7f89786b8bd02f4b8f9521f4c7
|
|
Change-Id: I02ab930c6e3304009c90eef36f55d61a4531af7c
|
|
Change-Id: I126dbbec9fb6cbb19f848d8317002c69b407a36b
|
|
...which was at maximum set to GCC's -finline-limit=0 -fno-inline
(solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug
builds "since forever", but that looks very much like cargo cult: -fno-inline
"is the default when not optimizing" anyway
(<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it
is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline
(and maybe was present for ancient compilers that only supported -finline-limit
but not -fno-inline?).
Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874
Reviewed-on: https://gerrit.libreoffice.org/66836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iacd5323ee1db9be294556f3d7344eab00b27095b
|
|
The way the iOS app is built (over in the online repo), any
"resources" to be included need to be copied into the
workdir/CustomTarget/ios folder.
Change-Id: Ibac15b03dc447d6649e03404fe9a68ef3b4881b9
|
|
Previously it tried to use a BUILDID Make variable that did not exist.
Change-Id: Ie31eb3928c69dc52fcb17a9a5593cbe166d95307
|
|
Otherwise i18nlantag works weirdly.
Change-Id: Ic5bf2007e586e6bb53a9e89782c2b05f73e348e3
|
|
Not sure wht it was commented out. For now use
$(LIBO_SHARE_RESOURCE_FOLDER) which is the same "program/resource" as
on Unix.
Change-Id: I81b8dd4868e68c3a8c38f9b4f84de7bfc8383d28
|
|
Change-Id: Ie46906d5aa84d91efcb88ca795797883e883939f
|
|
Change-Id: I6f4cf36509c2fedf7bed346a07080fe0c67716a2
|
|
This gets rid of the horrible hack in gbuild.mk to accomodate the
case-incorrect iOS platform makefiles that cannot be renamed without
upsetting git on file systems that sadly lack the case sensitivity
feature.
Keep the macro defined to IOS though.
Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234
Reviewed-on: https://gerrit.libreoffice.org/62705
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I979a163e796418d9a693229698b638cec4bf2226
|
|
The makefile here was changed already some weeks ago to put
native-code.h in workdir and not in the source directory, but I forgot
to make sure this file still compiled, as it is used by
LibreOfficeLight only.
Yes, it is ugly to use the workdir/CustomTarget/ios pathname, so sue
me.
Change-Id: I568d933c1d1384041632f432053d0a0c64c485c2
|
|
But I tested just a few times. If somebody re-starts work on
LibreOfficeLight, and encounter hangs, hopefully they notice this
commit and try to un-comment-out the line in question.
I hadn't noticed that temporaryHackToInvokeCallbackHandlers() thing
before, maybe calling it in the iOS app being developed (in the
"online" repo) is necessary, and would help avoiding the hangs I
occasionally see in it?
Change-Id: I0f4d8c800024c43acb512d40efdfad71c229bec2
|
|
Don't bother with a 'userinstallation' subdirectory. It is a
subdirectory called "user" of the UserInstallation value that will be
used for our stuff anyway.
Change-Id: Idb6b5992bfda73ed7af80274b0de8ad7b43c241c
|
|
Thus it now actually takes a buffer pointer also on iOS, like on Linux
and Android. Less confusing, more uniform. Add a separate iOS-specific
paintTileToCGContext() method to LibreOfficeKitDocumentClass that
takes a CGContextRef. Adapt callers correspondingly. (The
LibreOfficeLight code in particular needs the paintTileToCGContext().)
Change-Id: I81084806d37b9aac9f2b2bc03d0c262e991eec81
|
|
(And it actually works now again, as far as I see, after the recent
fix to LibreOfficeKit's iOS code.)
Adapt to earlier changes: The generated files are now in workdir, not
in the ios source directory.
Use org.libreoffice.ios.LibreOfficeLight for the
PRODUCT_BUNDLE_IDENTIFIER instead of janI's own.
(Additionally the DEVELOPMENT_TEAM was reset to the one I use;
apparently there is no way to make sure that developer-specific
setting is in a file not in version control?)
Change-Id: I575561583f584b5ac3c759d115b1c9c6dc97ef94
|
|
(No idea why it complains about that only now. I did upgrade the Mac
where I am building this to 10.14, but not sure how that could have an
impact?)
Change-Id: Ifaf56dbbe380694049d4957cc3fa8174c602bc67
|
|
Change-Id: I3dccdd3253bf6e3e451b9ed53786eefaa02d451e
|
|
Change-Id: I02c73c040eafd77628d94f6045c48f02b650f8d6
|
|
Change-Id: I61b030d277a7fbcc1fd714b3edafc7922c59483a
|
|
Change-Id: Iccf4b7156677c6db7e675b2c7a6926d8395d025a
|
|
To get that with CoreGraphics on iOS we need to use also
kCGImageByteOrder32Little in the CGBitmapContextCreate() call,
otherwise the bytes will be in ARGB order in memory.
(Not touching the macOS code here.)
Change-Id: I3c2dd94feb1c6bf46c5b335f5901b29e5fe1e7fb
|
|
On iOS, don't attempt to write the tile dump ppm file to /tmp, but use
the app-specific directory so that it can be copied for inspection
using iTunes. (Of course, even better would be to simply paint it to
the app's view. Later)
Change-Id: I8dd60d04adc61de6594099f5c358a9b6220522da
Reviewed-on: https://gerrit.libreoffice.org/61255
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Idef0b375d5c7d6d4542aee1f8abecaf9f834189c
Reviewed-on: https://gerrit.libreoffice.org/61058
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Idedcaddeab80fcfdc3d5a4f2852712827a98e848
|
|
It seems that on iOS, where we don't have any Java, Python, BASIC, or
other scripting, the only thing that would use the C++/UNO bridge
functionality that invokes codeSnippet() was cppu::throwException().
codeSnippet() is part of what corresponds to the code that uses
run-time-generated machine code on other platforms. We can't generate
code at run-time on iOS, that has been known forever. Instead we have
used some manually written assembler to handle it instead. We used to
have a Perl script to generate a set of code snippets for different
cases, different numbers of parameters of the called function and
whatnot, but that went away at some stage some year ago. (It is
unclear whether that broke the C++/UNO bridge on iOS, or whether the
stuff continued to work even after that.)
Anyway, this handwritten assembly, or the manual construction of
internal data structures for exceptions, or something else, seemed to
have bit-rotten. Exceptions thrown with cppu::throwException() were
not catchable properly any longer.
Instead of digging in and trying to understand what is wrong, I chose
another solution. It turns out that the number of types of exception
objects thrown by cppu::throwException() is fairly small. During
startup of the LibreOffice code, and loading of an .odt document, only
one kind of exception is thrown this way... (The lovely
css::ucb:InteractiveAugmentedIOException.)
So we can simply have code that checks what the type of object being
thrown is, and explicitgly throws such an object then with a normal
C++ throw statement. Seems to work.
Sadly the cppu::getCaughtException() API still needs some inline
assembly in the C++/UNO brige. That seems to work though, knock on
wood.
This commit also adds a small "unit test" for iOS, copied from
cppuhelperm to ImplSVMain(). Ideally we should not copy code around of
course, but have a separate unit test app for iOS that would somehow
include relevant unit tests from source files all over the place.
Later.
Change-Id: Ib6d9d5b6fb8cc684ec15c97a312ca2f720e87069
Reviewed-on: https://gerrit.libreoffice.org/60506
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Not sure how it worked in LibreOfficeLight.
Change-Id: I0991b13a7538581642f530bf45a1bba1b1b644d5
Reviewed-on: https://gerrit.libreoffice.org/60505
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
(The LibreOfficeLight Xcode project still needs to be adapted
correspondingly.)
Change-Id: I0b17c595fc0d169f6393ab8734a1eecb241f59be
|
|
Change-Id: I7454c10a1547db796554f45f2d630af81a916c55
|
|
(To be used from Xcode projects elsewhere building iOS apps that want
to link to iOS code built here.)
Change-Id: I39bf2a4ed059930fcfc30c4d2016dfbc698da353
|
|
Change-Id: I78571f8494a13f6f8c07f9aee2bf6f8144a48ed2
|
|
Change-Id: I1310cb8f5f543f49f9667ee10cb26c9809df259e
|
|
Change-Id: I222792dd34cd016196dfec9870161896c7c43b0d
|
|
Change-Id: Ifea7072922388b2c0b7631fb809b23e2a5524a3c
|
|
Change-Id: I7faf23de08db680599658206faaf3028888563f6
|
|
chmod -x to complete
Change-Id: I966773e0adebf8563343856f18ba25ba84b0a633
Reviewed-on: https://gerrit.libreoffice.org/53666
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I68464a213303ebe7dd850659031baf4cd7bdfa73
|
|
The build phase contained copy statements for
bridges/source/cpp_uno/ which should not happen
Change-Id: Ied4c1b2ef29effe4642f5ca0e7dc3a5b41ef0b68
|
|
Solved problem in assembler code, so the call chain is correct.
There are still something missing for uno to work correctly
Change-Id: Ieb3b3d6b15153576159e07b52ced0efedd135713
|
|
the only change is that addition of files needed to debug the
stack corruption problem.
Change-Id: I3598cdba2e84f51a3a90387dbe3439eafb34f878
|
|
It must be changed in the swift code also.
Change-Id: Ide7ccbb89d94f91a9f6e0dbbd7a29035c46f7f4f
|
|
Change-Id: I266fe71a6c58d8b80fa917198e8d84b356dfe296
|