When a tile is requested, don't create anything yet, just send the request.
Create the tile after we actually get it from the server.
This is in preparation for the cancellation of the tiles requests.
Implementing this Was harder than I first expected. The basic idea is as
follows: The master process puts each message arriving from a client that
isn't "canceltiles" into a (client-specific) queue. A separate thread that
pulls messages from the queue at its own pace and handles them as
before. Incoming "canceltiles" messages are handled specially, though: The
queue is emptied of "tile" messages.
The above sounds simple but there are several details that were a bit tricky
to get right.
The keypress and keycode = 13 are converted to click event,
so Calc Application does not receive keypress RETURN, It is needed
to commit changes into cell.
Even though it is set in /etc/sysconfig/loolwsd, it expands to nothing when
used in the loolwsd.services file. Oh well. Let's hardcode a value of 5 for
now.
LibreOffice from TDF, packaged in RPM, does not have proper dependencies as it
is supposed to be usable on different distros and can't know what names are
used for packages for system libraries used, like the one containing
libdbus-glib. But we must have all dependent libraries installed when running
the loolwsd-systemplate-setup command in the %post phase. As this spec file de
facto is for openSUSE 13.2 only anyway, we can find out the package names and
depend on them...
Add the list from running:
rpm -qf --queryformat '%{NAME} ' `find /opt/libreofficedev5.1 -name '*.so' -o -name '*.so.[0-9]*' | while read file; do ldd $file; done | grep -v dynamic | cut -d " " -f 3 | grep -E '^(/lib|/usr)/' | sort -u`
loleaflet only triggers the loading of the tile, and the tile comes sooner or
later whatever we do, so the idea of aborting the loading does not work until
we have server support for that anyway - let's just kill that for now.
They need to be installed before loolwsd is installed, because our %post
action needs to know where LO is installed so that it can create the
systemplate and child-roots directories on the same file system where LO
is. Oh this is crazy and over-engineered. I wonder if it makes sense at all to
even consider packaging this loolwsd in some generically useful way, or if it
should be considered a manual thing for customers / users to install and
configure.
Sadly the TDF builds of LO use the version number in the package names, so we
can't depend on *some* TDF build of LO (like >= 5.0), but must have a specific
version in this spec file. Sigh.
