Similarly to the iOS case seen in #7908 the %SAVED_STATE_UI%
does not get replaced. In mobile apps there is no fileserver
that can replace these variables.
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: Icb7f9d7550b0990cc0ad1d65253773b49ff97795
When building the iOS app, the %SAVED_UI_STATE% does not get
replaced with a quoted string during the build and the resulting
unquoted string causes document loading to stop.
Also, eliminate warnings when running in Xcode by adding missing
CFBundleTypeRole entries in the iOS app's Info.plist.
Signed-off-by: Patrick Luby <guibomacdev@gmail.com>
Change-Id: Ie398955241a078be45af28e54c49387ff673870b
They allow respectively to switch to fullscreen, or to start the
presentation in impress in fullscreen
Action_FullscreenPresentation can get the following arguments:
- StartSlideNumber: the slide to start at
- CurrentSlide: start at the current slide
The options are exclusive to each other. StartSlideNumber takes precedence
Signed-off-by: Hubert Figuière <hub@collabora.com>
Change-Id: I4d97eadf8c119e70e5738df4063d209feb5db793
Before this change, panning a calc spreadsheet would cause the onscreen
keyboard to pop up when in tablet mode. Dismissing the keyboard would
not stop it from being popped up the next time you panned around. This
made it very difficult to pan around spreadsheets in calc without either
using an external keyboard, the mobile app or another device altogether.
This commit introduces a known regression: when you are on a tablet and
have a physical external keyboard, you could previously select the cell
and start typing. Now you must tap into the cell in the same way you
would if you have an onscreen keyboard. This matches the behavior on
mobile devices. I consider this regression a reasonable tradeoff, so
notwithstanding I believe this should be merged.
Additionally, this commit adds 2 POST messages, "Hint_OnscreenKeyboard"
and "Hint_NoOnscreenKeyboard". These can be used to override our guess
if you know more about whether the device has an onscreen keyboard than
we do.
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: I8f3683ccb9e57f0c4a5bf8e415f9aabef917dd78
The new messages are: Collapse_Notebookbar and Extend_Notebookbar
As a side effect they also hide the classic toolbar the same way
Signed-off-by: Hubert Figuière <hub@collabora.com>
Change-Id: Ic9d04876acb06f2885a6be1e171df7f87e513ed8
This is of course for testing locally and as a demo.
This expects the wasm build browser/dist to be located
inside at browser/dist/wasm (which currently is done
manually).
Change-Id: I285177b4f08591cffe772acba531cf1a3434178b
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Without that integrator doesn't know what happened.
We were silently ignoring messages.
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I897a95b343a1b436745816ccbef7656f30981112
it belonged to the removed unused document signing code
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: Idf57b30a508381e02c8d62196de38c828cd77f2f
Added information in help tab (keyboard shortcuts)
- About moving back and forth in between calc sheets using keyboard shortcuts
Signed-off-by: Darshan-upadhyay1110 <darshan.upadhyay@collabora.com>
Change-Id: I7ccbc194fe67fb36f9d68827dfa7c5636c9bc7e8
Signed-off-by: Darshan-upadhyay1110 <darshan.upadhyay@collabora.com>
problem:
till now we used values from DOM elements which were unreliable,
sometimes they are not discoverable due to nested iframs.
That threw some 404 due to incorrect theming path.
Signed-off-by: Pranam Lashkari <lpranam@collabora.com>
Change-Id: Ibc291ce9f64db799095e1edcb14c598bdd085de7
Added toggle button/menu entry for enable/disable accessibility support.
This ui feature is available for Online Writer only.
The button/menu entry is added only when accessibility is enabled at
server level.
That allows to enable/disable accessibility per view.
By default, the accessibility support is disabled.
Anyway the accessibility support state is saved to local storage
if available.
Signed-off-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Change-Id: If5968a47f17922038b9da3d320cbed84ebb7688b
A new section about accessibility has been appended to coolwsd.xml
config file
Signed-off-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Change-Id: I086abdf73646639283eb655ae60f200fb64e495a
In tabbed view when we open help or keyboard shortcts dialog
"button" style of cool-help.html overrides the button.ui-tab.notebookbar.
So all buttons (even in notebook bar) uses dialog buttons'
text-decoration: underline ans pad padding:0
Here we make the dialog's button style to specific that dialogs.
Signed-off-by: Gülşah Köse <gulsah.kose@collabora.com>
Change-Id: Iacaab42efa527fc5c6ada21fd007e4a352912b60
Mobile apps don't substitute these values so set them to zero length
strings.
Also, the iOS app sets the base text direction via the "dir" parameter
so add handling of that parameter in cool.html. TODO: check if the
Android and GTK apps need to implement the "dir" parameter to handle
RTL layout.
Signed-off-by: Patrick Luby <patrick.luby@collabora.com>
Change-Id: Ied8268ec256011281961ef610d53baeee0efe9cd
fetch route_token from indirectionurl and add them in wopisrc
parameter
Signed-off-by: Rash419 <rashesh.padia@collabora.com>
Change-Id: I6e724d0c59e12d4f7f6c125ec076e90d20b9b3c8
Now I hope things are initialised in the right order and the plumbing
gets set up so that messages are passed as expected. It seems to work
most of the time.
Main changes are:
- The online WASM executable is built using the -s MODULARIZE -s
EXPORT_NAME=createOnlineModule options. This means that the WASM
runtime is not automatically initialized and the main() function
is not automatically started. Only when the createOnlineModule()
function is called is that done. Calling exported C/C++ functions
is a little bit more complicated.
- Code to actually Base64-encode strings to be executed as
JavaScript when expected is now present in wasmapp.cpp. (After
being passed through the Base64ToArrayBuffer function on the JS
side.) Whether this is actually necessary is not fully clear, but
to keep the code similar to that in the GTK, iOS, and Android
apps, this is kept as such for now. It would probably work fine to
just directly create the ArrayBuffer in the C++ (using the EM_ASM
magic).
- The COOLWSD::run() function is now run in a separate thread so
that main() can return.
- The FakeWebSocket's onopen() function is now called from
innerMain(), where the HULLO message is sent. It remains a bit
unclear if this really is the ideal place.
In the mobile apps the HULLO message is sent and the onopen()
function is called in the window.socket.onopen() function in
global.js.
But note that despite that the WASM app and the mobile apps are
largely quite similarly constructed and the FakeSocket and
FakeWebSocket plumbing is the same, there is an important
difference. In a mobile app the C++ code is what runs first, and
that then loads the HTML page into WebKit, in which the JS
runs. In the WASM app it is the other way around. The web page is
naturaly the one that is loaded and the JS code then starts
running the C++ code as WASM.
Finally, note that the whole concept that there is a separate "WASM
app" is temporary.
What we eventually want to achieve is that the COOL webpage upon
loading will connect a COOL server. As it does currently. The COOL
server runs the online and core C++ code to load a document, and
renders document tiles and sends those to the client JS code to
dispay.
The new thing will be that, if enabled, in addition to the HTML and JS
resources, the client will also download the WASM code and data
resources. Also, the document and updates to it will be downloaded
while being edited so that a copy can be kept in client memory. But
the WASM code and the downloaded document will remain unused most of
the time. Only if the connection to the COOL server breaks will the JS
start running the WASM code and the JS will talk to online code
running locally as WASM instead of to a COOL server. Obviously there
are still lots of things hanging in the air here regarding how exactly
this will work.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Ib1786a0b485d51797b0f2302d4296aa1ff9df5c1
Also, don't load online.js. It seems that it will be loaded into the
JS "web worker" for each thread automatically by
online.worker.js. (But hmm, what loads online.worker.js? I am probably
completely confused here. Probably getting rid of Qt things
(qtloader.js) and using only JS that Emscripten produces (modified if
necessary) will make things simpler to understand.)
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I050a20a553b7c0f6ebe9db0e7cb9cab2f9829f9e
Obviously just this is not a good reason to involve Qt, but we want
now initially to get something to even show up, so let's start by
using HTML and from the Qt-based WASM-LibreOffice. Let's see.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I7841fce8e5680a983cc00d516c3fca3a6747e9dc
