Re: Weird cross reference bug
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel No, these changes are the ones who fix the bug (the bug is Dekel caused by the lv_- getLyXFunc()-Dispatch(LFUN_REF_BACK) call in lv_- FormRef::updateRefs when Dekel the stack (backstack) is not empty). OK, then I guess you can indeed apply it. Note that we should make sure the bindings are available in emacs mode too. JMarc
Re: Weird cross reference bug
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> No, these changes are the ones who fix the bug (the bug is Dekel> caused by the lv_-> getLyXFunc()->Dispatch(LFUN_REF_BACK) call in lv_-> FormRef::updateRefs when Dekel> the stack (backstack) is not empty). OK, then I guess you can indeed apply it. Note that we should make sure the bindings are available in emacs mode too. JMarc
Re: Weird cross reference bug
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel On Tue, Feb 06, 2001 at 11:17:50AM +0100, Jean-Marc Lasgouttes Dekel wrote: I'm a bit unsure too. Dekel, is the bookmark code only a "side-effect" or is it that you do not want to separate the patch in two? We already had one new bug in 1.1.6fix1, and I really do not want to see another one! Dekel It is hard to separate the patch to two. While it is possible Dekel to do, it involves a lot of work, and the chance of introducing Dekel a new bug is probably greater than using the patch as is. Where can I see the patch? Same for the bib stuff. I'd rather not have Dekel http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html Hmm, is the important part of the patch the use of paragraph id, along with the small cjhanges in Formref::updateBrowser? the multiple bibliography stuff, since if we decide to change the way it works before 1.2.0, we will be bound by what appeared in 1.1.6fixX. Dekel I can disable the multiple bibliographies code with #ifdef's Yes, I'd prefer that. JMarc
Re: Weird cross reference bug
On Wed, Feb 07, 2001 at 04:07:58PM +0100, Jean-Marc Lasgouttes wrote:
Dekel http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html
Hmm, is the important part of the patch the use of paragraph id, along
with the small cjhanges in Formref::updateBrowser?
The main part of the patch is the use of saved_positions (a vector) instead
of backstack (stack) in BufferView::Pimpl::{save,restore}Position,
and the changes in FormRef.
Re: Weird cross reference bug
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes:
Dekel On Wed, Feb 07, 2001 at 04:07:58PM +0100, Jean-Marc Lasgouttes
Dekel wrote:
Dekel http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html
Hmm, is the important part of the patch the use of paragraph id,
along with the small cjhanges in Formref::updateBrowser?
Dekel The main part of the patch is the use of saved_positions (a
Dekel vector) instead of backstack (stack) in
Dekel BufferView::Pimpl::{save,restore}Position, and the changes in
Dekel FormRef.
Yes, but this is not what fixes the bug, is it?
JMarc
Re: Weird cross reference bug
On Wed, Feb 07, 2001 at 04:47:25PM +0100, Jean-Marc Lasgouttes wrote:
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes:
Dekel On Wed, Feb 07, 2001 at 04:07:58PM +0100, Jean-Marc Lasgouttes
Dekel wrote:
Dekel http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html
Hmm, is the important part of the patch the use of paragraph id,
along with the small cjhanges in Formref::updateBrowser?
Dekel The main part of the patch is the use of saved_positions (a
Dekel vector) instead of backstack (stack) in
Dekel BufferView::Pimpl::{save,restore}Position, and the changes in
Dekel FormRef.
Yes, but this is not what fixes the bug, is it?
No, these changes are the ones who fix the bug (the bug is caused by the
lv_-getLyXFunc()-Dispatch(LFUN_REF_BACK) call in FormRef::updateRefs when
the stack (backstack) is not empty).
Re: Weird cross reference bug
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> On Tue, Feb 06, 2001 at 11:17:50AM +0100, Jean-Marc Lasgouttes Dekel> wrote: >> I'm a bit unsure too. Dekel, is the bookmark code only a >> "side-effect" or is it that you do not want to separate the patch >> in two? We already had one new bug in 1.1.6fix1, and I really do >> not want to see another one! Dekel> It is hard to separate the patch to two. While it is possible Dekel> to do, it involves a lot of work, and the chance of introducing Dekel> a new bug is probably greater than using the patch as is. >> Where can I see the patch? Same for the bib stuff. I'd rather not >> have Dekel> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html Hmm, is the important part of the patch the use of paragraph id, along with the small cjhanges in Formref::updateBrowser? >> the multiple bibliography stuff, since if we decide to change the >> way it works before 1.2.0, we will be bound by what appeared in >> 1.1.6fixX. Dekel> I can disable the multiple bibliographies code with #ifdef's Yes, I'd prefer that. JMarc
Re: Weird cross reference bug
On Wed, Feb 07, 2001 at 04:07:58PM +0100, Jean-Marc Lasgouttes wrote:
> Dekel> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html
>
> Hmm, is the important part of the patch the use of paragraph id, along
> with the small cjhanges in Formref::updateBrowser?
The main part of the patch is the use of saved_positions (a vector) instead
of backstack (stack) in BufferView::Pimpl::{save,restore}Position,
and the changes in FormRef.
Re: Weird cross reference bug
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> On Wed, Feb 07, 2001 at 04:07:58PM +0100, Jean-Marc Lasgouttes
Dekel> wrote:
Dekel> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html
>> Hmm, is the important part of the patch the use of paragraph id,
>> along with the small cjhanges in Formref::updateBrowser?
Dekel> The main part of the patch is the use of saved_positions (a
Dekel> vector) instead of backstack (stack) in
Dekel> BufferView::Pimpl::{save,restore}Position, and the changes in
Dekel> FormRef.
Yes, but this is not what fixes the bug, is it?
JMarc
Re: Weird cross reference bug
On Wed, Feb 07, 2001 at 04:47:25PM +0100, Jean-Marc Lasgouttes wrote:
> > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
>
> Dekel> On Wed, Feb 07, 2001 at 04:07:58PM +0100, Jean-Marc Lasgouttes
> Dekel> wrote:
> Dekel> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html
> >> Hmm, is the important part of the patch the use of paragraph id,
> >> along with the small cjhanges in Formref::updateBrowser?
>
> Dekel> The main part of the patch is the use of saved_positions (a
> Dekel> vector) instead of backstack (stack) in
> Dekel> BufferView::Pimpl::{save,restore}Position, and the changes in
> Dekel> FormRef.
>
> Yes, but this is not what fixes the bug, is it?
No, these changes are the ones who fix the bug (the bug is caused by the
lv_->getLyXFunc()->Dispatch(LFUN_REF_BACK) call in FormRef::updateRefs when
the stack (backstack) is not empty).
Re: Weird cross reference bug
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars So you want untested features added to the stable branch... Lars I'll leave the decision with Jean-Marc, but I am not overly Lars positive. I'm a bit unsure too. Dekel, is the bookmark code only a "side-effect" or is it that you do not want to separate the patch in two? We already had one new bug in 1.1.6fix1, and I really do not want to see another one! My thoughts for these fix release is to be overly cautious (paranoid?). We really do not need new features there. Where can I see the patch? Same for the bib stuff. I'd rather not have the multiple bibliography stuff, since if we decide to change the way it works before 1.2.0, we will be bound by what appeared in 1.1.6fixX. JMarc
Re: Weird cross reference bug
On Tue, Feb 06, 2001 at 11:17:50AM +0100, Jean-Marc Lasgouttes wrote: I'm a bit unsure too. Dekel, is the bookmark code only a "side-effect" or is it that you do not want to separate the patch in two? We already had one new bug in 1.1.6fix1, and I really do not want to see another one! It is hard to separate the patch to two. While it is possible to do, it involves a lot of work, and the chance of introducing a new bug is probably greater than using the patch as is. Where can I see the patch? Same for the bib stuff. I'd rather not have http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html the multiple bibliography stuff, since if we decide to change the way it works before 1.2.0, we will be bound by what appeared in 1.1.6fixX. I can disable the multiple bibliographies code with #ifdef's
Re: Weird cross reference bug
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> So you want untested features added to the stable branch... Lars> I'll leave the decision with Jean-Marc, but I am not overly Lars> positive. I'm a bit unsure too. Dekel, is the bookmark code only a "side-effect" or is it that you do not want to separate the patch in two? We already had one new bug in 1.1.6fix1, and I really do not want to see another one! My thoughts for these fix release is to be overly cautious (paranoid?). We really do not need new features there. Where can I see the patch? Same for the bib stuff. I'd rather not have the multiple bibliography stuff, since if we decide to change the way it works before 1.2.0, we will be bound by what appeared in 1.1.6fixX. JMarc
Re: Weird cross reference bug
On Tue, Feb 06, 2001 at 11:17:50AM +0100, Jean-Marc Lasgouttes wrote: > I'm a bit unsure too. Dekel, is the bookmark code only a "side-effect" > or is it that you do not want to separate the patch in two? We already > had one new bug in 1.1.6fix1, and I really do not want to see another > one! It is hard to separate the patch to two. While it is possible to do, it involves a lot of work, and the chance of introducing a new bug is probably greater than using the patch as is. > Where can I see the patch? Same for the bib stuff. I'd rather not have http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg18611.html > the multiple bibliography stuff, since if we decide to change the way > it works before 1.2.0, we will be bound by what appeared in 1.1.6fixX. I can disable the multiple bibliographies code with #ifdef's
Re: Weird cross reference bug
On Sun, Jan 28, 2001 at 06:52:41PM +0100, Lars Gullik Bjønnes wrote: Dekel Tsur [EMAIL PROTECTED] writes: | I would like to apply this patch to HEAD and to 1.1.6 branch. | Any comments? Apply only to head. The patch (the bookmarks patch) fixes the bug that reported by Amir, so it should be applied to 1.1.6.
Re: Weird cross reference bug
Dekel Tsur [EMAIL PROTECTED] writes: | On Sun, Jan 28, 2001 at 06:52:41PM +0100, Lars Gullik Bjnnes wrote: | Dekel Tsur [EMAIL PROTECTED] writes: | | | I would like to apply this patch to HEAD and to 1.1.6 branch. | | Any comments? | | Apply only to head. | | The patch (the bookmarks patch) fixes the bug that reported by Amir, | so it should be applied to 1.1.6. So you want untested features added to the stable branch... I'll leave the decision with Jean-Marc, but I am not overly positive. Lgb
Re: Weird cross reference bug
On Mon, Feb 05, 2001 at 09:30:15PM +0100, Lars Gullik Bjønnes wrote: Dekel Tsur [EMAIL PROTECTED] writes: | On Sun, Jan 28, 2001 at 06:52:41PM +0100, Lars Gullik Bj?nnes wrote: | Dekel Tsur [EMAIL PROTECTED] writes: | | | I would like to apply this patch to HEAD and to 1.1.6 branch. | | Any comments? | | Apply only to head. | | The patch (the bookmarks patch) fixes the bug that reported by Amir, | so it should be applied to 1.1.6. So you want untested features added to the stable branch... I want the bugfix to be in 1.1.6. The bookmarks feature is a side effect.
Re: Weird cross reference bug
On Sun, Jan 28, 2001 at 06:52:41PM +0100, Lars Gullik Bjønnes wrote: > Dekel Tsur <[EMAIL PROTECTED]> writes: > > | I would like to apply this patch to HEAD and to 1.1.6 branch. > | Any comments? > > Apply only to head. The patch (the bookmarks patch) fixes the bug that reported by Amir, so it should be applied to 1.1.6.
Re: Weird cross reference bug
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Sun, Jan 28, 2001 at 06:52:41PM +0100, Lars Gullik Bjønnes wrote: | > Dekel Tsur <[EMAIL PROTECTED]> writes: | > | > | I would like to apply this patch to HEAD and to 1.1.6 branch. | > | Any comments? | > | > Apply only to head. | | The patch (the bookmarks patch) fixes the bug that reported by Amir, | so it should be applied to 1.1.6. So you want untested features added to the stable branch... I'll leave the decision with Jean-Marc, but I am not overly positive. Lgb
Re: Weird cross reference bug
On Mon, Feb 05, 2001 at 09:30:15PM +0100, Lars Gullik Bjønnes wrote: > Dekel Tsur <[EMAIL PROTECTED]> writes: > > | On Sun, Jan 28, 2001 at 06:52:41PM +0100, Lars Gullik Bj?nnes wrote: > | > Dekel Tsur <[EMAIL PROTECTED]> writes: > | > > | > | I would like to apply this patch to HEAD and to 1.1.6 branch. > | > | Any comments? > | > > | > Apply only to head. > | > | The patch (the bookmarks patch) fixes the bug that reported by Amir, > | so it should be applied to 1.1.6. > > So you want untested features added to the stable branch... I want the bugfix to be in 1.1.6. The bookmarks feature is a side effect.
Re: Weird cross reference bug
Dekel Tsur [EMAIL PROTECTED] writes: | I would like to apply this patch to HEAD and to 1.1.6 branch. | Any comments? Apply only to head. Lgb
Re: Weird cross reference bug
Dekel Tsur <[EMAIL PROTECTED]> writes: | I would like to apply this patch to HEAD and to 1.1.6 branch. | Any comments? Apply only to head. Lgb
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 01:00:56PM +, Angus Leeming wrote:
Me, I like 1 best. But we'll still run into problems when navigating between
labels if the labels are in different buffers. Ideally, the popup should know
whether the buffers are related (share a common parent). If they do, stay
open, if not close. That sounds excessively complex. Why don't I override
UpdateSlot to:
void FormRef::updateSlot(bool switched)
{
update();
}
Will that be sufficient?
This will not fix the bug.
I've attached a solution for the bug, by completely changing
BufferView::savePosition and BufferView::restorePosition.
Instead of keeping a stack of positions, we keep a vector of positions,
where elementp #0 in the evctor is used for goto reference/go back mechanism,
and the rest of the elements are used for bookmarks (try the
edit-bookmarks menu), which is a quite useful feature.
I would like to apply this patch to HEAD and to 1.1.6 branch.
Any comments?
patch.gz
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 01:00:56PM +, Angus Leeming wrote:
> Me, I like 1 best. But we'll still run into problems when navigating between
> labels if the labels are in different buffers. Ideally, the popup should know
> whether the buffers are related (share a common parent). If they do, stay
> open, if not close. That sounds excessively complex. Why don't I override
> UpdateSlot to:
>
> void FormRef::updateSlot(bool switched)
> {
> update();
> }
>
> Will that be sufficient?
This will not fix the bug.
I've attached a solution for the bug, by completely changing
BufferView::savePosition and BufferView::restorePosition.
Instead of keeping a stack of positions, we keep a vector of positions,
where elementp #0 in the evctor is used for goto reference/go back mechanism,
and the rest of the elements are used for bookmarks (try the
edit->bookmarks menu), which is a quite useful feature.
I would like to apply this patch to HEAD and to 1.1.6 branch.
Any comments?
patch.gz
Re: Weird cross reference bug
Ahhh! I _think_ I understand... perhaps...
This feels like the popup is recieving a signal that the buffer has changed.
In fact, I'm sure that's what is happening.
If the buffer changes, then a signal "updateBufferDependent" is emitted into
the ether. This signal is connected to a slot "updateSlot" in the Ref popup:
void FormInset::updateSlot(bool switched)
{
if (switched)
hide();
else
update();
}
In this case, updateSlot is being passed "true", telling it that the buffer
has changed and so the popup should be closed.
The question is, therefore, WHY is it receiving such a signal when you "click
on one of the figure refs from the list" and equally, why does it "randomly
goes away" after a few minutes.
Dekel, will this have been fixed by your recent patch? Perhaps you'd care to
comment?
Angus
On Monday 22 January 2001 21:00, Amir Karger wrote:
I'm using 1.1.6, but I'm pretty sure the problem also occurred once when I
was using the early June 1.1.6cvs. Last time I thought it was a fluke, but
now it's happening again.
My main THESIS.lyx file includes a bunch of files. Each of those has figures
in it, and the figures have labels. I'm in one of the sub-files, and I
do an "Insert-Reference" and click on one of the figure refs from the list.
(I should mention that I love the way the forms are shaping up. Definitely a
usability win in LyX.) Instead of showing the name of the reference in the
"Ref" box, the entire popup closes (I never even had the chance to click on
OK.), and I'm teleported to the main file. This happens several times. I'm
able to insert a ref into the main file, but if I go back to a sub-file
(even a different sub-file) it doesn't work.
After a couple minutes the problem randomly goes away. Sorry that this is a
terrible bug report, but it's a very weird bug. I've used references a
million times, and I don't think I'm doing anything particularly weird when
the problem occurs, but maybe one of you will have an idea what's causing
this.
-Amir
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 11:16:57AM +, Angus Leeming wrote: Dekel, will this have been fixed by your recent patch? Perhaps you'd care to comment? Don't try to blame me. It is your fault. The problem is that when a label is selected in the browser, we call to Dispatch(LFUN_REF_BACK) (in FormRef::input). I guess the idea is to return you to the original position from which the browser was opened, so the reference will be inserted there. However, if there are previously saved positions (i.e. you open the dialog, press "goto reference" and closed the dialog without pressing "go back"), the cursor will move to the last save positions, which can be in a different buffer, and the buffer switching causes the closing of the dialog. It is not hard to fix this problem, but I want to discuss what is the behavior that we want for the dialog. Here are three suggestions 1. The cursor is moved only when explicitly pressing goto reference/go back. 2. Pressing a label in the browser doesn't move the cursor. However, when you press OK/Apply, the cursor is moved to the original position (i.e. the position from which the dialog was opened), and the reference is inserted there. 3. Pressing a label in the browser automatically moves you to the label, (without the need to press "goto reference"). Again, pressing OK/Apply returns you to the original position. I think that 3 is the best option.
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 11:16:57AM +, Angus Leeming wrote: In this case, updateSlot is being passed "true", telling it that the buffer has changed and so the popup should be closed. Since now the references dialog closes when changing buffers, it is not possible to add references to labels in a different file. There are two possible solutions (which are not mutually exclusive): 1. Make the Ref button editable, so you could insert an arbitrary reference (we can add a warning when the user insert a reference to a label that doesn't exist in the current document). 2. Add a choice button to the dialog, which let you choose to list the labels from the current document, or from any other open document.
Re: Weird cross reference bug
On Tuesday 23 January 2001 12:43, Dekel Tsur wrote:
Dekel, will this have been fixed by your recent patch? Perhaps you'd
care to comment?
Don't try to blame me. It is your fault.
Hey, hey, hey! I blamed nobody! So, I'll start now by saying, "It's all my
fault. Everything is my fault. O me miserum!" That should cover most
eventualities :o)
The problem is that when a label is selected in the browser, we call to
Dispatch(LFUN_REF_BACK) (in FormRef::input). I guess the idea is to return
you to the original position from which the browser was opened, so the
reference will be inserted there. However, if there are previously saved
positions (i.e. you open the dialog, press "goto reference" and closed the
dialog without pressing "go back"), the cursor will move to the last save
positions, which can be in a different buffer, and the buffer switching
causes the closing of the dialog.
Well this is certainly wrong. There should be nothing saved when the popup is
closed. (Incidentally, what DID you change recently; I'm vaguely aware that
you fixed something but have been busy elsewhere and not really paying
attention.)
It is not hard to fix this problem, but I want to discuss what is the
behavior that we want for the dialog. Here are three suggestions
1. The cursor is moved only when explicitly pressing goto reference/go back.
2. Pressing a label in the browser doesn't move the cursor. However, when
you
press OK/Apply, the cursor is moved to the original position (i.e. the
position from which the dialog was opened), and the reference is inserted
there.
3. Pressing a label in the browser automatically moves you to the label,
(without the need to press "goto reference"). Again, pressing OK/Apply
returns you to the original position.
I think that 3 is the best option.
Me, I like 1 best. But we'll still run into problems when navigating between
labels if the labels are in different buffers. Ideally, the popup should know
whether the buffers are related (share a common parent). If they do, stay
open, if not close. That sounds excessively complex. Why don't I override
UpdateSlot to:
void FormRef::updateSlot(bool switched)
{
update();
}
Will that be sufficient?
Angus
Re: Weird cross reference bug
On Tuesday 23 January 2001 12:51, Dekel Tsur wrote: On Tue, Jan 23, 2001 at 11:16:57AM +, Angus Leeming wrote: In this case, updateSlot is being passed "true", telling it that the buffer has changed and so the popup should be closed. Since now the references dialog closes when changing buffers, it is not possible to add references to labels in a different file. There are two possible solutions (which are not mutually exclusive): 1. Make the Ref button editable, so you could insert an arbitrary reference (we can add a warning when the user insert a reference to a label that doesn't exist in the current document). 2. Add a choice button to the dialog, which let you choose to list the labels from the current document, or from any other open document. I like 2 best. Fool proof and accurate. A
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 02:51:11PM +0200, Dekel Tsur wrote: On Tue, Jan 23, 2001 at 11:16:57AM +, Angus Leeming wrote: In this case, updateSlot is being passed "true", telling it that the buffer has changed and so the popup should be closed. Since now the references dialog closes when changing buffers, it is not possible to add references to labels in a different file. Maybe I'm not understanding what you're saying, but I add references to labels in different files all the time. Yes, I have to reopen the dialog, but I've been hitting OK instead of Apply most of the time anyway, because I tend to dislike window clutter, and I don't add references all that often. But I definitely get a list of all the references in all the sub-documents, and can add ones from the current file or different files. -Amir
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 10:23:05AM -0500, Amir Karger wrote: Maybe I'm not understanding what you're saying, but I add references to labels in different files all the time. Yes, I have to reopen the dialog, but I've been hitting OK instead of Apply most of the time anyway, because I tend to dislike window clutter, and I don't add references all that often. But I definitely get a list of all the references in all the sub-documents, and can add ones from the current file or different files. If you have for example, main.lyx which includes chap1.lyx, chap2.lyx, ... then after opening the insert ref dialog in main.lyx, you can see the list of all labels in all the files. But this is not very convenient (suppose you are in chap1.lyx and want only the labels of chap1.lyx, or only the labels of chap2.lyx).
Re: Weird cross reference bug
Dekel Tsur wrote: On Tue, Jan 23, 2001 at 10:23:05AM -0500, Amir Karger wrote: Maybe I'm not understanding what you're saying, but I add references to labels in different files all the time. Yes, I have to reopen the dialog, but I've been hitting OK instead of Apply most of the time anyway, because I tend to dislike window clutter, and I don't add references all that often. But I definitely get a list of all the references in all the sub-documents, and can add ones from the current file or different files. If you have for example, main.lyx which includes chap1.lyx, chap2.lyx, ... then after opening the insert ref dialog in main.lyx, you can see the list of all labels in all the files. But this is not very convenient (suppose you are in chap1.lyx and want only the labels of chap1.lyx, or only the labels of chap2.lyx). What happens if you open main.lyx and chap1.lyx as separate documents? Garst
Re: Weird cross reference bug
Ahhh! I _think_ I understand... perhaps...
This feels like the popup is recieving a signal that the buffer has changed.
In fact, I'm sure that's what is happening.
If the buffer changes, then a signal "updateBufferDependent" is emitted into
the ether. This signal is connected to a slot "updateSlot" in the Ref popup:
void FormInset::updateSlot(bool switched)
{
if (switched)
hide();
else
update();
}
In this case, updateSlot is being passed "true", telling it that the buffer
has changed and so the popup should be closed.
The question is, therefore, WHY is it receiving such a signal when you "click
on one of the figure refs from the list" and equally, why does it "randomly
goes away" after a few minutes.
Dekel, will this have been fixed by your recent patch? Perhaps you'd care to
comment?
Angus
On Monday 22 January 2001 21:00, Amir Karger wrote:
> I'm using 1.1.6, but I'm pretty sure the problem also occurred once when I
> was using the early June 1.1.6cvs. Last time I thought it was a fluke, but
> now it's happening again.
>
> My main THESIS.lyx file includes a bunch of files. Each of those has figures
> in it, and the figures have labels. I'm in one of the sub-files, and I
> do an "Insert->Reference" and click on one of the figure refs from the list.
> (I should mention that I love the way the forms are shaping up. Definitely a
> usability win in LyX.) Instead of showing the name of the reference in the
> "Ref" box, the entire popup closes (I never even had the chance to click on
> OK.), and I'm teleported to the main file. This happens several times. I'm
> able to insert a ref into the main file, but if I go back to a sub-file
> (even a different sub-file) it doesn't work.
>
> After a couple minutes the problem randomly goes away. Sorry that this is a
> terrible bug report, but it's a very weird bug. I've used references a
> million times, and I don't think I'm doing anything particularly weird when
> the problem occurs, but maybe one of you will have an idea what's causing
> this.
>
> -Amir
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 11:16:57AM +, Angus Leeming wrote: > Dekel, will this have been fixed by your recent patch? Perhaps you'd care to > comment? Don't try to blame me. It is your fault. The problem is that when a label is selected in the browser, we call to Dispatch(LFUN_REF_BACK) (in FormRef::input). I guess the idea is to return you to the original position from which the browser was opened, so the reference will be inserted there. However, if there are previously saved positions (i.e. you open the dialog, press "goto reference" and closed the dialog without pressing "go back"), the cursor will move to the last save positions, which can be in a different buffer, and the buffer switching causes the closing of the dialog. It is not hard to fix this problem, but I want to discuss what is the behavior that we want for the dialog. Here are three suggestions 1. The cursor is moved only when explicitly pressing goto reference/go back. 2. Pressing a label in the browser doesn't move the cursor. However, when you press OK/Apply, the cursor is moved to the original position (i.e. the position from which the dialog was opened), and the reference is inserted there. 3. Pressing a label in the browser automatically moves you to the label, (without the need to press "goto reference"). Again, pressing OK/Apply returns you to the original position. I think that 3 is the best option.
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 11:16:57AM +, Angus Leeming wrote: > In this case, updateSlot is being passed "true", telling it that the buffer > has changed and so the popup should be closed. Since now the references dialog closes when changing buffers, it is not possible to add references to labels in a different file. There are two possible solutions (which are not mutually exclusive): 1. Make the Ref button editable, so you could insert an arbitrary reference (we can add a warning when the user insert a reference to a label that doesn't exist in the current document). 2. Add a choice button to the dialog, which let you choose to list the labels from the current document, or from any other open document.
Re: Weird cross reference bug
On Tuesday 23 January 2001 12:43, Dekel Tsur wrote:
> > Dekel, will this have been fixed by your recent patch? Perhaps you'd
> > care to comment?
> Don't try to blame me. It is your fault.
Hey, hey, hey! I blamed nobody! So, I'll start now by saying, "It's all my
fault. Everything is my fault. O me miserum!" That should cover most
eventualities :o)
> The problem is that when a label is selected in the browser, we call to
> Dispatch(LFUN_REF_BACK) (in FormRef::input). I guess the idea is to return
> you to the original position from which the browser was opened, so the
> reference will be inserted there. However, if there are previously saved
> positions (i.e. you open the dialog, press "goto reference" and closed the
> dialog without pressing "go back"), the cursor will move to the last save
> positions, which can be in a different buffer, and the buffer switching
> causes the closing of the dialog.
Well this is certainly wrong. There should be nothing saved when the popup is
closed. (Incidentally, what DID you change recently; I'm vaguely aware that
you fixed something but have been busy elsewhere and not really paying
attention.)
> It is not hard to fix this problem, but I want to discuss what is the
> behavior that we want for the dialog. Here are three suggestions
>
> 1. The cursor is moved only when explicitly pressing goto reference/go back.
>
> 2. Pressing a label in the browser doesn't move the cursor. However, when
you
> press OK/Apply, the cursor is moved to the original position (i.e. the
> position from which the dialog was opened), and the reference is inserted
> there.
>
> 3. Pressing a label in the browser automatically moves you to the label,
> (without the need to press "goto reference"). Again, pressing OK/Apply
> returns you to the original position.
>
> I think that 3 is the best option.
Me, I like 1 best. But we'll still run into problems when navigating between
labels if the labels are in different buffers. Ideally, the popup should know
whether the buffers are related (share a common parent). If they do, stay
open, if not close. That sounds excessively complex. Why don't I override
UpdateSlot to:
void FormRef::updateSlot(bool switched)
{
update();
}
Will that be sufficient?
Angus
Re: Weird cross reference bug
On Tuesday 23 January 2001 12:51, Dekel Tsur wrote: > On Tue, Jan 23, 2001 at 11:16:57AM +, Angus Leeming wrote: > > In this case, updateSlot is being passed "true", telling it that the buffer > > has changed and so the popup should be closed. > > Since now the references dialog closes when changing buffers, it is not > possible to add references to labels in a different file. > > There are two possible solutions (which are not mutually exclusive): > > 1. Make the Ref button editable, so you could insert an arbitrary reference > (we can add a warning when the user insert a reference to a label that > doesn't exist in the current document). > > 2. Add a choice button to the dialog, which let you choose to list the > labels from the current document, or from any other open document. I like 2 best. Fool proof and accurate. A
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 02:51:11PM +0200, Dekel Tsur wrote: > On Tue, Jan 23, 2001 at 11:16:57AM +, Angus Leeming wrote: > > In this case, updateSlot is being passed "true", telling it that the buffer > > has changed and so the popup should be closed. > > Since now the references dialog closes when changing buffers, it is not > possible to add references to labels in a different file. > Maybe I'm not understanding what you're saying, but I add references to labels in different files all the time. Yes, I have to reopen the dialog, but I've been hitting OK instead of Apply most of the time anyway, because I tend to dislike window clutter, and I don't add references all that often. But I definitely get a list of all the references in all the sub-documents, and can add ones from the current file or different files. -Amir
Re: Weird cross reference bug
On Tue, Jan 23, 2001 at 10:23:05AM -0500, Amir Karger wrote: > Maybe I'm not understanding what you're saying, but I add references to > labels in different files all the time. Yes, I have to reopen the dialog, > but I've been hitting OK instead of Apply most of the time anyway, because I > tend to dislike window clutter, and I don't add references all that often. > But I definitely get a list of all the references in all the sub-documents, > and can add ones from the current file or different files. If you have for example, main.lyx which includes chap1.lyx, chap2.lyx, ... then after opening the insert ref dialog in main.lyx, you can see the list of all labels in all the files. But this is not very convenient (suppose you are in chap1.lyx and want only the labels of chap1.lyx, or only the labels of chap2.lyx).
Re: Weird cross reference bug
Dekel Tsur wrote: > > On Tue, Jan 23, 2001 at 10:23:05AM -0500, Amir Karger wrote: > > Maybe I'm not understanding what you're saying, but I add references to > > labels in different files all the time. Yes, I have to reopen the dialog, > > but I've been hitting OK instead of Apply most of the time anyway, because I > > tend to dislike window clutter, and I don't add references all that often. > > But I definitely get a list of all the references in all the sub-documents, > > and can add ones from the current file or different files. > > If you have for example, main.lyx which includes chap1.lyx, chap2.lyx, ... > then after opening the insert ref dialog in main.lyx, you can see the list > of all labels in all the files. But this is not very convenient (suppose you > are in chap1.lyx and want only the labels of chap1.lyx, or only the labels > of chap2.lyx). What happens if you open main.lyx and chap1.lyx as separate documents? Garst
