>> I don't see a way to use this with the AtPoint LyXAction flag. I >> either have to revert this, or discard the use of this argument. > >Sorry, I probably missed one of your messages, could you tell me >again why they cannot be used together? Is that a technical problem >or a UI problem?
This parameter of inset-settings determines to which Inset the lfun has to be relayed. I haven't seen anything else that has such a parameter. 1. If we want to use the AtPoint mechanism for this, we should take this argument into account when deciding to which Inset to relay. This would mean to put lfun-specific code into LyXAction::dispatch (IIRC), which is ugly. 2. Another way is to reintroduce the handling to BufferView::dispatch, use the argument to decide to which Inset to dispatch to. This is practically the same as it was, but I don't really like this as the handling of the lfun is then scattered over different places. And I'd like to see this handled by a LyXAction flag. 3. Yet another way is to introduce a new LyXAction flag that says that this lfun should be dispatched both to the current inset as to the next inset. In that case, we could process the argument in Inset::dispatch. That would mean AtPointAll (or something like that). (Choosing for this method would also mean to centralize the handling of LFUN_INSET_SETTINGS in the Inset class (to avoid duplicating code) and use an improved editable() mechanism to decide which Inset has a settings dialog (or introduce the hasInsetDialog() function, but I didn't really get the opinion of Andre about this. It was hidden somewhere between irony and a dilemma)). I hope I made it clear. I think I'll vote for 3. >Jmarc Vincent
