The first child had tracing enabled even after
initial startup is completed. This would leak
user details when anonymization is enabled.
Change-Id: I5325e02d1a1078bff6640af85f5672b556c00aeb
Previously SocketPoll expected to be
running its own thread for polling.
This is unnecessary when we have a
spare thread (e.g. main) that can
(and should, for efficiency) be used
for polling rather than starting
dedicated thread.
Not starting the SocketPoll's thread
and calling SocketPoll::poll() directly
worked, the warning logs on each activity
notwithstanding.
The warnings aren't just noisy, they are
a performance drain as well, and signal
that something is wrong. The new code
now makes the API cleaner and avoids
unnecessary warning logs, while being
faster.
Change-Id: Ibf9a223c59dae6522a5fc2e5d84a8ef191b577b1
Why log something vague like "Stop flagged" when we can log what we
actually do?
Also, the log lines already include the name of the thread, so no need
to prefix with "Kit:".
Change-Id: I5a05492aa4e8a26714889cc6341a26862c80e4d0
Doesn't help my current issue in the iOS app, but the less use of
TerminationFlag the better, I think. (Doesn't break 'make check' on
Linux.)
Change-Id: I8fef271d6e0e81dea92e0da76ecb7211239adab6
Instead we should just exit the thread(s) that serve the document that
was being edited, and the app should return to showing the document
browser. (Or whatever we eventually will have as its state when the
user is not editing or viewing a document.) Work in progress.
I changed the code in this commit:
c2a5f6acb0
To make kit send a tilecombine message even if it does not
send actual tile data so we can track that the rendering was
done and so we can update the clients' _tilesBeingRendered
list. The issue is that tileBeingRendered object
belongs to not only one client, but more and so we don't
know which client gets the actual empty tile response.
So revert this method and rather use a smaller timeout for "waiting" the
arrival of the rendered tile.
Change-Id: I2dbbab1a62b81cbbb5314f2f37fdbc3415c69130
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
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>
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
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.
The needed files were not copied, and consequently the hostname
resolution did not work in the chroot.
Change-Id: Id3dccc4f70cd1deeddb83c8e672f240e06748e34
Although, at least for me, after calling LOK's saveAs with an
intentionally bogus file extension 'file:///user/docs/u0.frobozz'
retrying with 'file:///user/docs/u0.frobozz.odt' does not work either.
Actually, I am not sure how useful this retry feature is as it is now.
If the user tries to save as some unsupported format, why can we
assume that maybe they want to save in some other format instead, and
possibly overwrite an existing file? Maybe the retry should be done
only if the file name to saveAs was without extension? But that was
already discussed in gerrit, I see.
Change-Id: I8bd4fbf241cb492d9654ae893af4baaf28b6b3a0
These are copy-constructed from a const reference but are only used as
const reference; make them a const reference.
Change-Id: Id193905b65224c2db4aab88999a92e60d3af3fdf
Need to get the viewid which moved our visible cursor, so we can check
whether it positioned changed by the owner of the cursor or not.
Change-Id: Ie7b1fafc8d8f11fba0c0b0d5f02d755e15284514
Reviewed-on: https://gerrit.libreoffice.org/52571
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
Last lingering bits are the xpdfimport import support and
some horrors required for NSS.
This requires a reasonably new core.
Change-Id: I2e08b841668722af0e3b947cf2b06687cca73b53
This already worked for normal save, but not for convert-to.
Depends on core.git commit 0518bb5c3a98d973c3675fdd4cb8c52a669a3507
(desktop lok: handle NoFileSync in saveAs(), 2018-03-26).
Change-Id: Iec1a92fba2094f3954cc1a4ed6ee3372076fddc5
