On Tue, Apr 30, 2013 at 6:06 PM, Tommaso Cucinotta <tomm...@lyx.org> wrote: > On 30/04/13 21:12, Marcelo Galvăo Póvoa wrote: >> there are indeed several possible approaches. I will try to briefly >> describe mine and you can comment about its (in)feasibility. > > As you say, your case was far easier, and it seems to correspond to the > simple scenario of editing text in a text-only paragraph. > Criticalities already discussed on the list: keep position as an offset, > it's basically what LyX does, but in a structured form. A Cursor is a > stack of CursorSlice, where each slice is basically a triplet > > <pos, pit, idx> > > where pos indicates the character position in the text, pit (ParagraphIT) > indicates the paragraph number in the multi-paragraph text, idx indicates > what cell of a multi-cell table we're in. Then, we have a stack of these, > because in a given pos we might have, instead of a normal character, a > kind of placeholder indicating there's an inset there. So, we go to the > inset, which in turn is another kind-of LyX text, with potentially its > own multi-paragraph text etc.... > > So, another user edits creating further pars or deleting pars, and we > need to pay attention to cursor positions after them. > >> edits are only of types "insert text" or "delete text", represented as >> (global-offset, type, data), > > pls, have a look at LyXAction.cpp to get a feeling of the possible edit > actions that users might be willing to do (I'm not pretending that all > of them should work in the interactive editing mode -- perhaps we just > allow a subset of them to be used in that mode; ideally, we'd like all > of them to keep working). >
I think the best approach is not treating the LFUN as edits themselves but their effect on the document text instead. Many of them doesn't touch the text, so it's useless to send to the other party. As for the others, the idea is to serialize each one into a string that represent their textual output. For example, it could be translated to LyX file syntax itself, couldn't it? The other party would deserialize this content filling the appropriate LyX data structures. I hope that the LyX functions for Save and Load could be reused for that matter. > Now, the hack I did, was rude: keep the serialized LFUN (in form of > text), send to the other side, reconstruct the LFUN, dispatch it > locally. INCLUDING CURSOR MOVEMENTS, which are relative (go up, go > right one char, etc...). That was causing easy de-synch between the > two sides, about what position the cursor is, when dispatching an > editing LFUN. So, there should be a way to exchange and keep in synch > the cursor position independently of the multiple edits being merged > within the doc. > I had this problem too with my implementation. I could solve it in the following way: just treat the cursor as a dummy edit and add it to the bunch. Its position can be updated using the same algorithm I described. > Good. Doc revision may be helpful. As highlighted by Nico, if we know > the revision against which an editing LFUN dispatch was meant, we might > know what position to affect, but still in case of replay of other users' > concurrent editing LFUNs, the key point is how to translate/transform > the subsequent actions.. > I claim that the sorting algorithm I loosely described works for that purpose (maintaining consistency), assuming that all users generate edits based on the same revision. > would it be applicable to the nested/structured LyX text, as described > above ? or, how to extend it properly in such case ? > As I said, it would require proper (de)serialization to a textual format. >> As someone mentioned, when two users are >> editing too close to each other, there is no correct result for this. > > As I see it, if others' cursors are close to mine, then when I start > typing, LyX should delay a bit the action, so as to ensure I "lock" > some part of text where others wouldn't be able to edit. Then, perhaps > after a time-out I don't edit any more that part, it's released. The > locked part might be highlighted some-way in the GUI, both for the > user with the lock (~~green leftbar or similar), and for the one(s) > without (~~red leftbar or similar). > I agree with Nico here. A lock is not necessary: when someone starts editing a section, the others will see that and shouldn't interfere. > knowing what was changed in each revision, it should be possible to > re-send only the affected/changed parts... > That's a possibility, but one would have to store a history of revisions in case it is needed by someone else. Marcelo
