1. 10 May, 2019 2 kayıt (commit)
  2. 26 Nis, 2019 1 kayıt (commit)
  3. 12 Nis, 2019 1 kayıt (commit)
    • Tor Lillqvist's avatar
      tdf#124449: We need also share/gallery for the iOS app · 7811a0e5
      Tor Lillqvist yazdı
      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
      7811a0e5
  4. 25 Mar, 2019 1 kayıt (commit)
  5. 20 Mar, 2019 1 kayıt (commit)
  6. 11 Mar, 2019 1 kayıt (commit)
  7. 28 Şub, 2019 2 kayıt (commit)
  8. 24 Ock, 2019 1 kayıt (commit)
  9. 30 Kas, 2018 1 kayıt (commit)
  10. 27 Kas, 2018 1 kayıt (commit)
  11. 26 Kas, 2018 1 kayıt (commit)
  12. 12 Kas, 2018 1 kayıt (commit)
  13. 09 Kas, 2018 2 kayıt (commit)
  14. 06 Kas, 2018 1 kayıt (commit)
  15. 01 Kas, 2018 1 kayıt (commit)
  16. 31 Eki, 2018 1 kayıt (commit)
  17. 22 Eki, 2018 1 kayıt (commit)
    • Tor Lillqvist's avatar
      Look for the generated native-code.h where it now is · c49d9180
      Tor Lillqvist yazdı
      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
      c49d9180
  18. 19 Eki, 2018 1 kayıt (commit)
    • Tor Lillqvist's avatar
      It seems to work even without calling temporaryHackToInvokeCallbackHandlers()? · 9a373521
      Tor Lillqvist yazdı
      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
      9a373521
  19. 12 Eki, 2018 1 kayıt (commit)
    • Tor Lillqvist's avatar
      Avoid superfluous directory level · 944ef72a
      Tor Lillqvist yazdı
      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
      944ef72a
  20. 10 Eki, 2018 2 kayıt (commit)
    • Tor Lillqvist's avatar
      Move the iOS CGBitmapContextCreate() call do doc_paintTile() · 1d279e9c
      Tor Lillqvist yazdı
      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
      1d279e9c
    • Tor Lillqvist's avatar
      Make LibreOfficeLight build again · 6b77a740
      Tor Lillqvist yazdı
      (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
      6b77a740
  21. 08 Eki, 2018 1 kayıt (commit)
  22. 05 Eki, 2018 4 kayıt (commit)
  23. 02 Eki, 2018 2 kayıt (commit)
  24. 28 Eyl, 2018 1 kayıt (commit)
  25. 27 Eyl, 2018 1 kayıt (commit)
  26. 15 Eyl, 2018 1 kayıt (commit)
    • Tor Lillqvist's avatar
      Re-think cppu::throwException() and the C++/UNO bridge on iOS · 7d6be61a
      Tor Lillqvist yazdı
      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: 's avatarTor Lillqvist <tml@collabora.com>
      7d6be61a
  27. 14 Eyl, 2018 1 kayıt (commit)
  28. 05 Eyl, 2018 3 kayıt (commit)
  29. 28 Agu, 2018 2 kayıt (commit)