Re: GSoC 2013: Interactive LyX

On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda sa...@lyx.org wrote: Marcelo Galv?o Póvoa wrote: Please check the description I just sent. These side effects of editing would be handled normally at the internal representation level, the data to be sent are the changes to the textual

Re: GSoC 2013: Interactive LyX

Marcelo Galv?o Póvoa wrote: Just to check whether I understood your concept - you basically want to synchronize the internal lyx structures between peers by using .lyx diffs as transport layer, while hoping that full reconstruction from .lyx diff snippet into lyx internal structure is

Re: GSoC 2013: Interactive LyX

On 02/05/13 12:03, Marcelo Galvão Póvoa wrote: On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda sa...@lyx.org wrote: Marcelo Galv?o Póvoa wrote: Just to check whether I understood your concept - you basically want to synchronize the internal lyx structures between peers by using .lyx diffs as

Re: GSoC 2013: Interactive LyX

On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta tomm...@lyx.org wrote: As an immediate concern, adding to Pavel's ones, I have to say that I'm not so sure that merging different edits on the .lyx file level, very much like a version control system would do in presence of concurrent commits,

Re: GSoC 2013: Interactive LyX

On 05/02/2013 03:01 PM, Tommaso Cucinotta wrote: On 02/05/13 12:03, Marcelo Galvão Póvoa wrote: On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda sa...@lyx.org wrote: Marcelo Galv?o Póvoa wrote: Just to check whether I understood your concept - you basically want to synchronize the internal lyx

Re: GSoC 2013: Interactive LyX

On 05/02/2013 03:16 PM, Nico Williams wrote: On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta tomm...@lyx.org wrote: As an immediate concern, adding to Pavel's ones, I have to say that I'm not so sure that merging different edits on the .lyx file level, very much like a version control system

Re: GSoC 2013: Interactive LyX

On Thu, May 2, 2013 at 2:22 PM, Richard Heck rgh...@lyx.org wrote: On 05/02/2013 03:16 PM, Nico Williams wrote: On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta tomm...@lyx.org wrote: As an immediate concern, adding to Pavel's ones, I have to say that I'm not so sure that merging different

Re: GSoC 2013: Interactive LyX

On 02/05/13 20:30, Nico Williams wrote: In fact, a GSoC project to load/save XML would probably be quite useful. I was just about to suggest you to add such proposal, as it's a long standing issue. It's quite late now, but who knows perhaps a student takes the chance :-). Just, I'd address

Re: GSoC 2013: Interactive LyX

On Thu, May 2, 2013 at 1:36 PM, Pavel Sanda sa...@lyx.org wrote: Marcelo Galv?o Póvoa wrote: Just to check whether I understood your concept - you basically want to synchronize the internal lyx structures between peers by using .lyx diffs as transport layer, while hoping that full

Re: GSoC 2013: Interactive LyX

Marcelo Galv?o Póvoa wrote: earlier. But I don't see this transformation as lossy meaning that unrecoverable information is being discarded, simply because this is how a .lyx file is saved. Yep, what I meant - it's lossy unless you reload whole .lyx file (you want to do that after each

Re: GSoC 2013: Interactive LyX

On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda wrote: > Marcelo Galv?o Póvoa wrote: >> Please check the description I just sent. These side effects of >> editing would be handled normally at the internal representation >> level, the data to be sent are the changes to the textual >>

Re: GSoC 2013: Interactive LyX

Marcelo Galv?o Póvoa wrote: > > Just to check whether I understood your concept - you basically want to > > synchronize the internal lyx structures between peers by using .lyx diffs as > > transport layer, while hoping that full reconstruction from .lyx diff > > snippet > > into lyx internal

Re: GSoC 2013: Interactive LyX

On 02/05/13 12:03, Marcelo Galvão Póvoa wrote: > On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda wrote: >> Marcelo Galv?o Póvoa wrote: >> Just to check whether I understood your concept - you basically want to >> synchronize the internal lyx structures between peers by using .lyx diffs

Re: GSoC 2013: Interactive LyX

On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta wrote: > As an immediate concern, adding to Pavel's ones, I have to say that I'm not > so sure that merging different edits on the .lyx file level, very much like a > version control system would do in presence of concurrent

Re: GSoC 2013: Interactive LyX

On 05/02/2013 03:01 PM, Tommaso Cucinotta wrote: On 02/05/13 12:03, Marcelo Galvão Póvoa wrote: On Thu, May 2, 2013 at 1:43 AM, Pavel Sanda wrote: Marcelo Galv?o Póvoa wrote: Just to check whether I understood your concept - you basically want to synchronize the internal lyx

Re: GSoC 2013: Interactive LyX

On 05/02/2013 03:16 PM, Nico Williams wrote: On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta wrote: As an immediate concern, adding to Pavel's ones, I have to say that I'm not so sure that merging different edits on the .lyx file level, very much like a version control

Re: GSoC 2013: Interactive LyX

On Thu, May 2, 2013 at 2:22 PM, Richard Heck wrote: > On 05/02/2013 03:16 PM, Nico Williams wrote: >> >> On Thu, May 2, 2013 at 2:01 PM, Tommaso Cucinotta wrote: >>> >>> As an immediate concern, adding to Pavel's ones, I have to say that I'm >>> not >>> so sure

Re: GSoC 2013: Interactive LyX

On 02/05/13 20:30, Nico Williams wrote: > In fact, a GSoC project to load/save XML would probably be quite useful. I was just about to suggest you to add such proposal, as it's a long standing issue. It's quite late now, but who knows perhaps a student takes the chance :-). Just, I'd address

Re: GSoC 2013: Interactive LyX

On Thu, May 2, 2013 at 1:36 PM, Pavel Sanda wrote: > Marcelo Galv?o Póvoa wrote: >> > Just to check whether I understood your concept - you basically want to >> > synchronize the internal lyx structures between peers by using .lyx diffs >> > as >> > transport layer, while hoping

Re: GSoC 2013: Interactive LyX

Marcelo Galv?o Póvoa wrote: > earlier. But I don't see this transformation as "lossy" meaning that > unrecoverable information is being discarded, simply because this is > how a .lyx file is saved. Yep, what I meant - it's lossy unless you reload whole .lyx file (you want to do that after each

Re: GSoC 2013: Interactive LyX

Tommaso Cucinotta wrote: For example: -) I know, cases will grow fast... If you suffer from good sleep, then start considering these: - User adds external material (graphics,biblio, whatever). Now what? - User runs various lfuns (and there are tons of doc-changing lfuns, start with

Re: GSoC 2013: Interactive LyX

Nico Williams wrote: You can't do that. Assume chat servers/peers come and go. You don't I don't think we should assume such thing. This is online collaboration. If you go offline, peer has either to wait or become independent and responsible for merging problems not covered by LyX internal

Re: GSoC 2013: Interactive LyX

Nico Williams wrote: What's wrong with version control? - It would be very hard to avoid user assisted merging (online colab mechanism should be transparent to user) - To do this stuff reliably you need much better integration with 3rd party VCS, most probaly including parts of its

Re: GSoC 2013: Interactive LyX

On 30/04/13 23:10, Marcelo Galvão Póvoa wrote: I think the best approach is not treating the LFUN as edits themselves but their effect on the document text instead. Dispatching LFUNs has the advantage of not subverting the way LyX edits docs, internally, and also re-use them. For example, you

Re: GSoC 2013: Interactive LyX

Liviu Andronic wrote: If an image-based approach is adopted, this would remove the need to either implement chat in LyX or implement a LyX buffer in a chat client. Both seem awkward and difficult to achieve. How is this different from what was proposed already in this thread? Basically: Out:

Re: GSoC 2013: Interactive LyX

Marcelo Galv?o Póvoa wrote: On Mon, Apr 29, 2013 at 8:56 PM, Nico Williams n...@cryptonector.com wrote: BTW, this has all been solved before (clearly). Research it and use whatever protocol pattern is most appropriate (or, if you can't because of patents, invent a new protocol). Some

Re: GSoC 2013: Interactive LyX

On Wed, May 1, 2013 at 6:23 AM, Tommaso Cucinotta tomm...@lyx.org wrote: You could, but I'm not sure about what advantage you get. LyX keeps in memory a structured graph of C++ objects, not their serialized version. If you send a serialized paragraph, then you have to de-serialize it replacing

Re: GSoC 2013: Interactive LyX

On Wed, May 1, 2013 at 7:27 AM, Pavel Sanda sa...@lyx.org wrote: I can't comment whether your approach would work, but please think how your approach work with several random bits: - we don't have just linear structure of the document and sometimes distance of change can be tricky thing,

Re: GSoC 2013: Interactive LyX

Marcelo Galv?o Póvoa wrote: Please check the description I just sent. These side effects of editing would be handled normally at the internal representation level, the data to be sent are the changes to the textual representation (ie, modifications that would appear at the LyX file). Just to

Re: GSoC 2013: Interactive LyX

Tommaso Cucinotta wrote: > For example: > -) I know, cases will grow fast... If you suffer from good sleep, then start considering these: - User adds external material (graphics,biblio, whatever). Now what? - User runs various lfuns (and there are tons of doc-changing lfuns, start with

Re: GSoC 2013: Interactive LyX

Nico Williams wrote: > You can't do that. Assume chat servers/peers come and go. You don't I don't think we should assume such thing. This is online collaboration. If you go offline, peer has either to wait or become independent and responsible for merging problems not covered by LyX internal

Re: GSoC 2013: Interactive LyX

Nico Williams wrote: > What's wrong with version control? - It would be very hard to avoid user assisted merging (online colab mechanism should be transparent to user) - To do this stuff reliably you need much better integration with 3rd party VCS, most probaly including parts of its

Re: GSoC 2013: Interactive LyX

On 30/04/13 23:10, Marcelo Galvão Póvoa wrote: > I think the best approach is not treating the LFUN as edits themselves > but their effect on the document text instead. Dispatching LFUNs has the advantage of not subverting the way LyX edits docs, internally, and also re-use them. For example, you

Re: GSoC 2013: Interactive LyX

Liviu Andronic wrote: > If an image-based approach is adopted, this would remove the need to > either implement chat in LyX or implement a LyX buffer in a chat > client. Both seem awkward and difficult to achieve. How is this different from what was proposed already in this thread? Basically:

Re: GSoC 2013: Interactive LyX

Marcelo Galv?o Póvoa wrote: > On Mon, Apr 29, 2013 at 8:56 PM, Nico Williams wrote: > > BTW, this has all been solved before (clearly). Research it and use > > whatever protocol pattern is most appropriate (or, if you can't > > because of patents, invent a new protocol). >

Re: GSoC 2013: Interactive LyX

On Wed, May 1, 2013 at 6:23 AM, Tommaso Cucinotta wrote: > You could, but I'm not sure about what advantage you get. LyX keeps in > memory a structured graph of C++ objects, not their serialized version. > If you send a serialized paragraph, then you have to de-serialize it >

Re: GSoC 2013: Interactive LyX

On Wed, May 1, 2013 at 7:27 AM, Pavel Sanda wrote: > I can't comment whether your approach would work, but please think > how your approach work with several random bits: > > - we don't have just linear structure of the document and sometimes > distance of change can be tricky

Re: GSoC 2013: Interactive LyX

Marcelo Galv?o Póvoa wrote: > Please check the description I just sent. These side effects of > editing would be handled normally at the internal representation > level, the data to be sent are the changes to the textual > representation (ie, modifications that would appear at the LyX file). Just

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 12:09 AM, Tommaso Cucinotta tomm...@lyx.org wrote: OTOH interactive LyX seems to be really worth and requested feature while the chat looks more like a toy with the aroma of the word bloat around (sorry for the punch :) I'm not sure here: AFAICS, I'd see myself more

Re: GSoC 2013: Interactive LyX

I must admit that I share Pavel's sentiment: I'm not sure how much the community needs/requires a chatting function in LyX. But I was thinking of possibly a cheap workaround: Why not communicate with images? Good point. In the age of Skype etc., and with many existing good chat clients, why

Re: GSoC 2013: Interactive LyX

On 30/04/13 08:49, Liviu Andronic wrote: But I was thinking of possibly a cheap workaround: Why not communicate with images? hmmm.. that sounds like a hack.., would usability be the same ? or the user would have to switch back and forth among the chat client and lyx to do this, for handling

Re: GSoC 2013: Interactive LyX

On 30/04/13 00:23, Nico Williams wrote: Well... If a paragraph is deleted then the pointer might get assigned in a subsequent allocation and... you end up with an aliasing problem. I was thinking of detecting this problem when you delete a par, going through the cursors/pointers potentially

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 10:16 AM, Tommaso Cucinotta tomm...@lyx.org wrote: On 30/04/13 08:49, Liviu Andronic wrote: But I was thinking of possibly a cheap workaround: Why not communicate with images? hmmm.. that sounds like a hack.., would usability be the same ? or the user would have to

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 2:49 AM, Liviu Andronic landronim...@gmail.com wrote: I must admit that I share Pavel's sentiment: I'm not sure how much the community needs/requires a chatting function in LyX. But I was thinking of possibly a cheap workaround: Why not communicate with images? LyX

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 3:26 AM, Tommaso Cucinotta tomm...@lyx.org wrote: On 30/04/13 00:23, Nico Williams wrote: Well... If a paragraph is deleted then the pointer might get assigned in a subsequent allocation and... you end up with an aliasing problem. I was thinking of detecting this

Re: GSoC 2013: Interactive LyX

Hello. In my opinion, cooperative editing the same paragraph does not make sense. I will be annoyed if the paragraph I am editing change from time to time making the structure and meaning and everything a mess. I suggest that we could simply lock that paragraph while others can commenting on it,

Re: GSoC 2013: Interactive LyX

On Mon, Apr 29, 2013 at 8:56 PM, Nico Williams n...@cryptonector.com wrote: BTW, this has all been solved before (clearly). Research it and use whatever protocol pattern is most appropriate (or, if you can't because of patents, invent a new protocol). Some posts on this list pointed at some

Re: GSoC 2013: Interactive LyX

On 30/04/13 10:51, Nico Williams wrote: Part of the XMPP/whatever fabric gets disconnected from the rest. Now you have two LyX instances collaborating but unable to reach each other. What do you do now? If each user is allowed to keep making changes that are not acknowledged by the other

Re: GSoC 2013: Interactive LyX

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

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 3:41 PM, Tommaso Cucinotta tomm...@lyx.org wrote: On 30/04/13 10:51, Nico Williams wrote: Part of the XMPP/whatever fabric gets disconnected from the rest. Now you have two LyX instances collaborating but unable to reach each other. What do you do now? If each user

Re: GSoC 2013: Interactive LyX

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

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 12:09 AM, Tommaso Cucinotta wrote: >> OTOH interactive LyX seems to be really worth and requested feature while the >> chat looks more like a toy with the aroma of the word "bloat" around (sorry >> for >> the punch :) > > I'm not sure here: AFAICS, I'd

Re: GSoC 2013: Interactive LyX

I must admit that I share Pavel's sentiment: I'm not sure how much the community needs/requires a chatting function in LyX. But I was thinking of possibly a cheap workaround: Why not communicate with images? Good point. In the age of Skype etc., and with many existing good chat clients, why

Re: GSoC 2013: Interactive LyX

On 30/04/13 08:49, Liviu Andronic wrote: > But I was > thinking of possibly a cheap workaround: Why not communicate with > images? hmmm.. that sounds like a hack.., would usability be the same ? or the user would have to switch back and forth among the chat client and lyx to do this, for handling

Re: GSoC 2013: Interactive LyX

On 30/04/13 00:23, Nico Williams wrote: > Well... If a paragraph is deleted then the pointer might get assigned > in a subsequent allocation and... you end up with an aliasing problem. I was thinking of detecting this problem when you delete a par, going through the cursors/pointers potentially

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 10:16 AM, Tommaso Cucinotta wrote: > On 30/04/13 08:49, Liviu Andronic wrote: >> But I was >> thinking of possibly a cheap workaround: Why not communicate with >> images? > > hmmm.. that sounds like a hack.., would usability be the same ? or the > user

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 2:49 AM, Liviu Andronic wrote: > I must admit that I share Pavel's sentiment: I'm not sure how much the > community needs/requires a chatting function in LyX. But I was > thinking of possibly a cheap workaround: Why not communicate with > images?

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 3:26 AM, Tommaso Cucinotta wrote: > On 30/04/13 00:23, Nico Williams wrote: >> Well... If a paragraph is deleted then the pointer might get assigned >> in a subsequent allocation and... you end up with an aliasing problem. > > I was thinking of detecting

Re: GSoC 2013: Interactive LyX

Hello. In my opinion, cooperative editing the same paragraph does not make sense. I will be annoyed if the paragraph I am editing change from time to time making the structure and meaning and everything a mess. I suggest that we could simply lock that paragraph while others can commenting on it,

Re: GSoC 2013: Interactive LyX

On Mon, Apr 29, 2013 at 8:56 PM, Nico Williams wrote: > BTW, this has all been solved before (clearly). Research it and use > whatever protocol pattern is most appropriate (or, if you can't > because of patents, invent a new protocol). > > Some posts on this list pointed

Re: GSoC 2013: Interactive LyX

On 30/04/13 10:51, Nico Williams wrote: > Part of the XMPP/whatever fabric gets disconnected from the rest. Now > you have two LyX instances collaborating but unable to reach each > other. What do you do now? If each user is allowed to keep making > changes that are not acknowledged by the

Re: GSoC 2013: Interactive LyX

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

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 3:41 PM, Tommaso Cucinotta wrote: > On 30/04/13 10:51, Nico Williams wrote: >> Part of the XMPP/whatever fabric gets disconnected from the rest. Now >> you have two LyX instances collaborating but unable to reach each >> other. What do you do now? If

Re: GSoC 2013: Interactive LyX

On Tue, Apr 30, 2013 at 6:06 PM, Tommaso Cucinotta 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

Re: GSoC 2013: Interactive LyX

On 21/04/13 20:56, Pavel Sanda wrote: lyx internals, as you say, multiple Cursors, or as said in some other thread, if we should switch from index-based to ptr-based CursorSlice, etc... I'm pessimist that newcomer in the project should start substantial cursorslice refactoring. There are

Re: GSoC 2013: Interactive LyX

On Sat, Apr 20, 2013 at 7:06 AM, Vinícius dos Santos Oliveira vini.ipsma...@gmail.com wrote: 2013/4/20 Tommaso Cucinotta tomm...@lyx.org 3) client-side encryption add-on: can we exchange b64 encoding of client-side encrypted text segments, so that IM servers cannot see what's being

Re: GSoC 2013: Interactive LyX

On Sat, Apr 20, 2013 at 5:33 AM, Tommaso Cucinotta tomm...@lyx.org wrote: Concerning the interactive editing, I also remembered some critical issues faced during my prior quick hack: LyX internally uses index positions for the cursor, i.e., my cursor is on the 3rd paragraph, 5th character,

Re: GSoC 2013: Interactive LyX

On 20/04/13 10:19, Tommaso Cucinotta wrote: So, as I said earlier, since the project already seems quite large as is, it would be better to discuss a list of deliverables for the GSoC and how they should be implemented. As for intermediate checkpoints within the project, for the chat: 1)

Re: GSoC 2013: Interactive LyX

On 29/04/13 23:32, Nico Williams wrote: However, when considering that other users might be editing stuff above/before our cursor position, then it means this way of referencing positions within the text should be changed/reworked to a pointer-based one. But what alternative addressing

Re: GSoC 2013: Interactive LyX

On 29/04/13 23:26, Nico Williams wrote: It's possible to use OTR: http://en.wikipedia.org/wiki/Off-the-Record_Messaging Yes. Let libpurple (or similar) take care of this for you. Are you aware of a similar library for Qt-oriented projects ? Any comment on, or experience with, qxmpp --

Re: GSoC 2013: Interactive LyX

On Mon, Apr 29, 2013 at 6:06 PM, Tommaso Cucinotta tomm...@lyx.org wrote: On 29/04/13 23:26, Nico Williams wrote: It's possible to use OTR: http://en.wikipedia.org/wiki/Off-the-Record_Messaging Yes. Let libpurple (or similar) take care of this for you. Are you aware of a similar library

Re: GSoC 2013: Interactive LyX

On 30/04/13 00:06, Tommaso Cucinotta wrote: Any comment on, or experience with, qxmpp -- http://code.google.com/p/qxmpp/ ? This can be useful for applicants to look at http://doc.qxmpp.org/qxmpp-snapshot/classQXmppRosterManager.html#a978cf900248b0ef144460bb52052ded8 to get a feeling of how

Re: GSoC 2013: Interactive LyX

On 30/04/13 00:11, Nico Williams wrote: But do you want to reuse an OTR implementation? The question is why OTR, but perhaps the answer is simply that is already made to be compatible with messaging protocols. However, security may be one of the optional add-on / separate work-items / fine

Re: GSoC 2013: Interactive LyX

On Mon, Apr 29, 2013 at 6:03 PM, Tommaso Cucinotta tomm...@lyx.org wrote: On 29/04/13 23:32, Nico Williams wrote: However, when considering that other users might be editing stuff above/before our cursor position, then it means this way of referencing positions within the text should be

Re: GSoC 2013: Interactive LyX

On Mon, Apr 29, 2013 at 6:21 PM, Tommaso Cucinotta tomm...@lyx.org wrote: On 30/04/13 00:11, Nico Williams wrote: But do you want to reuse an OTR implementation? The question is why OTR, but perhaps the answer is simply that is already made to be compatible with messaging protocols. OTR is

Re: GSoC 2013: Interactive LyX

On 30/04/13 00:03, Tommaso Cucinotta wrote: For example: -) when inserting a new character (LFUN_SELF_INSERT): for each cursor in same par in positions beyond this, do a pos++ -) when inserting a new par (on Enter): for each cursor in later pars, do a pit++ -) others for cut'n'paste,

Re: GSoC 2013: Interactive LyX

BTW, this has all been solved before (clearly). Research it and use whatever protocol pattern is most appropriate (or, if you can't because of patents, invent a new protocol). Some posts on this list pointed at some such prior work.

Re: GSoC 2013: Interactive LyX

On 21/04/13 20:56, Pavel Sanda wrote: >> lyx internals, as you say, multiple Cursors, or as said in some other >> thread, if >> we should switch from index-based to ptr-based CursorSlice, etc... > > I'm pessimist that newcomer in the project should start substantial > cursorslice > refactoring.

Re: GSoC 2013: Interactive LyX

On Sat, Apr 20, 2013 at 7:06 AM, Vinícius dos Santos Oliveira wrote: > 2013/4/20 Tommaso Cucinotta >> >> 3) client-side encryption add-on: can we exchange b64 encoding of >> client-side >>encrypted text segments, so that IM servers cannot see what's

Re: GSoC 2013: Interactive LyX

On Sat, Apr 20, 2013 at 5:33 AM, Tommaso Cucinotta wrote: > Concerning the interactive editing, I also remembered some critical issues > faced > during my prior quick hack: LyX internally uses index positions for the > cursor, > i.e., my cursor is on the 3rd paragraph, 5th

Re: GSoC 2013: Interactive LyX

On 20/04/13 10:19, Tommaso Cucinotta wrote: >> So, as I said >> earlier, since the project already seems quite large as is, it would >> be better to discuss a list of deliverables for the GSoC and how they >> should be implemented. > > As for intermediate checkpoints within the project, for the

Re: GSoC 2013: Interactive LyX

On 29/04/13 23:32, Nico Williams wrote: >> However, when considering that other users might be editing stuff >> above/before our >> cursor position, then it means this way of referencing positions within the >> text >> should be changed/reworked to a pointer-based one. > > But what alternative

Re: GSoC 2013: Interactive LyX

On 29/04/13 23:26, Nico Williams wrote: >> It's possible to use OTR: >> http://en.wikipedia.org/wiki/Off-the-Record_Messaging > > Yes. Let libpurple (or similar) take care of this for you. Are you aware of a similar library for Qt-oriented projects ? Any comment on, or experience with, qxmpp --

Re: GSoC 2013: Interactive LyX

On Mon, Apr 29, 2013 at 6:06 PM, Tommaso Cucinotta wrote: > On 29/04/13 23:26, Nico Williams wrote: >>> It's possible to use OTR: >>> http://en.wikipedia.org/wiki/Off-the-Record_Messaging >> >> Yes. Let libpurple (or similar) take care of this for you. > > Are you aware of a

Re: GSoC 2013: Interactive LyX

On 30/04/13 00:06, Tommaso Cucinotta wrote: > Any comment on, or experience with, qxmpp -- http://code.google.com/p/qxmpp/ ? This can be useful for applicants to look at http://doc.qxmpp.org/qxmpp-snapshot/classQXmppRosterManager.html#a978cf900248b0ef144460bb52052ded8 to get a feeling of how

Re: GSoC 2013: Interactive LyX

On 30/04/13 00:11, Nico Williams wrote: > But do you want to reuse an OTR > implementation? The question is why OTR, but perhaps the answer is simply that is already made to be compatible with messaging protocols. However, security may be one of the optional add-on / separate work-items / fine

Re: GSoC 2013: Interactive LyX

On Mon, Apr 29, 2013 at 6:03 PM, Tommaso Cucinotta wrote: > On 29/04/13 23:32, Nico Williams wrote: >>> However, when considering that other users might be editing stuff >>> above/before our >>> cursor position, then it means this way of referencing positions within the >>>

Re: GSoC 2013: Interactive LyX

On Mon, Apr 29, 2013 at 6:21 PM, Tommaso Cucinotta wrote: > On 30/04/13 00:11, Nico Williams wrote: >> But do you want to reuse an OTR >> implementation? > > The question is why OTR, but perhaps the answer is simply that is already > made to be compatible with messaging

Re: GSoC 2013: Interactive LyX

On 30/04/13 00:03, Tommaso Cucinotta wrote: > For example: > -) when inserting a new character (LFUN_SELF_INSERT): >for each cursor in same par in positions beyond this, do a pos++ > -) when inserting a new par (on Enter): >for each cursor in later pars, do a pit++ > -) others for

Re: GSoC 2013: Interactive LyX

BTW, this has all been solved before (clearly). Research it and use whatever protocol pattern is most appropriate (or, if you can't because of patents, invent a new protocol). Some posts on this list pointed at some such prior work.

Re: GSoC 2013: Interactive LyX

On 20/04/13 21:25, Pavel Sanda wrote: As proposed by someone else it might have even more sense to think about chat project as pidgin/... add-on than lyx feature. Yes, we might think of packing the LyX editor feature so that you can reuse it plugging it into another software, and actually I

Re: GSoC 2013: Interactive LyX

Tommaso Cucinotta wrote: Now, a LyX panel showing a list of users by enumerating them through some library call and handling the session state, does not seem to be such a big code base to pull into LyX, am I wrong ? Panel showing list of strings is not problem, I'm concerned about the

Re: GSoC 2013: Interactive LyX

On 20/04/13 21:25, Pavel Sanda wrote: > As proposed by someone else it might have even more sense to think > about chat project as pidgin/... add-on than lyx feature. Yes, we might think of "packing" the LyX editor feature so that you can reuse it plugging it into another software, and actually

Re: GSoC 2013: Interactive LyX

Tommaso Cucinotta wrote: > Now, a LyX panel showing a list of users by enumerating them through some > library call and handling the session state, does not seem to be such a big > code base to pull into LyX, am I wrong ? Panel showing list of strings is not problem, I'm concerned about the

Re: GSoC 2013: Interactive LyX

On 20/04/13 00:54, Marcelo Galvão Póvoa wrote: I checked and and it seems libpurple can handle multiple IM protocols at once, but using it directly would require creating new interfaces inside LyX for authentication, contacts list, etc. I just found a few pointers of attempts to build a Qt

Re: GSoC 2013: Interactive LyX

On 20/04/13 10:19, Tommaso Cucinotta wrote: As for the more challenging interactive lyx project, I'm not sure any of these pre-existing IM infrastructures are appropriate, the key issue being how long a message takes to be delivered to the destination. For IM chats, I wouldn't expect a server

Re: GSoC 2013: Interactive LyX

2013/4/20 Tommaso Cucinotta tomm...@lyx.org 3) client-side encryption add-on: can we exchange b64 encoding of client-side encrypted text segments, so that IM servers cannot see what's being exchanged ? It's possible to use OTR: http://en.wikipedia.org/wiki/Off-the-Record_Messaging --

Re: GSoC 2013: Interactive LyX and Google Docs

The API isn't open at this point, there's a simple integration that we made available that you can see here: https://spandex.io/api/simple-site-integration-post https://spandex.io/api/simple-site-integration-get But it's not sufficient for this use. We're still designing the API and are hoping

Re: GSoC 2013: Interactive LyX and Google Docs

2013/4/20 Gregori Kanatzidis kanatzid...@gmail.com We're still designing the API and are hoping to be able to start opening up more relevant parts of it in a couple of weeks. I don't know if it will be fast enough. Student application proposals ends in may 3. But it's excellent news anyway.

Re: GSoC 2013: Interactive LyX

Tommaso Cucinotta wrote: (things like searching for and adding friends may be handled through an external client Yep, we need to outsource this business out of lyx as much as possible because of the maintenance pain. As proposed by someone else it might have even more sense to think about

  1   2   >