Upcoming changes will introduce use of APIs that require iOS 13.
Change-Id: Idd4b1e1235ca7ab19eea8aa58f72784b946d50f8
Signed-off-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit fcdc3b2f89)
It leads to the app being rejected when uploaded to App Store Connect.
The rejection email says:
ITMS-90176: Unrecognized Locale - The locale names used in
localization directories at ('Payload/Mobile.app/Settings.bundle/ca-VALENCIA.lproj')
are invalid. iTunes supports BCP47 but not the UN M.49
specification. Refer to the Language and Locale Designations guide
at https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPInternational/LanguageandLocaleIDs/LanguageandLocaleIDs.html
for more information on naming your language-specific directories.
Change-Id: I0ede85c5cc65c203e93ff4b75e898a3faaef20e2
When keyboard input has been directed to one text field in a tunnelled
dialog, and the user taps in another field, we (for some unclear
reason) then get a UIKeyboardDidHideNotification, but we do want the
keyboard to stay usable, so make sure that happens.
Change-Id: I6d0ba9ab65027ad1f687b2bc98b2294e061376d5
We can't let the normal UIResponder and UITextView mechanism try to
handle the clipboard (well, "pasteboard" is what it is called on iOS
and macOS) commands as the UITextView has no idea about the *real*
document being edited. The paste command in theory might work, but
best to let LibreOffice core handle that, too.
Change-Id: Id130708ceb5718660af26367538a17a14238843b
We don't have any such messages permanently in the code anyway, so we
don't win anything by doing it through the LOOL loggin mechanism at
level "trace".
Change-Id: I2c18e1cd561f797d2c4c20b403d5faedce695062
Added translation using Weblate (Norwegian Bokmål)
Translated using Weblate (Norwegian Bokmål)
Currently translated at 98.8% (344 of 348 strings)
Translation: Collabora Online/UI
Translate-URL: https://hosted.weblate.org/projects/collabora-online/ui/nb_NO/
In theory, this doesn't make sense. In practice, it helps.
Change-Id: I34d03a812c543e1b112851c9e9ff512f2482a20c
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/103714
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Ignore a hide command that quickly followed a display command.
Change-Id: I7be71dbc3ccdffb9db78de4a6b70d59baee14457
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/103713
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
... to indicate this is intended behavior.
Change-Id: Id5318bb20b8066364c5e2fd3b704b5a73bac1b42
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/103711
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
These files contain no data at all. This guarantees that when the
user opens a new document in the app, the language of paragraph,
page size, cell date format, currency, etc. will be according to
the current locale.
Change-Id: If1804ad4c63b8eb76c229a9e683d207191c385c5
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/102284
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
This is a quite complicated change that should both fix tdf#133284
(cursor keys on a hardware keyboard do not work in a spreadsheet
document) and also improve the interaction with
CollaboraOnlineWebViewKeyboardManager that manages the on-screen
keyboard. We need to jump through complicated hoops in order to get
the hardware cursor keys handled right after loading a spreadsheet
document.
In the CollaboraOnlineWebViewKeyboardManager case we try harder to
keep loleaflet's _textArea buffer in sync with what the UITextView in
CollaboraOnlineWebViewKeyboardManager uses to provide suggestions
above the on-screen keyboard.
Also merges in related changes from today to
CollaboraOnlineWebViewKeyboardManager.
Change-Id: Ic4acb54bd4e815aa8bfb2bf40b08493446ae5ab0
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/101878
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
For now, just copy its source files here. When/if I figure out what is
the appropriate way to package that framework for use in other
products (like the Collabora Office iOS app) I will use that instead.
Change-Id: If808f96b6a72c80e54dc84fce80a551503c96335
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/101268
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
We don't want to use cached scaled icons (and other stuff that might
be in the cache?) if from a potentially incompatible version of the
app. Store the core and online hashes in files in the cache to be able
to compare.
Change-Id: I593ece5dae71f91f204d4c040bd9f744b3bc498f
AC_DEFINE causes it to be in config.h, but there is no code that would
use its definition from there.
It is enough to have AM_CONDITIONAL for it (to enable having 'if
ENABLE_SETCAP' in Makefile.am files) and AC_SUBST it (to enable having
'@ENABLE_SETCAP@' in Makefile.am and *.in files).
Change-Id: Ia00b624114c8139d81bb173c92800ae0a62fec35
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/99287
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Avoids the need for PNG encoding (takes significant amount of CPU
time) and Base64 encoding in the app process, transfer to JavaScript
(running in a WebKit process of its own), and corresponding decoding
(in the WebKit process). Instead simply pass the URL of each tile file
to the JavaScript. Remove each BMP file once it has been loaded.
Change-Id: I6e7b9450691679c64813979976c59f1763ec104c
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/98710
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
(Why not call LOG_INF directly in FakeSocket.cpp instead? Good
question. I guess my idea was originally to keep FakeSocket separately
testable without all the Online logging stuff.)
Change-Id: I1e6b730a9742ad653d431774d88fec6a36d98850
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/98736
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
This prevents an assertion failure when you quickly open the same
document again after closing it.
Change-Id: I26b8c53d57bd1d33f0473a3c5a332ec02c37455d
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/98263
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
A small re-factoring to help planned re-plumbing of the iOS app.
Change-Id: I21f09216a7c5adf965179765a75f5a0d521cd7f3
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97771
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Surely no point in using that code for the iOS app, though. Hopefullly
eventually some clean way to bypass it wil emerge. Note that this is
just one step towards making the iOS app even build again.
Change-Id: Ia5a8e31fc6195394f02cbf43f2b5291bcfbb398d
- read settings from loolwsd.xml
- in case of notebookbar activated send :notebookbar parameter
- for mobile apps I left empty parameter in setupKitEnvironment calls
Change-Id: I5813589564b37eecc1e77c5d0eb737eca5f92f04
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/97233
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Seems to not cause any serious regressions in the iOS app or in "make
run", but of course I am not able to run a comprehensive check of all
functionality.
Change-Id: I44a0e8d60bdbc0a885db88475961575c5e95ce88
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/93037
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
When exporting a copy, let core write the copy to a temp subdirectory
before invoking UIDocumentPickerViewController to select where to
store it permanently.
Change-Id: I3d2292414a3c824515ba6d98ad09b296e543cea9
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/95295
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
I don't want to make it necessary to have npm on macOS (in the case of
building the iOS app, otherwise Online is Linux-only). I still want to
use the method where the JS bits are built on a Linux machine and
loleaflet/dist is copied over to the Mac where you build the iOS app.
Remove the apparently never seriously used instructions for the other
way from ios/README. If somebody actually *uses* that way for real,
for a longer time, then please reinstate them, and modify
configure.ac, etc.
Change-Id: I22a8ca4746907bb11aad11d7c995b0de2fdbc157
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/94815
Tested-by: Jenkins
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
If you edit the Info.plist in Xcode, it is written with TABs and
eight-column indentation steps. Make the Info.plist.in the same to
make it easier to compare what changes in case you do some intentional
change in Xcode first.
This commit has only whitespace changes.
Change-Id: I0878eac5e19f666426ab67dd8e3c425027036756
We need to catch the downloadas message already in
-[DocumentViewController
userContentController:didReceiveScriptMessage:] and use an
UIDocumentPickerViewController to let the user choose where to
download (or export) the document. The iOS-specific code in
ChildSession::downloadAs() can go away.
Change-Id: I626b9986ec6156f7e83bda02b04e65f7819f8017
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92112
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
It is enough to call the -[UIDocument
saveToURL:forSaveOperation:completionHandler:] only in
DocumentBroker::sendUnoSave(). And on the other hand, in
-[DocumentViewController bye] we can't want for the
LOOLWSD::lokit_main_mutex as the main queue is needed for parts of
what the saveToURL does.
Also, use a separate copy of the document as the file that is actually
edited by LO core. This matches what the Android app does. I think it
is useful to do this in order to avoid some hangs that I noticed. They
probably were caused by both LO core and the system frameworks
occasionally accessing the same document file at the same time.
Change-Id: Idb65be23a7cb6ad1288fbbd23c7471e0fb8d52f4
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/91851
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
There are already several classes called Document on the C++ side.
Let's reduce confusion a bit. (Also, we might need to use the
Objective-C Document class from some of the Online C++ code (which is
actually compiled as Objective-C++).)
Change-Id: I34347ba0161c067b14bb125c3410eefd89bbca31
The problem is that the @media-based detection often disagrees with the
JS-based detection which then leads to many problems - most notably that
part of the UI behaves as if it was a tablet, and the other part as if
was a mobile phone, leading to a terrible user experience.
This commit changes it so that there is only one way how to detect if
we are on mobile phone, tablet or desktop: using the JavaScript, and we
will load the appropriate css accordingly.
Only one @media-based rule is converted as an example, the rest will
follow.
Change-Id: Id7bfb58ca12264904b3329db1542ae6b54893f11
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/91416
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
The git hashes now show up in the Settings app, without having to run
the Collabora Office app, open a document, and check the About dialog.
The core git hash is taken from the core build directory's
instdir/program/setuprc.
Also, drop the fairly pointless lone Finnish localisation of the
Settings strings.
Change-Id: I56631f8facde017ed99038209c55f516386eab99
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/91073
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
This was added in commit 2174206de1 (android:
Don't hang after returning from a hyperlink., 2020-02-14), but the new command
was only handled on Android. Handle HYPERLINK on iOS, too.
Change-Id: I8c942c1a64c8a52462a749989e312d0d9899a841
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/90917
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
... in order to have languages agnostic templates.
fo:language="en" fo:language="US" was removed from styles.xml
Change-Id: I680809d33cb902fc447ea5393d7f8dad3d83cbfc
Otherwise, when one validates (or uploads) a new build, even just for
TestFlight purposes, one gets an error in Xcode: "The value for key
CFBundleShortVersionString [4.2.1] in the Info.plist file must contain
a higher version than that of the previously approved version
[4.2.1]."
(cherry picked from commit 585cf6be86)
Change-Id: I2ea1342980384a8eb81312734747be5e686da347
We can't rename a file in the Xcode project, so copy it to
ios/Mobile/loolkitconfig.xcu in the configure script, and use from
there.
Change-Id: I1e50235c06f528dd24d0d968aaccc994418b57d8
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/89466
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
We want to be able to force the on-screen keyboard to be displayed
(when there is no external hardware keyboard) from our JavaScript.
Change-Id: I0678d84ca941a03316ffb68cfd9c3e93a6ea7e57
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/89023
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Particularly configuration layers so we can tweak mobile config
easily.
Add core source files from configmgr for breakpointing convenience in
the iOS project. Add loolkitconfig.xcu to the iOS app bundle. Use
${BRAND_BASE_DIR} instead of a compile-time LOOLWSD_CONFIGDIR literal
on iOS (because there is no compile-time constant path to the app
bundle). No "registry" directory directly in the app bundle any longer
on iOS, a corresponding change in core.git moved that stuff to be
under "share", like on other platforms.
Change-Id: I6672efc0505abf27297c4758118a20992b10ceb3
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/88765
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
As a build of 4.2 has been approved for release in the App Store, we must bump
this before any new build can be uploaded, even just for TestFlight.
Change-Id: I60de542eaf6d10776ad287c8c9c5d36e0feed70c
Effectively both approaches were doing the same thing, let's unify to
the iOS way to minimize the platform-specific code.
Change-Id: I11290410a536c26db054ffcb87e3b64cc2a11c07
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/84589
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
(It is, sadly, apparently possible to set breakpoints in advance
(before the code has reached that file) only in files that are listed
in the project.)
Also drop the nonexistent "filter" directory in Resources. (It is
config/filter.)
Change-Id: I96ec9dd8dc4591db9d640b01fb07e807565670cb
Add a "singleton" class method to DocumentViewController to return the
(as for now) singleton DocumentViewController.
Change-Id: I0b8a8def558cfe7f9469b6062a86311dfa63f549
Reviewed-on: https://gerrit.libreoffice.org/82007
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit 2807f907d9)
Reviewed-on: https://gerrit.libreoffice.org/82021
Probably a good idea, although doesn't seem to have much effect? At
least not on tdf#128577.
Change-Id: I7b66a2e9ba44bd4cef583c0861883edfae11eb1d
Reviewed-on: https://gerrit.libreoffice.org/82006
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit 2990203dff)
Reviewed-on: https://gerrit.libreoffice.org/82020
... because lotuswordpro filter is not present in MPLv2-only core builds
Change-Id: I100e886273f8b7fd38887576c2d29fad4c69b2e7
Reviewed-on: https://gerrit.libreoffice.org/79683
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit d781398991)
Otherwise, if you close a document before it has been rendered
completely, the plumbing of threads and FakeSocket connections gets
confused and opening the next document hangs or runs into an assertion
failure. This typically happened for large presentations where
rendering the slide previews takes significant time.
Change-Id: I0f586bec021c4c045a129b3f179ddb3942915c58
Reviewed-on: https://gerrit.libreoffice.org/80882
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
... when the app starts.
Change-Id: Icac4a9e1074fb6c5f3c9b5282e20a4513717a323
Reviewed-on: https://gerrit.libreoffice.org/80881
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Sadly I have no understanding why not doing that caused such a
mysterious end result. But I am glad I thought of trying this simple
thing before spending any more time trying to understand what is going
on.
Change-Id: I129f8fffa32fa087e21c444f9657394de0e255a1
Letting the system call exit() will cause destructors of global C++
objects to be called, and doing that at an arbitrary point in time
will cause a crash. So just call std::_Exit() in the AppDelegate's
applicationWillTerminate: method.
Change-Id: I15d7a761db931a6b7aed588bb407fa0d3b4a9465
(cherry picked from commit 4c2cb838ff)
Seems that setting allowsLinkPreview to NO for the WKWebView affects
this functionality, too. Was just an educated guess, and it worked!
Single-line fixes to what initially seems like a hard problem are the
best.
Change-Id: Ic88bf53b883d857338c0316188e079e6797a4d76
Reviewed-on: https://gerrit.libreoffice.org/80208
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit c7e38e6348)
Otherwise, on iPadOS 13.1, the document will show up in a view that
doesn't cover all the screen, which looks weird, and also makes our
JavaScript code not realize it is on a tablet, so it uses the
phone-style UI, with toolbar at the bottom, no permanently visible
menu bar etc.
This also contains some other changes made by Xcode to the storyboard
file. The only intentional change was changing the Presentation to
"Full Screen", which added a modalPresentationStyle attribute to the
viewController element of the Document View Controller scene.
Change-Id: If33b53981ce40948c54b9adfe791b88a24c4e97d
Reviewed-on: https://gerrit.libreoffice.org/79558
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(cherry picked from commit 0ee9b408cd)
Reviewed-on: https://gerrit.libreoffice.org/79565
Note that this is just one step, work is needed elsewhere, too, for
the app to actually manage to open a .lwp document correctly. (Desktop
Collabora Office opens such documents without problems.) As we can't
save this format, set the CFBundleTypeRole to "Viewer".
Change-Id: I5f818bf915a1a9ee607a97424b2437655f8a9d79
(cherry picked from commit 38e6ace9a6)
Reviewed-on: https://gerrit.libreoffice.org/79384
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
(In the tree where I building the core branch used for the app as
distributed, that is.)
Change-Id: Ice622c79ff9c7f56f4e58f68fe65e5d89696681b
(cherry picked from commit 21dc19f7a2)
Reviewed-on: https://gerrit.libreoffice.org/79381
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Does not fix tdf#125383, though. The WebView still can become zoomed
by manipulating a tunnelled dialog as described in the bug report's
comments.
Change-Id: I9af8d826c58e2065e54b42bc35f74436b0d34a90
The disk tile cache is now gone also in the collabora-online-4 branch,
so no need to keep the string here in master just to be translated.
Change-Id: Ibd496bee738f64152a5ca7a9634e439289b0cd80
The change causes problems for people on various sad distros. Oh well,
whatever.
This reverts commit bd00d9fd05.
This reverts commit 054a9cdb04.
Change-Id: Ie439e4c655d02b6f34bdd1a9c1c5b6db6048b653
It is is complicated enough to build the iOS app. Requiring GNU
libtool brings with it the risk of polluting the command environment
as there already is a completely different command in macOS with the
same name, /usr/bin/libtool. And as GNU libtool was used only to build
the unit tests for the "normal" server-based Online that are built and
run only on Linux anyway, we don't really need any of the
"portability" that GNU libtool brings.
Without GNU libtool, we compile all the $(wsd_sources) (see
test/Makefile.am) that the unit-* tests use into a single object file,
WsdSources.o. (Because they need to be compiled as PIC we can't use
the already compiled object files for the Online server programs.)
This required some additional minor changes to a few source files.
Change-Id: I20a2c523170376fa4c1a0d9d8d6b693a9779376f
Reviewed-on: https://gerrit.libreoffice.org/72840
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
It is presumably possible to do it in the JavaScript, too, and then
the same problem would go away for normal Online viewed in Mobile
Safari, too. But I couldn't figure out how. Googling turned up various
advice that suggested using '-webkit-overflow-scrolling: auto;' for
the body of the page but it didn't seem to help. (I tried adding that
to the style attribute of the body element in loleaflet.html.m4.)
Change-Id: Iac3487a73eca218130583dde9decdb89c316c1fc
Spent hours on trying to cleverly use the existing TerminationFlag
(with minor modifications to the code that checks it, and some
additional code to set and reset it), but could not get it to work.
This is simpler, but sure, using a global variable is ugly of course.
At least the new MobileTerminationFlag is very specific in semantics
and only used in the mobile apps.
Change-Id: I0775fdfa7880750ca12c6fd7ec41d3d3ceb2f0ad
Point out that in my way, you will (sadly) need GNU libtool for the
running of the autogen.sh script, even if not actually at all
otherwise.
(We should really try to get rid of the need for libtool. A minor
amount of hacking to loleaflet/Makefile.am should be enough.)
The pointer to the DocumentViewController object in the Document class
can be a weak property. This avoids a circular reference.
When the DocumentViewController is being dismissed, remove the script
message handlers and remove the view from its superview. Also, set the
webView property to nil.
A configure argument, --with-iosapp-branding, should point to a
directory containing a branding.css file and possibly other files that
branding.css references, to be bundled and used by the iOS app. The
directory structure ends upp in the app bundle as Branding. The
generated loleaflet.html for the iOS app references
Branding/branding.css unconditionally.
They for some reason appear when one adds a Settings Bundle to the
project using Xcode, but are not needed, as far as I see
(I already removed a fourth when I added the Finnish localisation.)
Add a sample Finnish localisation. The localised Root.strings files
are supposed to come from some Pootle-based workflow eventually.
Apparently there is some new and improved way to do localisation in
Xcode 10, "Base localisation", but our project file was created in an
earlier Xcode version and I couldn't figure out how to do it the new
way for Settings.bundle, so I manually added the fi.lproj directory.
I changed the English Root.strings file to be in UTF-8 instead of
UTF-16 (and it still works). (The Finnish one is UTF-8, too.) I added
the strings to be translated from Root.plist into it. That is the file
that should be used as a base for Pootle work, no need to extract
strings from the Root.plist, I think.
Change-Id: I80f1c3199ee14678bb1438e218eb9c2475cd66f8
Preparation for using it on Android too.
Change-Id: Iee7778b2625a02a98daff5df87c39f4ab1d18144
Reviewed-on: https://gerrit.libreoffice.org/70651
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Because of the use of std::shared_ptr in lokit_main(), the (singleton)
lok::Office (or LibLibreOffice_Impl) object gets destroyed when
lokit_main() exits. We shouldn't keep our own copy of a raw pointer to
it around. Just call lok_init_2() to get the pointer where we need it.
We don't need to call lok_init_2() already in -[AppDelegate
application:didFinishLaunchingWithOptions:].
(What we cache is also the textual data: URLs even if we store them
using .png file names.)
This avoids the current back-and-forth-encoding: First we
base64-encode the complete binary "tile:" message (one text line
followed by a newline and the binary PNG) to pass to WebKit, then in
the JavaScript snippet passed to WebKit we decode the base64 and turn
it into an ArrayBuffer, and then we unpack the ArrayBuffer and encode
the PNG part to use as a data: URL.
(Except that the tunnelled dialogs don't show up, but they don't show
up in a browser connected to a normal Online 'make run' either at the
moment.)
Change-Id: Ic054b415d5d78572338e20da711a4285584ba330
I don't have an AirPrint printer so I couldn't verify that it actually
prints, but the system print dialog is displayed and shows a preview
correctly, so I am fairly sure it works.
Change-Id: I5e8a704386cd5053b8689dc63f26e545df323193
The lok_document pointer will only be used when it is valid anyway.
Fixes a crash when you open a second document after closing the first.
Change-Id: I362db282e4eccf419b56bf790ea58181594ab0fe
When you want to build a new version for distribution, bump the
build number in the BUNDLE-VERSION file.
Change-Id: I1e7e55528aef6d3526ce14d070ae96abc5931f38
Lets leave this optimization for later, this is incomplete, and does not
fix the problem which it was originally supposed to address.
This reverts commit bce922e8fd.
Change-Id: I5d2ee19058261c7612d36014181f509604c8acde
Yeah, a bit silly to have to do git commit for these bumps. I should
change things so that CFBundleVersion is taken from some local file in
the build tree, not from a file in git.
Change-Id: I99d68490aa7f084e8cfb34896c3398486bc6f8a2
Add two settings: One setting "Template list URL" is a string that
should either be empty (the typical case for a random user of the
app), or contain a https: URL. If this setting is empty, only the
templates bundled in the app are provided.
If the "Template list URL" is non-empty, it should be a https: URL
pointing to a text file (or dynamically generated text resource). That
file is downloaded and read when the app starts. Each line in the file
should either be a comment (starting with a hash '#'), or a https: URL
pointing to a template document, that is of type .ott, .ots, or .otp.
That document is downloaded if it hasn't been downloaded already, or
if its time stamp is newer than that of the already downloaded copy.
Also a thumbnail image for the template, formed by appending ".png" to
its URL, is downloaded, if available.
Any previously downloaded templates that aren't mentioned in the list
file are removed.
The intent is that in some managed mass deployment environment, the
mobile device management software would set up this setting, so that
the end-user devices would see the same templates.
Obviously, this URL does not have to point to a static file on a web
server, but could point to some dynamically generated resource on a
web server, that enumerates the templates available on the server and
returns their URLs as a text document.
Another setting is "Empty tile cache next time". This is a toggle. If
toggled on, the next time a document is opened in the app, the tile
cache is emptied (and the toggle is reset off). This is mostly for
potential problem solving, and might be removd later.
Various refactoring to support the new functionality.
Change-Id: Ie2ebf032acb9e43bb1c6f7ae4d0c449ae66eaa05
This is a somewhat temporary quick solution. It bluntly uses the same
code here that I had added for a while as the implementation of
translateGet() for LibreOfficeKitClass in LO core.
Ideally we should have a script here in online to pick the needed
translation from the translations submodule of core and keep them
around even if a translation happens to evaporate from
core/translations. The same idea as in the scripts/unocommands.py, but
I did not yet start modifying or copying that.
Change-Id: I455ad6044e321ef59873d60f8e5f3e7032f2447e
Now it finally looks like I want, but oh boy was that a pain. I am not
sure at all I understand what I am doing in Xcode's Interface Builder.
I tried hard at first to use the cell size 200x220 for the cell size
of the UICollectionView, consisting of a 200x200 UIImageView and a
200x20 UILabel below. But that did not seem to work, it still used a
(default?) size of 150x150. Weird. Anyway, let's commit this state now
that seems to work.
Change-Id: I4021133619fbf62cd633392d93f19c2bbc81311a
Add such thumbnails. Rename the presentation templates to not have
colons in their name, as that seems to be problematic for macOS and/or
iOS, sigh. (Shadows of pre-OS X MacOS, where the coln was the path
component separator, not the slash.)
Hack on the storyboard scene for the template browser. More work is
needed there; the thumbnails aren't scaled down for some reason. I
need to make sure the aspect ratio is maintained, too. Maybe to get it
to look like I want I need to do some coding and not just tweak the
storyboard in the Xcode UI designer, sigh.
Change-Id: I959d051352c2f033c8563188155af5281961c7d8
Using a template has been implemented to work in a way more
appropriate for the platform.
There is little reason to allow direct opening of a template in the
iOS app as long as it don't have any way to save it as an actual
document, based on the template, after editing, (with a different file
name) anyway.
This reverts commit f01a73fa92.
Change-Id: Iff4b2f299c6e6eda27c00e40a49374899af41cf0
It took quite some time for me to understand how to do it. Not sure if
this is The Right Way, but at least it now works better.
The trick was to store the importHandler block as a property of the
TemplateCollectionViewController and call it when the right template
has been selected.
There is no need to call the importHandler already in the
documentBrowser:didRequestDocumentCreationWithHandler: instance method
and it would not be possible anyway as there apparently is no way to
have the presentViewController:animated:completion: method work in a
truly modal way, so that it would not return until the selection has
been done.
Change-Id: Ia229500c181844fcd99f1f099b2e6744c22b5266
When the "Create Document" button in the document browser is pressed,
we scan a set of ODF templates in the Templates subfolder of the app
bundle, and we display that list as a collection view. (So far that
view is not interactive, i.e. once it is displayed, you are stuck
there.)
Eventually, when the user chooses one of the templates, we will open
that and immediately, before the user has done any edits, do a Save As
of it as a real (not template) document in the app's document folder.
What name to use for it is unclear yet. Further saves will thus don't
need any dialog to choose the document name.
More work will be needed on i18n of the template support. Should we
have localised templates? At least localised template names. Etc.
Change-Id: I5675779a5b16bc4c70a943109aa0dd53cf4bd903
Still need to figure out how to ask the user where to save the
documemnt and under what name when closing it.
Or actually, should ask right away, as iOS apps are supposed to be
crash-proof, there shouldn't be any need for any separate "save" or
"close" operation by the user, right?
Change-Id: I6d6b9933f5e21f7793837c7ed65049b82853a183
It turns out that the view of the DocumentViewController object is
removed from the view hierarchy when the camera is displayed, and
re-added after you choose to use the taken photo. Thus the
viewWillAppear: method is called again at that stage. The Document
object is stil quite intact, though. We should not call the Document
object's openWithCompletionHandler: method again, as that will cause
horrible brokenness.
Change-Id: Ib79bd8f292b01a19866278c4d95a2e816dcd9235
Tor Lillqvist
tamer dab
日陰のコスモス
Andras Timar
koffevar
Nnamani Ezinne Martina
Rob Pearson
Allan Nordhøy
Andrea Gelmini
Szymon Kłos
Muhammet Kara
Jan Holesovsky
Miklos Vajna
Michael Meeks
Tomaž Vajngerl
Tor Lillqvist