On Sat, Jan 15, 2005 at 11:45:27AM +0100, Andre Poenitz wrote:
On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote:
I didn't know LyX was that clean internally. For most other apps
that would be close to a rewrite of the core parts.
Guess what we did in the 1.4 cycle.
Ain't it great
On Sat, Jan 15, 2005 at 11:45:27AM +0100, Andre Poenitz wrote:
> On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote:
> > I didn't know LyX was that clean internally. For most other apps
> > that would be close to a rewrite of the core parts.
>
> Guess what we did in the 1.4 cycle.
Ain't
I rather think it is the user interface parts that need work in
such a case. The core shouldn't really see the difference between
two users updating one document, or one user moving
rapidly back and forth doing modifications in two places. :-)
Makes sense.
Kuba
Kuba Ober [EMAIL PROTECTED] writes:
I rather think it is the user interface parts that need work in
such a case. The core shouldn't really see the difference between
two users updating one document, or one user moving
rapidly back and forth doing modifications in two places.
Makes
On wtorek 18 stycze 2005 08:49 am, Andreas Vox wrote:
Kuba Ober [EMAIL PROTECTED] writes:
I rather think it is the user interface parts that need work in
such a case. The core shouldn't really see the difference between
two users updating one document, or one user moving
rapidly back
Kuba Ober [EMAIL PROTECTED] writes:
Without special provisions in the core, they would undo the globally most
recent action.
Not nice but simple and save.
Methinks the core has to associate a couple of stately* things with each
client. Undo history being one of them.
And the undo
> I rather think it is the user interface parts that need work in
> such a case. The core shouldn't really see the difference between
> two users updating one document, or one user moving
> rapidly back and forth doing modifications in two places. :-)
Makes sense.
Kuba
Kuba Ober <[EMAIL PROTECTED]> writes:
>
> > I rather think it is the user interface parts that need work in
> > such a case. The core shouldn't really see the difference between
> > two users updating one document, or one user moving
> > rapidly back and forth doing modifications in two places.
On wtorek 18 styczeÅ 2005 08:49 am, Andreas Vox wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> > > I rather think it is the user interface parts that need work in
> > > such a case. The core shouldn't really see the difference between
> > > two users updating one document, or one user moving
>
Kuba Ober <[EMAIL PROTECTED]> writes:
>
> Without special provisions in the core, they would undo the globally most
> recent action.
Not nice but simple and save.
>
> Methinks the core has to associate a couple of stately* things with each
> client. Undo history being one of them.
And the
On Fri, Jan 14, 2005 at 10:53:52AM +0100, Lars Gullik Bjønnes wrote:
I'll describe it as a change in viewpoint: instead of having the core
call the frontend (sounds a bit backwards, right?), we change it so
that it is the frontend that calls the core.
My vision is that the core is almost
On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote:
I didn't know LyX was that clean internally. For most other apps that would
be
close to a rewrite of the core parts.
Guess what we did in the 1.4 cycle.
Andre'
On Fri, Jan 14, 2005 at 10:53:52AM +0100, Lars Gullik Bjønnes wrote:
> I'll describe it as a change in viewpoint: instead of having the core
> call the frontend (sounds a bit backwards, right?), we change it so
> that it is the frontend that calls the core.
>
> My "vision" is that the core is
On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote:
> I didn't know LyX was that clean internally. For most other apps that would
> be
> close to a rewrite of the core parts.
Guess what we did in the 1.4 cycle.
Andre'
Kuba Ober [EMAIL PROTECTED] writes:
| I think we could have saved some time, if we were able to work both on a
| single document at the same time. So I propose a
| server-client-architecture for LyX that works in the same way as the
| team modus of starcraft. One opens a server with the
Lars Gullik Bjønnes wrote:
| I didn't know LyX was that clean internally. For most other apps that
| would be close to a rewrite of the core parts.
Perhaps I am a bit too optimistic :-)
The main work (before splitting in a server and client) would be to
change the interface between core
Angus Leeming [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| I didn't know LyX was that clean internally. For most other apps that
| would be close to a rewrite of the core parts.
Perhaps I am a bit too optimistic :-)
The main work (before splitting in a server and client) would
Kuba Ober wrote:
Man, if you can do it in a week and it works then I'm donating a case
of good
beer (or a monetary equivalent) to the cause (seriously).
I didn't know LyX was that clean internally. For most other apps that would be
close to a rewrite of the core parts.
I rather think it is
Helge Hafting [EMAIL PROTECTED] writes:
| Kuba Ober wrote:
Man, if you can do it in a week and it works then I'm donating a
case of good
beer (or a monetary equivalent) to the cause (seriously).
I didn't know LyX was that clean internally. For most other apps
that would be close to a
Kuba Ober <[EMAIL PROTECTED]> writes:
>> | I think we could have saved some time, if we were able to work both on a
>> | single document at the same time. So I propose a
>> | server-client-architecture for LyX that works in the same way as the
>> | "team modus" of starcraft. One opens a server
Lars Gullik Bjønnes wrote:
> | I didn't know LyX was that clean internally. For most other apps that
> | would be close to a rewrite of the core parts.
>
> Perhaps I am a bit too optimistic :-)
>
> The main work (before splitting in a server and client) would be to
> change the interface between
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | I didn't know LyX was that clean internally. For most other apps that
>> | would be close to a rewrite of the core parts.
>>
>> Perhaps I am a bit too optimistic :-)
>>
>> The main work (before splitting in a server and
Kuba Ober wrote:
Man, if you can do it in a week and it works then I'm donating a case
of good
beer (or a monetary equivalent) to the cause (seriously).
I didn't know LyX was that clean internally. For most other apps that would be
close to a rewrite of the core parts.
I rather think it is
Helge Hafting <[EMAIL PROTECTED]> writes:
| Kuba Ober wrote:
>
>> Man, if you can do it in a week and it works then I'm donating a
>> case of good
>>
>>beer (or a monetary equivalent) to the cause (seriously).
>>
>> I didn't know LyX was that clean internally. For most other apps
>> that would be
Hello,
last year a colleague and me had to write a script for my professor. So we
took our laptops, and wrote the script during the lesson. Of course, we used
LyX for text and formulas and xfig for graphs! My colleague was an faster
typer, so he typed text and me made formulaes and graphs. Our
Tobias Spranger [EMAIL PROTECTED] writes:
| Hello,
| I think we could have saved some time, if we were able to work both on a
| single document at the same time. So I propose a server-client-architecture
| for LyX that works in the same way as the team modus of starcraft. One
| opens a
Lars Gullik Bjønnes wrote:
Actaully this wouldn't be _that_ hard, it is all about having a nice
protocol between the gui and the core. I guess I could do it in a
week. This also fits quite well with some other cleanup that I'd
really like to do, but there are problems as well... security is
Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
Tobias Spranger [EMAIL PROTECTED] writes:
| Hello,
| I think we could have saved some time, if we were able to work both on a
| single document at the same time. So I propose a
server-client-architecture
| for LyX that works in the same
Angus Leeming [EMAIL PROTECTED] writes:
Lars Gullik Bjnnes wrote:
Actaully this wouldn't be _that_ hard, it is all about having a nice
protocol between the gui and the core. I guess I could do it in a
week. This also fits quite well with some other cleanup that I'd
really like to do,
Andreas Vox wrote:
What about the buffer? I think the lyx-paragraphs should be on the
server but the cursor position at the client (I dont know the current
code too well, maybe they are already separated)
They are. This is equivalent to having multiple views into the document.
That's something
| I think we could have saved some time, if we were able to work both on a
| single document at the same time. So I propose a
| server-client-architecture for LyX that works in the same way as the
| team modus of starcraft. One opens a server with the document to edit
| and other people
Hello,
last year a colleague and me had to write a script for my professor. So we
took our laptops, and wrote the script during the lesson. Of course, we used
LyX for text and formulas and xfig for graphs! My colleague was an faster
typer, so he typed text and me made formulaes and graphs. Our
Tobias Spranger <[EMAIL PROTECTED]> writes:
| Hello,
>
| I think we could have saved some time, if we were able to work both on a
| single document at the same time. So I propose a server-client-architecture
| for LyX that works in the same way as the "team modus" of starcraft. One
| opens a
Lars Gullik Bjønnes wrote:
> Actaully this wouldn't be _that_ hard, it is all about having a nice
> protocol between the gui and the core. I guess I could do it in a
> week. This also fits quite well with some other cleanup that I'd
> really like to do, but there are problems as well... security
Lars Gullik BjÃnnes <[EMAIL PROTECTED]> writes:
<
< Tobias Spranger <[EMAIL PROTECTED]> writes:
<
< | Hello,
< >
< | I think we could have saved some time, if we were able to work both on a
< | single document at the same time. So I propose a
server-client-architecture
< | for LyX that
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Lars Gullik BjÃnnes wrote:
> > Actaully this wouldn't be _that_ hard, it is all about having a nice
> > protocol between the gui and the core. I guess I could do it in a
> > week. This also fits quite well with some other cleanup that I'd
> > really
Andreas Vox wrote:
> What about the buffer? I think the lyx-paragraphs should be on the
> server but the cursor position at the client (I dont know the current
> code too well, maybe they are already separated)
They are. This is equivalent to having multiple views into the document.
That's
> | I think we could have saved some time, if we were able to work both on a
> | single document at the same time. So I propose a
> | server-client-architecture for LyX that works in the same way as the
> | "team modus" of starcraft. One opens a server with the document to edit
> | and other
38 matches
Mail list logo
