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
Even if the LO core code, as called by the Online code, already has
saved the document back to the file from which it was loaded, in order
for a file provider extension like NextCloud to notice that, it is
essential to call saveToURL:forSaveOperation:completionHandler:. The
contentsForType:error: method can just return a NSFileWrapper for the
same, already saved, file, though.
Change-Id: Ic063c8603ca38930083866d973e500336cad517e
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.
Also, yes, we do need to turn the coordinate system upside-down from
the top left corner.
On iOS it shouldn't actually be pointer to a pixel char buffer, but a
craphics context reference. (This is how it has been since the
experimental TiledLibreOffice app, maybe five years ago? Sadly it
wasn't documented in the LibreOfficeKit include file. But it is how
LibreOfficeLight used the API, too.)
In TiledLibreOffice we rendered tiles directly into the CALayer of the
view. In this Online-based app we of course do render tiles into pixel
char buffers, just like in real Online, but we need to create bitmap
graphics contexts for them and pass that to paintTile().
Now I get white tiles, not totally zero-filled ones. But still no
document contents rendered.
I don't yet want to change the pBuffer parameter to actually be a
buffer pointer on iOS, too, like on other platforms. Also, changing it
will mean the LibreOfficeLight app would need changing, too, and I
don't feel like doing that. But ideally, sure, that should be done.
Re-think the plumbing between the different parts of the C++ Online
code. Do try to have it work more like in real Online on all but the
lowest socket level. Except that we don't have multiple processes, but
threads inside the same process. And instead of using actual system
sockets for WebSocket traffic between the threads, we use our own
FakeSocket things, with no WebSocket framing of messages.
Reduce the amount of #ifdef MOBILEAPP a bit also by compiling in the
UnitFoo things. Hardcode that so that no unit testing is ever
attempted, though. We don't try to dlopen any library.
Corresponding changes in the app Objective-C code. Plus fixes and
functionality improvements.
Now it gets so far that the JavaScript code thinks it has the document
tiles presented, and doesn't crash. But it hangs occasionally. And all
tiles show up blank.
Anyway, progress.
Change-Id: I769497c9a46ddb74984bc7af36d132b7b43895d4
The app is unimaginatively called "Mobile" for now.
Runs but crashes pretty quickly after loading the document by the LO
core. Will need some heavy changes to get a ClientSession object
created in there, too, to handle the (emulated) WebSocket messages
from the JavaScript. It would then handle some of these messages
itself, and forwards some to the ChildSession, which in this case is
in the same process. Now the messsages from the JavaScript go to a
ChildSession, which is wrong. As the assertion says, "Tile traffic
should go through the DocumentBroker-LoKit WS"
