Which is sometimes stored in a bool, but when auto is used, it's char*,
so it helps to have that written explicitly.
Change-Id: I561692e8d5c575b4ff8612fd50e489ad3c60d655
This minimizes unlocking and relocking
on the LOK Document.
Change-Id: Ibe5045c82008df907dc329c1530cb50138b0c211
Reviewed-on: https://gerrit.libreoffice.org/29545
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
By default LOK doesn't provide the part where the invalidated
tile is. The part # is found using API, but due to the fact
that callbacks are processed asynchronously, the part #
may well have changed by the time the invalidation is
processed. This could result in buggy invalidations
where no modification took place.
With the new API flag LOK_FEATURE_PART_IN_INVALIDATION_CALLBACK
the part # is included in the callback, which is parsed
and used to inform the client with the correct part #.
Change-Id: Ibd85764bfdc41ebf1aae490df335bd503284ae91
Reviewed-on: https://gerrit.libreoffice.org/29467
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Instead of trying to inform the sysadmin (which we did not yet try to
do in any meaningful way), inform all connected clients (even those
editing other documents).
We use 'error: cmd=internal kind=diskfull' as the message to the
clients. The loleaflet code needs to be updated to handle that
carefully by displaying a very prominent message that tells the user
that all bets are off.
Also add a unit test for the functionality.
Document the new protocol details.
The code for this alert functionalty became a bit less elegant than I
like because of the way we include Util.cpp in the unit test 'test'
program.
Still need to add code to check for disk full in more places, not just
when saving a cached tile or font. Probably we should even actually
check for disk space on the file system(s) we use getting alarmingly
low, not just check for file writing operations that fail. Later.
The missing init of mutexes is probably theoretical, the TraceFile and
the Unit ones were real errors, I think.
Change-Id: If19c23a9c93d34059998346af8d45c26a34043a6
Instead of 2 queues and 2 threads, merge those to one - which gives a perfect
ordering of the invalidations and rendering.
Change-Id: I229dfc08b43e6ce7e4f08ea8059d3298d9bf8f8a
Reviewed-on: https://gerrit.libreoffice.org/29282
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This replaces addview/remview/remallview messages in the protocol
with 'viewinfo' message which is sent whenever there is any
change in the view information.
Let the client deal with what information is redundant to it.
Change-Id: Ic470ea88a94ff281a0ae021014a9fba1b876f648
On destroyView Core must flush the events queue, otherwise
by the next idle the descriptor will be gone and we'll
be using freed memory.
Change-Id: I6d3d8f9461bc156383a7294e9c65c535d79f2e7a
Reviewed-on: https://gerrit.libreoffice.org/29088
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Seems to fix the deadlock problem, or at least makes it very much
rarer. (I am not entirely certain that a callback might not be in
progress already (in another thread) when we turn off callbacks, and
in that case the callback might still then access freed memory?)
If the connection thread is not running when loading a
document, the callback will drop events. This can happen
when the thread is too slow to spawn, but we return from
the createSession function and process client messages.
This should solve the race where we lose notifications of
other views when a new view is created.
Change-Id: Ia79739889b2f01fbb374d48eb33620084f4ed1c1
Reviewed-on: https://gerrit.libreoffice.org/29063
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Act as if it was always set.
The ChildSession::_multiView field will always be true, so factor it
out. Ditto for Document::_multiView.
The ClientSession::_haveEditLock will also be always true, so factor
it out. This means the ClientSession::isEditLocked() will always
return true, so factor it out, too.
ClientSession::markEditLock() always will always set _haveEditLock to
true (which it will be from the constructor already anyway) so it can
be removed.
ClientSession::setEditLock() does not need a parameter as the
parameter was actually only used for misleading logging. The msg
variable constructed in the function used isEditLocked(), not the
parameter.
We still generate and handle editlock messages. Not sure whether that
makes any sense, though.
- lok::Document::setCallbackLatch: used on doument loading for
set/unset the latch
- now cell cursors of other views are correctly notified to the new
view
- lok::Document::setCallbackLatch: used by a child session for
set/unset the latch
- lok::Document::registerCallback has a new boolean parameter used for
setting the latch state just before the callback is actually
registered for a (new) view
- now cell cursors of other views are correctly notified to the new
view
Use the existing function notifyOtherSessions() to broadcast the
message.
The function also takes care of sending this message only to
active clients.
Change-Id: I98d40429de17463167a67cb10ba59381a0cbc525
A new queue with own thread now processes tile requests
so we have a chance to cull backlogged tile requests
that have since been invalidated.
This reduces load on the server significantly, especially
with multiple view at different zoom levels, and very fast
typing.
Change-Id: I6599939cd363dc71c30187f40d542aa37260dc56
Reviewed-on: https://gerrit.libreoffice.org/28607
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Not sure what the stop() function should do now, if anything. Maybe
_stop should be kept and actually tested somewhere, like in the third
lambda passed to IoUtil::SocketProcessor() in Connection::run()?
