>> 2. the status of LFUN_INSET_SETTINGS is handled by >> BufferView::getStatus() and the dispatch is handled by >> Text::dispatch(). This looks at least a bit awkward. Shouldn't these >> be handled by the same class ? > >Why not all of them in the relevant inset class? > >> 3. when Text::dispatch() handles the LFUN_INSET_SETTINGS, it resolves
>> the inset of interest and calls inset.showInsetDialog(). >> Should this not be handled by the Inset. Thus Text::dispatch calls >> Inset::dispatch which then calls showInsetDialog. In this way you can >> dispatch the LFUN_INSET_SETTINGS to an Inset (which seems like a good >> thing to do) without running into an assertion. > >Definitely. You may want to experiment with the new AtPoint LyXAction flag. > So, do you have any ideas what to do with the argument of inset-settings ? The only place where this is used is the Edit menu, e.g. 'inset-settings note' 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. One solution would be to highlight the inset that would receive the action (as decided by the AtPoint mechanism). Then it is immediately clear to the user which inset would react to the inset-toggle shortcut or the inset-settings shortcut or the View->Edit inset settings.. In this way, we can remove all the optional menuitems (I think you wanted to do that anyway). Is this a good idea ? Would it be best to revert the AtPoint-thingie ? Or does someone have another idea ? > Jmarc Vincent
