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>
... in order to have languages agnostic templates.
fo:language="en" fo:language="US" was removed from styles.xml
Change-Id: I680809d33cb902fc447ea5393d7f8dad3d83cbfc
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
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
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
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
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
