By retaining the view-ID to username mapping of disconnected
users we are able to show a disconnected username in the
document repair dialog.
Change-Id: Id08790de31f92653381b6a1525caf044bd875479
Reviewed-on: https://gerrit.libreoffice.org/30216
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This helps debugging and tracing issues as this single log
entry links the three most important pieces together:
the user, how Core references the user's view to a
given document, and how WSD references the same.
Change-Id: I7bf88504b43eed85d40e6f8bc9c3bad713f372da
Reviewed-on: https://gerrit.libreoffice.org/29935
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Writer has only one part for rendering purposes (0).
With the new API that includes the part number in
the INVALIDATE_TILES event, the part number must
be 0, otherwise, there will not be anything to render.
Unfortunately Core issues part number == page number,
which we overwrite with 0 in Online.
Change-Id: I842fdd2f50021334dcd3fa47c0b1c9df34d8c5e1
Reviewed-on: https://gerrit.libreoffice.org/29605
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
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>
... otherwise in some cases viewid that is set internally in core
is different from the one which is being loaded resulting in an
incorrect status message which then leads to lot of other problems as
well.
Change-Id: I8488d7d54b211a6b6f6028128f8dfc3388b73efd
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.
Avoid using the static mutex and instead use
the loKitDocument mutex when accessing the
latter. The static mutex is used only when
accessing the document manager. That is,
only when loading and unloading a document.
For ChildSession members that may
be accessed from both the callback and
incoming web-socket, guard them with the
member mutex.
Finally, move any local data manipulation
outside of locks altogether.
Change-Id: I046906bc6ed7e0b38c309f97836b38e27f9bfc8e
Reviewed-on: https://gerrit.libreoffice.org/29336
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
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
View information as of now includes viewid and username
associated with the view.
Change-Id: If0c4957eb56962eb4b1b1d0c1189dc300fa6b857
Reviewed-on: https://gerrit.libreoffice.org/28482
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
... but no need to notify the one which is just added.
Earlier behavior was notifying only the one which is just added,
which is redundant as same is accomplished by 'status' message.
Change-Id: Ib09424d186c49527b7b9c36fdabf90c31518ee04
Reviewed-on: https://gerrit.libreoffice.org/28395
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
ChildSession cleanup is tricky because it needs
to be cleaned up when the connection is dropped.
The ChildSession itself needs to initiate this
cleanup from Document.
A new approach simplifies the design and correctly
broadcasts remview to all other connections so
they would be able to cleanup visual elements.
Change-Id: I78fd01fb42b801913534c858324c16dd7ad6451d
Reviewed-on: https://gerrit.libreoffice.org/28302
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The new commands help the UI update the cursors and other
visual elements that track views and clients.
Currently, when remview is received loleaflet removes
the associated cursor from the screen.
Change-Id: I03e2f9e3485166adae31de84ae7ac6bd1c85b05d
Reviewed-on: https://gerrit.libreoffice.org/28131
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Each ChildSession had its own thread and queue,
which was an overkill. By moving the LOK callback
handler into Document and handling all events in the
same order that we receive them we reduce resource
consumption without affecting performance.
In fact, performance could improve by avoiding
unnecessary overheads.
Change-Id: Ic2bac0f08c28e91acabd512a704966c6b761fc7c
Reviewed-on: https://gerrit.libreoffice.org/28124
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
