Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
This looks wrong (the rest looks OK). Do you know that b !=
work_area_->bufferView().buffer() is possible even after a
work_area_->bufferView().setBuffer(b)?
This was indeed the case before my patch but look also at my
BufferView_pimp change.
They do only change the behaviour if quitting == true.
This plus my older changes to BufferView::setBuffer(), please read that
method and I think you will understand.
I think I do understand, but what I understand seems to differ from your
view.
We both understand that much obviously :-)
b !=
work_area_->bufferView().buffer() is still possible.
No, they may differ only if b == 0 which means that we are killing the
buffer.
Exactly. And in this case you are now calling connectBuffer and setLayout.
This was not done before.
I would agree that the call to connectBuffer() could be saved if this
buffer was already connected. But this is not the case, only one Buffer
is connected at a time to the LyXView. While it could be possible to
connect multiple buffers this is not done right now as the visible
buffer is disconnected before a buffer switch happen via the
disconnectBuffer() call in setBuffer():
void LyXView::setBuffer(Buffer * b)
{
if (work_area_->bufferView().buffer())
disconnectBuffer();
The layout combo shall always be connected to the visible buffer and
that's what setLayout() is doing.
This does only make a difference if there still
is a different buffer, but that happens for me quite often because I use
lots of multipart documents.
And why is it bad to call connectBuffer() and setLayout() on the next
buffer on the list? This is the buffer that is going to be shown on
screen after all.
I'll try to read the TortoiseSVN doc to do that.
Great. With plain svn yo'll have to use a trick unfortunately (set
diff-cmd = /home/me/bin/svndiff
and call the real diff with arguments in svndiff). I don't know how that
works with tourtoisesvn.
I'll check that thanks.
I've tested this patch with a lot of buffer switching and deletion.
It may work, but I still think that the logic above is wrong. You are
going to call connectBuffer and setLayout with an already connected
buffer when b == 0.
No, when b==0, BufferView::setBuffer() will switch to the first
available buffer in the bufferlist.
And that buffer will be connected again.
Again? Only one buffer is connected at a time... or maybe I am getting
everything wrong?
This was not done before.
That may do no harm, but is AFAIK not necessary, and makes the code
harder to understand.
I agree that it is hard to understand and the main reason is that
setBuffer(0) for killing a buffer is not a good API. I'll try to clean
up that when I get some time.
Is that any clearer?
No :-(
If I am wrong please explain me.
Abdel.
