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 good
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
| >
| >
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 click
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
>>>
>
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 b
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
>
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. LFUN_LYX_QUI
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 stuff,
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
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_CLO
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 LFUN_LY
> 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
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.
>
> B
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.
C
> "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
> "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
On 1/11/07, Bo Peng <[EMAIL PROTECTED]> wrote:
This patch uses both pit and id to locate a bookmark.
If there is no objection, it is going in soon. I will fix the
file->exit/bookmark update part later.
Cheers,
Bo
Given that quitWriteAll() is called in all the cases above, maybe
you can stick there your code?
Without looking at the code, maybe,
1. quiteWriteAll() may not have a cursor. (Can be called in non-GUI mode?)
2. I will have to switch to a buffer, set cursor to get the pid. It is
much easier to
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 an
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 GuiView::clos
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 whatev
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 boo
23 matches
Mail list logo
