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 fcdc3b2f892bc2847c777127e20e5e5db096870f)
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>
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
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>
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>
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>
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>
(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
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.
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
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
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
