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.
Be careful in using the definite article for classes that are
instantiated as singletons in a process, and otherwise an indefinite
article. Also mention in which process objects of the type in question
exist.
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 only usecases for using the ChildSession mutex
are during tile rendering in Document. For these
the lok::Document mutex is perfectly fine.
Change-Id: I888e51d7885b05081858bcd55212abe45925e732
Reviewed-on: https://gerrit.libreoffice.org/28295
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>
Callbacks from Core are now per-session and not
shared among all. A new descriptor is used to
help get from the callback to the respective
session.
Change-Id: Ie72771da05eef4760cf01351f7c06c034abf5109
Reviewed-on: https://gerrit.libreoffice.org/28122
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
