The main purpose of this time-out is to avoid waiting forever for lost
tile messages, but since it rare to loose them we can use bigger value,
so we can avoid to send new tiles to a slow network.
Note that the used time stamp does not mean the time when the tile
actually send to the client, but the time when it gets to the sender
queue.
Change-Id: I230d85c38b3a5dafd195851d0cf4caac23149e3e
There valid cases when we get unknown tileID. For example we
sent some tiles, but in the meantime canceltiles arrives which
resets tiles-on-fly list, but the client still send tileprocessed
messages for earlier requested tiles.
Change-Id: If2ec015106a0e58d66ae4517b64a9552eb8c38fc
In this case the part number is undefined, somewhere it is set to 0 or 1,
but has no meaning at all. Just avoid using it with text ducments.
Change-Id: Ic98217bf3ea6c86d37c34e42302bf456f7274975
This stuff is a bit fragile, and the presence of other apps on the
device that claim to support "our" file types might, or might not,
affect how it works. Also, upgrading to iOS 12 seemed to have an
effect. Anyway, now it is back to working as I need.
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
No need for explicit "0x" and std::hex when outputting a pointer. A
pointer will be output as a hex number anyway. We used to have things
like this in the log:
TRC #25 Connected to WS Handler 0x0x3610b60| ./net/WebSocketHandler.hpp:80
At least LOOLWSD.cpp has a couple of global variables of types that in
their constructors invoke FakeSocket APIs. If we turn on FakeSocket
logging (fakeSocketSetLoggingCallback()) only in the app's
initialization code, we will miss logging from those global variable
constructors.
Sure, the clean solution would be to turn those global variables into
members in the LOOLWSD class instead, but this will do for now.
Not sure whether the shutdown() implementation matches real shutdown()
semantics, especially with regards to the behaviour of poll(), read(),
and write() (on both the socket itself and the connectd one)
afterwards. But let's see.
The feed() API turned out to be not needed. (And in any case, it was
suposed to be completely equivalent to writing to the peer socket.)
Won't actually be needed anyway, the way the code is going in my work
tree.
Change-Id: I4480ed59fe96ddcfad8483517f2a23452606f332
Reviewed-on: https://gerrit.libreoffice.org/60576
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
It's easier to either call the function to set the logging callback,
or not, in one place in client code, than to comment in and out all
the logging lines in FakeSocket.cpp as needed.
Change-Id: Id17f7e461c7df817440b47cb3124fcece13b189b
As we use #ifdefs at all call sites anyway (because we don't dare use
the generic overrides of close() etc), we can leave out the parameters
related to actual BSD sockets that we ignore anyway.
"Real" Online always uses non-blocking sockets. We don't need to take
flags for that or check it. We can hardcode such behaviour always.
(Assuing that is what we want; let's see once something works.)
Change-Id: I6863907d71c5599b00ce1f8305a44d41bbaf7bee
That is how Online uses the sockets for communication between the
processes anyway: It send and receives complete WebSocket frames.
Sure, in the mobile case there is just one process, but (I think) we
want to keep the same basic structure anyway, even if "wsd" and "kit"
are just threads. (We probably also want to drop the WebSocket framing
of the messages.)
Change-Id: I2397f321029c1cbbbc448a9b2403ad185a51cf14
Intended as a replacement for the real sockets used for WebSocket IPC
in Online on Linux. The idea is that in a mobile app we don't want to
bother with any actual sockets or WebSocket protocol (because we are
running as a single process after all), but keep much of the code that
thinks it is using such mostly unmodified. Just an idea so far, let's
see how this turns out.
Change-Id: I7878b0db99d9cbf70650227186c1fec9677fa74b
Makes it easier to put a breakpoint in it in Xcode...
Not sure if we have any consistent convention around here anyway about
which member functions should be defined inline in the class
definition in the hpp file, and which ones should be in the cpp file.
We already use a suffix "Interface" for SocketHandlerInterface, so
rename IDocumentManager to DocumentManagerInterface.
Naming "interface" classes with an "I" prefix is C# and COM style.
Sure, that is a convention as good as any other, but let's try to be
consistent within this rather small code-base.
Change-Id: I9c356df327debd780f23ed2b2e6d6e630328861e
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"
We already explicitly check earlier, after attempting to create it,
and log a fatal error and exit on failure.
Change-Id: Ia3fde4026839a255d4d19932300e16a05f9a33d2
Earlier invalidatiles was requested the new tiles too, but now
invalidatetiles + _update makes to request all the visible tiles.
Change-Id: Ib3a07f748d270056d5f30cdb1731b6cf4e63c3ef
Can't say I understand why, but this turned out to not be a good idea
after all. And no, using constexpr did not work either, so I won't
waste any more time on this triviality, but just revert.
This reverts commit 195b88ac8d.
Change-Id: I49f737dc6a36fa4808841cb8e0335246ad8c6d03
Re-think Linux vs mobile ifdefs a bit. Use #ifdef __linux only to
surround code that actually is Linux-specific. Use #ifdef MOBILEAPP
for code that is for a mobile version (with no separste wsd, forkit,
and kit processes, and with no WebSocket protocol used).
Bypass UnitFoo for mobile. Possibly we do want the UnitFoo stuff after
all on mobile, to run in some special testing mode? Hard to say, let's
skipt it for now.
