summaryrefslogtreecommitdiff
path: root/ios
AgeCommit message (Collapse)Author
2019-05-10an uno -> a unoCaolán McNamara
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>
2019-05-10an is used before a vowel soundCaolán McNamara
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>
2019-04-26lok: allow paste content to popup dialogHenry Castro
Change-Id: I1893d52df505bc43428c37a624ca05c569ba1bc0 Reviewed-on: https://gerrit.libreoffice.org/70958 Tested-by: Jenkins Reviewed-by: Henry Castro <hcastro@collabora.com>
2019-04-12tdf#124449: We need also share/gallery for the iOS appTor Lillqvist
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
2019-03-25Just include all fonts from instdir/share/fonts in the iOS appTor Lillqvist
That is apparently what we want. Change-Id: I900c26873de02495cac7918b0c453f4fdcb6c3e6
2019-03-20tdf#124168: The share/template folder is needed in the iOS appTor Lillqvist
Otherwise we get a warning dialog about a missing internal/idxexample.odt when inserting a table of contents. Change-Id: Id30be100906ea3292b9acd9e983ef7ae39ef63a2
2019-03-11We need share/theme_definitions in the iOS appTor Lillqvist
Change-Id: I460a71f363eb3b7f89786b8bd02f4b8f9521f4c7
2019-02-28I had forgotten to add these files to gitTor Lillqvist
Change-Id: I02ab930c6e3304009c90eef36f55d61a4531af7c
2019-02-28Current ICU version is 63Tor Lillqvist
Change-Id: I126dbbec9fb6cbb19f848d8317002c69b407a36b
2019-01-24Drop unnecessary gb_DEBUG_CFLAGSStephan Bergmann
...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>
2018-11-30Mention this file is outdatedTor Lillqvist
Change-Id: Iacd5323ee1db9be294556f3d7344eab00b27095b
2018-11-27Prepare to bundle the Liberation fonts with the iOS appTor Lillqvist
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
2018-11-27Fill buildid in versionrc for iOS with the git HEAD hashTor Lillqvist
Previously it tried to use a BUILDID Make variable that did not exist. Change-Id: Ie31eb3928c69dc52fcb17a9a5593cbe166d95307
2018-11-12We need share/liblangtag, tooTor Lillqvist
Otherwise i18nlantag works weirdly. Change-Id: Ic5bf2007e586e6bb53a9e89782c2b05f73e348e3
2018-11-09Do put a BRAND_SHARE_RESOURCE_SUBDIR setting into fundamentalrc for iOSTor Lillqvist
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
2018-11-09Alignment (whitespace) cleanupTor Lillqvist
Change-Id: Ie46906d5aa84d91efcb88ca795797883e883939f
2018-11-06The image zipfiles should be in share/config, it seemsTor Lillqvist
Change-Id: I6f4cf36509c2fedf7bed346a07080fe0c67716a2
2018-11-01gbuild: rename value OS=IOS to OS=iOSMichael Stahl
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>
2018-10-31Handle also css::ucb::NameClashException>(aExceptionTor Lillqvist
Change-Id: I979a163e796418d9a693229698b638cec4bf2226
2018-10-22Look for the generated native-code.h where it now isTor Lillqvist
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
2018-10-19It seems to work even without calling temporaryHackToInvokeCallbackHandlers()?Tor Lillqvist
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
2018-10-12Avoid superfluous directory levelTor Lillqvist
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
2018-10-10Move the iOS CGBitmapContextCreate() call do doc_paintTile()Tor Lillqvist
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
2018-10-10Make LibreOfficeLight build againTor Lillqvist
(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
2018-10-08The UnitTest app needs the MobileCoreServices frameworkTor Lillqvist
(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
2018-10-05Add more vcl sources for easier breakpointingTor Lillqvist
Change-Id: I3dccdd3253bf6e3e451b9ed53786eefaa02d451e
2018-10-05Add sources in vcl/headless for easier breakpointingTor Lillqvist
Change-Id: I02c73c040eafd77628d94f6045c48f02b650f8d6
2018-10-05Add more source files from vcl for breakpointing convenienceTor Lillqvist
Change-Id: I61b030d277a7fbcc1fd714b3edafc7922c59483a
2018-10-05Add files from vcl/quartz for easy breakpointingTor Lillqvist
Change-Id: Iccf4b7156677c6db7e675b2c7a6926d8395d025a
2018-10-02LibreOfficeKit wants the tile pixmap bytes to be in BGRA order in memoryTor Lillqvist
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
2018-10-02More hacking on the tilebench part of the UnitTest appTor Lillqvist
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>
2018-09-28Start on the iOS unit test appTor Lillqvist
Change-Id: Idef0b375d5c7d6d4542aee1f8abecaf9f834189c Reviewed-on: https://gerrit.libreoffice.org/61058 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com>
2018-09-27Need to handle css::uno::RuntimeException too nowTor Lillqvist
Change-Id: Idedcaddeab80fcfdc3d5a4f2852712827a98e848
2018-09-15Re-think cppu::throwException() and the C++/UNO bridge on iOSTor Lillqvist
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>
2018-09-14Return share/config/soffice.cfg as it was, as I think the code expectsTor Lillqvist
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>
2018-09-05Don't copy files into the source directory, use workdirTor Lillqvist
(The LibreOfficeLight Xcode project still needs to be adapted correspondingly.) Change-Id: I0b17c595fc0d169f6393ab8734a1eecb241f59be
2018-09-05Put the lib names one per line to match what ld's -filelist expectsTor Lillqvist
Change-Id: I7454c10a1547db796554f45f2d630af81a916c55
2018-09-05Run bin/ios-all-static-libs and put its output in a fileTor Lillqvist
(To be used from Xcode projects elsewhere building iOS apps that want to link to iOS code built here.) Change-Id: I39bf2a4ed059930fcfc30c4d2016dfbc698da353
2018-08-28Fix typoTor Lillqvist
Change-Id: I78571f8494a13f6f8c07f9aee2bf6f8144a48ed2
2018-08-28Add --enable-ios-libreofficelight-app option to build stuff for janI's appTor Lillqvist
Change-Id: I1310cb8f5f543f49f9667ee10cb26c9809df259e
2018-08-28Bump version number in ICU data file nameTor Lillqvist
Change-Id: I222792dd34cd016196dfec9870161896c7c43b0d
2018-07-17Use $(ICU_MAJOR) instead of hard coded (Upgrade to ICU 62.1)Eike Rathke
Change-Id: Ifea7072922388b2c0b7631fb809b23e2a5524a3c
2018-06-07We use ICU 61 nowTor Lillqvist
Change-Id: I7faf23de08db680599658206faaf3028888563f6
2018-06-02Removed executable permission on data filesAndrea Gelmini
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>
2018-04-02iOS, update source to xcode 9.3 swift 4.1jan Iversen
Change-Id: I68464a213303ebe7dd850659031baf4cd7bdfa73
2018-03-17iOS, remove copy of source code to instdirjan Iversen
The build phase contained copy statements for bridges/source/cpp_uno/ which should not happen Change-Id: Ied4c1b2ef29effe4642f5ca0e7dc3a5b41ef0b68
2018-03-15iOS, solved corrupted stack in cpp -> unojan Iversen
Solved problem in assembler code, so the call chain is correct. There are still something missing for uno to work correctly Change-Id: Ieb3b3d6b15153576159e07b52ced0efedd135713
2018-03-11iOS, updated xcode project filejan Iversen
the only change is that addition of files needed to debug the stack corruption problem. Change-Id: I3598cdba2e84f51a3a90387dbe3439eafb34f878
2018-03-03iOS, change example.odt -> welcome.odtjan Iversen
It must be changed in the swift code also. Change-Id: Ide7ccbb89d94f91a9f6e0dbbd7a29035c46f7f4f
2018-03-03iOS, moved resources from share to direct.jan Iversen
Change-Id: I266fe71a6c58d8b80fa917198e8d84b356dfe296