Inset::localDispatch problem
Andr, as localDispatch is yours, perhaps you can help me with this problem. It's come up because I'm starting to deal with insets which have a dialog but which are also editable. Inset::localDispatch is called from LyXFunc::dispatch (below). If this fails then the LFUN is passed to BufferView::dispatch which contains a switch for the different LFUNs. ... } else if (((result=inset- // Hand-over to inset's own dispatch: localDispatch(FuncRequest(view(), action, argument))) == DISPATCHED) || (result == DISPATCHED_NOUPDATE)) goto exit_with_message; // If UNDISPATCHED, just soldier on The insets have a localDispatch method that is now handles LFUN_INSET_APPLY. My problem lies with the 'inset' in the above block of code. For example, I have two ERT insets. Right click one to pop up the dialog. Move the cursor into the other and now press 'Apply'. The changes in the dialog should apply to the first, 'opened' inset that is stored in a map in the Dialogs class. The code above causes it to be applied to the second inset that contains the cursor. The 'fix' is simple: } else if (action != LFUN_INSET_APPLY ((result=inset- // Hand-over to inset's own dispatch: localDispatch(FuncRequest(view(), action, argument))) == DISPATCHED) || (result == DISPATCHED_NOUPDATE)) goto exit_with_message; // If UNDISPATCHED, just soldier on Meaning that the code in BufferView_pimpl.C's dispatch is called to do the right thing. But is there a better way? -- Angus
Re: Inset::localDispatch problem
On Tue, Mar 04, 2003 at 11:16:39AM +, Angus Leeming wrote: André, as localDispatch is yours, Not really. perhaps you can help me with this problem. It's come up because I'm starting to deal with insets which have a dialog but which are also editable. Inset::localDispatch is called from LyXFunc::dispatch (below). If this fails then the LFUN is passed to BufferView::dispatch which contains a switch for the different LFUNs. I never understood dispatching out there. [...] Meaning that the code in BufferView_pimpl.C's dispatch is called to do the right thing. What's wrong with that. But is there a better way? The problem ist that functionality is not properly distributed right now. The innermost level that knows to handle an event should handle it. Ideally there should not be (much|any) magical guessing who is responsible. The hierarchy should be something like LyXFunc | BufferView | Buffer | OutermostText [And this should go if everything is an inset] | Insets and we should walk it bottom-up. Currently we have some strange combination of guessing jumps down (the_locking_inset and some hard coded 'let's the inset handle it) and a few steps up... Some jumps probably can't be avoided, though. Pressing apply could invoke an lfun LFUN_DIALOG_APPLY which is handled only in the Bufferview (or whatever entity knows which inset is open). The bv catches this event and issues another LFUN_DIRECT_APPLY event to the proper inset. Something like that... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Inset::localDispatch problem
On Tuesday 04 March 2003 12:54 pm, Andre Poenitz wrote: The innermost level that knows to handle an event should handle it. Ideally there should not be (much|any) magical guessing who is responsible. The hierarchy should be something like LyXFunc BufferView Buffer OutermostText [And this should go if everything is an inset] Insets and we should walk it bottom-up. Currently we have some strange combination of guessing jumps down (the_locking_inset and some hard coded 'let's the inset handle it) and a few steps up... Some jumps probably can't be avoided, though. Pressing apply could invoke an lfun LFUN_DIALOG_APPLY which is handled only in the Bufferview (or whatever entity knows which inset is open). The bv catches this event and issues another LFUN_DIRECT_APPLY event to the proper inset. Nice idea actually. Only BufferView handles LFUN_INSET_APPLY. If an inset is open then it calls inset-localDispatch(FuncRequest(bv_, LFUN_INSET_MODIFY, ev.argument)); else it creates a new inset at the current cursor pos. I can do this now... It'll cure my problem with LyXFunc::dispatch and will be ready for the next generation code too. Thanks André. Angus
Re: Inset::localDispatch problem
Andre Poenitz wrote: The hierarchy should be something like LyXFunc | BufferView | Buffer | OutermostText [And this should go if everything is an inset] | Insets and we should walk it bottom-up. Currently we have some strange combination of guessing jumps down (the_locking_inset and some hard coded 'let's the inset handle it) and a few steps up... I don't understand where you see jumps? the above is true and you have to extend it like: ... | Inset | Inset ... | Inset I don't see a jump it goes from the outermost to the innermost and stops there where the event is handled than it returns back. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset::localDispatch problem
On Tue, Mar 04, 2003 at 04:54:07PM +0100, Juergen Vigna wrote:
I don't understand where you see jumps?
bool BufferView::Pimpl::dispatch(FuncRequest const ev_in)
{
[...]
default:
return bv_-getLyXText()-dispatch(FuncRequest(ev, bv_));
} // end of switch
}
The Buffer layer is missing.
I don't see a jump it goes from the outermost to the innermost and stops
there where the event is handled than it returns back.
It should jump down once, preferably using some thing like a document
iterator and go innermost to outermost from there. This is the only way
nested structures can work.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Inset::localDispatch problem
André, as localDispatch is yours, perhaps you can help me with this problem. It's come up because I'm starting to deal with insets which have a dialog but which are also editable. Inset::localDispatch is called from LyXFunc::dispatch (below). If this fails then the LFUN is passed to BufferView::dispatch which contains a switch for the different LFUNs. ... } else if (((result=inset-> // Hand-over to inset's own dispatch: localDispatch(FuncRequest(view(), action, argument))) == DISPATCHED) || (result == DISPATCHED_NOUPDATE)) goto exit_with_message; // If UNDISPATCHED, just soldier on The insets have a localDispatch method that is now handles LFUN_INSET_APPLY. My problem lies with the 'inset' in the above block of code. For example, I have two ERT insets. Right click one to pop up the dialog. Move the cursor into the other and now press 'Apply'. The changes in the dialog should apply to the first, 'opened' inset that is stored in a map in the Dialogs class. The code above causes it to be applied to the second inset that contains the cursor. The 'fix' is simple: } else if (action != LFUN_INSET_APPLY && ((result=inset-> // Hand-over to inset's own dispatch: localDispatch(FuncRequest(view(), action, argument))) == DISPATCHED) || (result == DISPATCHED_NOUPDATE)) goto exit_with_message; // If UNDISPATCHED, just soldier on Meaning that the code in BufferView_pimpl.C's dispatch is called to do the right thing. But is there a better way? -- Angus
Re: Inset::localDispatch problem
On Tue, Mar 04, 2003 at 11:16:39AM +, Angus Leeming wrote: > André, as localDispatch is yours, Not really. > perhaps you can help me with this problem. It's come up because I'm > starting to deal with insets which have a dialog but which are also > editable. > > Inset::localDispatch is called from LyXFunc::dispatch (below). If this > fails then the LFUN is passed to BufferView::dispatch which contains a > switch for the different LFUNs. I never understood dispatching out there. > [...] Meaning that the code in BufferView_pimpl.C's dispatch is called > to do the right thing. What's wrong with that. > But is there a better way? The problem ist that functionality is not properly distributed right now. The innermost level that knows to handle an event should handle it. Ideally there should not be (much|any) magical guessing who is responsible. The hierarchy should be something like LyXFunc | BufferView | Buffer | OutermostText [And this should go if everything is an inset] | Insets and we should walk it bottom-up. Currently we have some strange combination of guessing jumps down (the_locking_inset and some hard coded 'let's the inset handle it) and a few steps up... Some jumps probably can't be avoided, though. Pressing apply could invoke an lfun "LFUN_DIALOG_APPLY" which is handled only in the Bufferview (or whatever entity knows which inset is "open"). The bv catches this event and issues another "LFUN_DIRECT_APPLY" event to the proper inset. Something like that... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Inset::localDispatch problem
On Tuesday 04 March 2003 12:54 pm, Andre Poenitz wrote: > The innermost level that knows to handle an event should handle it. Ideally > there should not be (much|any) magical guessing who is responsible. > > The hierarchy should be something like > > LyXFunc > > BufferView > > Buffer > > OutermostText [And this should go if everything is an inset] > > Insets > > and we should walk it bottom-up. Currently we have some strange combination > of guessing jumps down (the_locking_inset and some hard coded 'let's the > inset handle it) and a few steps up... > > Some jumps probably can't be avoided, though. > > Pressing apply could invoke an lfun "LFUN_DIALOG_APPLY" which is handled > only in the Bufferview (or whatever entity knows which inset is "open"). > The bv catches this event and issues another "LFUN_DIRECT_APPLY" event > to the proper inset. Nice idea actually. Only BufferView handles LFUN_INSET_APPLY. If an inset is open then it calls inset->localDispatch(FuncRequest(bv_, LFUN_INSET_MODIFY, ev.argument)); else it creates a new inset at the current cursor pos. I can do this now... It'll cure my problem with LyXFunc::dispatch and will be ready for the next generation code too. Thanks André. Angus
Re: Inset::localDispatch problem
Andre Poenitz wrote: The hierarchy should be something like LyXFunc | BufferView | Buffer | OutermostText [And this should go if everything is an inset] | Insets and we should walk it bottom-up. Currently we have some strange combination of guessing jumps down (the_locking_inset and some hard coded 'let's the inset handle it) and a few steps up... I don't understand where you see jumps? the above is true and you have to extend it like: ... | Inset | Inset ... | Inset I don't see a jump it goes from the outermost to the innermost and stops there where the event is handled than it returns back. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset::localDispatch problem
On Tue, Mar 04, 2003 at 04:54:07PM +0100, Juergen Vigna wrote:
> I don't understand where you see jumps?
bool BufferView::Pimpl::dispatch(FuncRequest const & ev_in)
{
[...]
default:
return bv_->getLyXText()->dispatch(FuncRequest(ev, bv_));
} // end of switch
}
The Buffer layer is missing.
> I don't see a jump it goes from the outermost to the innermost and stops
> there where the event is handled than it returns back.
It should jump down once, preferably using some thing like a "document
iterator" and go innermost to outermost from there. This is the only way
nested structures can work.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
