For now the same as before, 256, for both normal Online and mobile
app. If you want to experiment with another value, you only need to
change it in loleaflet.html.m4. I hope.
Note the FIXME in loleaflet/src/core/Socket.js.
Change-Id: Ic881758d7fa70bbfebcf932b7ed6a1da352e375d
If the document-container has an explicit style attribute, then this
breaks Calc (only Writer was tested before). This restores the correct
Writer/Calc/Impress behavior when the setting is false and keeps correct
behavior with Writer when the setting is true.
Change-Id: I310660e88af4407e521529ec41b5dcb604108bd9
In the mobile app, we don't run loleaflet.html through any filter that
would replace strings like <!--%DOCUMENT_CONTAINER_TOP%-->. We need to
produce a proper loleaflet.html at build time, using m4 for MOBILEAPP
conditionals.
Without this small fix, the loleaflet.html page ended up looking
extremely weird (all white document area), with nothing working.
It's not too easy to customize CSS, so move the top position of the
document container to loleaflet.html, where it's convenient to handle
this.
JS can dynamically query if the menu item should be there, similar to
the about dialog.
Change-Id: I4b2799a41f8ad31e3a9b4983fd1947d2e0363a2b
In loleaflet.html.m4, define a macro MOBILEAPP as true if either
IOSAPP or GTKAPP is true.
Set a window.ThisIsAMobileApp property in either case, and
window.ThisIsTheGtkApp in the GTKAPP case.
The checks for ThisIsTheiOSApp in the JS could in fact all be changed
to check for ThisIsAMobileApp instead, as they were all equally valid
for the gtk+ testbed app. For instance, sending WebKit messages to the
app code works the same way in JavaScript both for iOS and
webkit-gtk+. Which is not surprising, I guess, as the underlying
WebKit is the same.
First steps to modify behaviour in the app case. No query parameters
or WebSocket messages in that case.
Change-Id: I170d46830bb940c5164af3f62b873672373d8f17
The idea is that on a Linux box you have a tree of online that you
configure with --enable-iosapp. Then running 'make' there will only
create the stuff in loleaflet/dist. That loleaflet/dist can then be
copied to the Mac where you build the iOS app.
(To me, this approach seemed for now simpler than to get all the
PKG_CONFIG etc stuff working that running configure normally requires,
and run all the node, npm, and associated crack, on a Mac.)
Change-Id: Id2e495d0521922d0666fdab5fdcb5fcd460136f1
Concatenate and minify all javascript files in the release build but not
in the debug build. Also, it is enabled to use a build directory
Change-Id: Ia120447a827cfe236241ddf188bf43a088f877a7
Reviewed-on: https://gerrit.libreoffice.org/52802
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
