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 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.
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 :-).
Btw, I have nearly another patch ready which supports multiple connected
peers, and creates a different BufferView for each new remote peer
collaborating.
Bye,
T.
