On 02/01/2012 17:04, Tommaso Cucinotta wrote:
Il 02/01/2012 14:47, Abdelrazak Younes ha scritto:
No, not if you create a new BufferView. In this case all mouse
related action needs to be forwarded as well.
what I mean, is that locally I can have no clue (and I should not have
it) about the window and view geometry of the remote LyX instance.
Therefore, if the remote user clicks or selects with the mouse, then
these coordinates cannot make any sense for me. On the other hand, if
the remote LyX instance decodes the mouse action by using its own
metrics etc., then it forwards to me an equivalent (non-mouse) LFUN
(e.g., an LFUN commanding to issue a Cursor::putSelectionAt() encoding
someway the desired cursor position and selection length), then I'm
perfectly able to execute it locally.
As a first step you could add the BufferView size in an LFUN which will
be transmitted at the beginning of the connection. But I agree the local
user should not be interested in those.
As a bonus, you will be able to see exactly what the remote colleague
is doing. But this BufferView shall be read-only for the local guy.
If you want to edit this Buffer, you have to create a new editable
BufferView on the same Buffer (which will be forwarded as read-only
to the remote guy). In this new WorkArea, you'll be able of course to
see the remote Buffer change. You can now split the view to see the
two BufferView at the same time.
I'm not sure I understood what you suggested here.
My point is that I don't want my local BufferView cursor to be moved by
the remote guy and vice versa. Keeping 2 BufferViews with two cursors is
much simpler than cleaning up all the LFUNs that requires a cursor.
In order for this scheme to work smoothly, you'll need first to let
the remote BufferView be handled in a dedicated thread.
That's surely useful for avoiding that a network temporary delay
causes my LyX instance to hand while receiving an LFUN from remote.
Second, all methods that modify the Buffer contents needs to be
protected by mutexes. All in all, a lot of small work but not very
difficult.
This is not strictly needed, as my current scheme (periodic polling)
may still be reused, by having the thread receiving from the socket
push the received LFUN on a local LFUN queue, protected by a mutex,
then LyX could simply periodically poll (in a non-blocking way) from
such a queue, then issue the LFUNs locally. This allows to not spread
mutexes across the whole LyX code, i.e., keep its current
single-threaded orientation and still be able to receive and send
through the remote socket(s). Only the LFUN queue would need mutex
protection :-).
You don't need polling if you use QTcpSocket::readyRead() signal.
Abdel.
