Bo Peng wrote:
What I meant is something like follows. The patch does not work
correctly yet, but shows my point.
1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
This part is good. The BufferList should not care about quitting and
asking for user interaction.
2.
Bo Peng wrote:
What I meant is something like follows. The patch does not work
correctly yet, but shows my point.
1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one
4.
Peter Kümmel wrote:
Bo Peng wrote:
What I meant is something like follows. The patch does not work
correctly yet, but shows my point.
1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Bo Peng wrote:
What I meant is something like follows. The patch does not work
correctly yet, but shows my point.
1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
3. LFUN_WINDOW_CLOSE
I agree this has nothing to do here but we have to ask this question to
the user nevertheless, don't we? So where is this part of the code
transferred?
quitWriteBuffer() and close() are almost identical. By calling
LFUN_BUFFER_CLOSE, close() is called instead.
So this means that the user
Peter Kümmel [EMAIL PROTECTED] writes:
| Bo Peng wrote:
| What I meant is something like follows. The patch does not work
| correctly yet, but shows my point.
|
| 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
|
| 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
|
| 3.
Bo Peng wrote:
I agree this has nothing to do here but we have to ask this question to
the user nevertheless, don't we? So where is this part of the code
transferred?
quitWriteBuffer() and close() are almost identical. By calling
LFUN_BUFFER_CLOSE, close() is called instead.
Ahhh... very
Bo Peng wrote:
What I meant is something like follows. The patch does not work
correctly yet, but shows my point.
1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
This part is good. The BufferList should not care about quitting and
asking for user interaction.
2.
Bo Peng wrote:
> What I meant is something like follows. The patch does not work
> correctly yet, but shows my point.
>
> 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
>
> 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
>
> 3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one
Peter Kümmel wrote:
Bo Peng wrote:
What I meant is something like follows. The patch does not work
correctly yet, but shows my point.
1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Bo Peng wrote:
>>> What I meant is something like follows. The patch does not work
>>> correctly yet, but shows my point.
>>>
>>> 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
>>>
>>> 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
>>>
I agree this has nothing to do here but we have to ask this question to
the user nevertheless, don't we? So where is this part of the code
transferred?
quitWriteBuffer() and close() are almost identical. By calling
LFUN_BUFFER_CLOSE, close() is called instead.
So this means that the user
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Bo Peng wrote:
| > What I meant is something like follows. The patch does not work
| > correctly yet, but shows my point.
| >
| > 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
| >
| > 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
| >
| >
Bo Peng wrote:
I agree this has nothing to do here but we have to ask this question to
the user nevertheless, don't we? So where is this part of the code
transferred?
quitWriteBuffer() and close() are almost identical. By calling
LFUN_BUFFER_CLOSE, close() is called instead.
Ahhh... very
Bo Peng wrote:
I think I am no lyx-close expert, but in principle your point is correct.
Only, please make sure that it works in practice ;-)
I know, but I am not familiar with the quit logic, and there are so
many ways to quit lyx, plus some mac specialties ...
Yes. This is very hairy
I'll have a look at your patch but at first glance I think you missed
the mutiple-view case entirely.
I know. That is only a proof of concept patch. Thank you for you
attention, I was just irritated that I had to hang my session stuff
everywhere instead of doing it on a per-buffer basis.
Bo
Bo Peng wrote:
I think I am no lyx-close expert, but in principle your point is correct.
Only, please make sure that it works in practice ;-)
I know, but I am not familiar with the quit logic, and there are so
many ways to quit lyx, plus some mac specialties ...
Yes. This is very hairy
I'll have a look at your patch but at first glance I think you missed
the mutiple-view case entirely.
I know. That is only a proof of concept patch. Thank you for you
attention, I was just irritated that I had to hang my session stuff
everywhere instead of doing it on a per-buffer basis.
Bo
Bo == Bo Peng [EMAIL PROTECTED] writes:
Bo On 1/11/07, Bo Peng [EMAIL PROTECTED] wrote:
This patch uses both pit and id to locate a bookmark.
Bo If there is no objection, it is going in soon. I will fix the
file- exit/bookmark update part later.
It looks more complicated than I thought it
Bo == Bo Peng [EMAIL PROTECTED] writes:
Bo You can see that I update bookmark when buffer switch, buffer
Bo close, windows close, but I still can not update bookmark when
Bo File-exit is triggered.
Bo WHY CANNOT WE take the time to fire LFUN_BUFFER_CLOSE, and
Bo LFUN_WINDOW_CLOSE when lyx
It looks more complicated than I thought it would be, but I guess it
is OK.
I though it would be a five minutes jobs, but it took me two hours.
Both id and pit can change so I have to use and update both of them
when necessary. :-(
The patch is being cleaned, and will be in in a few minutes.
On Thu, Jan 11, 2007 at 04:43:37PM +0100, Jean-Marc Lasgouttes wrote:
Bo == Bo Peng [EMAIL PROTECTED] writes:
Bo You can see that I update bookmark when buffer switch, buffer
Bo close, windows close, but I still can not update bookmark when
Bo File-exit is triggered.
Bo WHY CANNOT WE
We should definitely do that.
I fear another quit cleanup saga...
For example, if you look at bufferlist.C, we have close,
quiteWriteBuffer, and quiteWriteAll. As far as I can tell, close =
quiteWriteBuffer, and quiteWriteAll should be removed (call
LFUN_BUFFER_CLOSE one by one).
Agreed?
Bo
What I meant is something like follows. The patch does not work
correctly yet, but shows my point.
1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one
4. closeEvent triggers
On Fri, Jan 12, 2007 at 09:22:00PM +1800, Bo Peng wrote:
What I meant is something like follows. The patch does not work
correctly yet, but shows my point.
1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
3. LFUN_WINDOW_CLOSE
I think I am no lyx-close expert, but in principle your point is correct.
Only, please make sure that it works in practice ;-)
I know, but I am not familiar with the quit logic, and there are so
many ways to quit lyx, plus some mac specialties ...
I guess my biggest concern is that why we have
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> On 1/11/07, Bo Peng <[EMAIL PROTECTED]> wrote:
>> This patch uses both pit and id to locate a bookmark.
Bo> If there is no objection, it is going in soon. I will fix the
file-> exit/bookmark update part later.
It looks more complicated than
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> You can see that I update bookmark when buffer switch, buffer
Bo> close, windows close, but I still can not update bookmark when
Bo> File->exit is triggered.
Bo> WHY CANNOT WE take the time to fire LFUN_BUFFER_CLOSE, and
Bo> LFUN_WINDOW_CLOSE
It looks more complicated than I thought it would be, but I guess it
is OK.
I though it would be a five minutes jobs, but it took me two hours.
Both id and pit can change so I have to use and update both of them
when necessary. :-(
The patch is being cleaned, and will be in in a few minutes.
On Thu, Jan 11, 2007 at 04:43:37PM +0100, Jean-Marc Lasgouttes wrote:
> > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>
> Bo> You can see that I update bookmark when buffer switch, buffer
> Bo> close, windows close, but I still can not update bookmark when
> Bo> File->exit is triggered.
>
>
> We should definitely do that.
I fear another quit cleanup saga...
For example, if you look at bufferlist.C, we have close,
quiteWriteBuffer, and quiteWriteAll. As far as I can tell, close =
quiteWriteBuffer, and quiteWriteAll should be removed (call
LFUN_BUFFER_CLOSE one by one).
Agreed?
What I meant is something like follows. The patch does not work
correctly yet, but shows my point.
1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
3. LFUN_WINDOW_CLOSE triggers LFUN_BUFFER_CLOSE one by one
4. closeEvent triggers
On Fri, Jan 12, 2007 at 09:22:00PM +1800, Bo Peng wrote:
> What I meant is something like follows. The patch does not work
> correctly yet, but shows my point.
>
> 1. src/bufferlist.C: remove quitWriteBuffer and quitWriteAll.
>
> 2. LFUN_LYX_QUIT triggers LFUN_WINDOW_CLOSE
>
> 3.
I think I am no lyx-close expert, but in principle your point is correct.
Only, please make sure that it works in practice ;-)
I know, but I am not familiar with the quit logic, and there are so
many ways to quit lyx, plus some mac specialties ...
I guess my biggest concern is that why we have
This patch uses both pit and id to locate a bookmark.
1. both pit and id are used to locate a position. Pit is saved by session.
2. moveToPosition now returns id and pit of the new position and
update bookmark if necessary. These happens:
* when id is invalid (Uwe's case), pit is used, and
On Thu, Jan 11, 2007 at 12:18:19PM +1800, Bo Peng wrote:
WHY CANNOT WE take the time to fire LFUN_BUFFER_CLOSE, and
LFUN_WINDOW_CLOSE when lyx exists? When lyx takes shortcuts to quit,
proper cleanup in these CLOSE events may be bypassed.
Maybe I don't know what you exactly mean, but whatever
Maybe I don't know what you exactly mean, but whatever the method
you use to quit (menu or click on the X in the right upper corner),
GuiView::closeEvent() is called. There you can already find some
code for saving geometry and cursor position of opened files.
What I meant was that
On Thu, Jan 11, 2007 at 02:29:27PM +1800, Bo Peng wrote:
Maybe I don't know what you exactly mean, but whatever the method
you use to quit (menu or click on the X in the right upper corner),
GuiView::closeEvent() is called. There you can already find some
code for saving geometry and
This patch uses both pit and id to locate a bookmark.
1. both pit and id are used to locate a position. Pit is saved by session.
2. moveToPosition now returns id and pit of the new position and
update bookmark if necessary. These happens:
* when id is invalid (Uwe's case), pit is used, and
On Thu, Jan 11, 2007 at 12:18:19PM +1800, Bo Peng wrote:
> WHY CANNOT WE take the time to fire LFUN_BUFFER_CLOSE, and
> LFUN_WINDOW_CLOSE when lyx exists? When lyx takes shortcuts to quit,
> proper cleanup in these CLOSE events may be bypassed.
Maybe I don't know what you exactly mean, but
Maybe I don't know what you exactly mean, but whatever the method
you use to quit (menu or click on the X in the right upper corner),
GuiView::closeEvent() is called. There you can already find some
code for saving geometry and cursor position of opened files.
What I meant was that
On Thu, Jan 11, 2007 at 02:29:27PM +1800, Bo Peng wrote:
> > Maybe I don't know what you exactly mean, but whatever the method
> > you use to quit (menu or click on the X in the right upper corner),
> > GuiView::closeEvent() is called. There you can already find some
> > code for saving geometry
42 matches
Mail list logo
