I guess that I should be nice to the Qt frontend too, so I'll hang back until that is done. However, the attached patch is the Brave New World of controllers and I'd value your considered perusal.
The new frontends/controllers/Dialogs.[Ch] is a full Model-Controller-View
split of a generic dialog and is a whole lot easier to get to grips with
than the old mess of nested, templatised classes. So, John, I think you're
in luck ;-)
Things elsewhere are still a little messy because the Old and the New
currently co-exist; I've 'done' all those dialogs whose controller derives
from ControlCommand.
You can now open and close these dialogs from the minibuffer and feasibly
pass in strings from outside by way of the lyxserver to insert new insets
with full control over the contents. The hook exists
(LFUN_DIALOG_SHOW_NEXT_INSET "name") to open the dialog of the next inset
after the cursor of a given type (or even just the next inset with a
dialog...) but there is no code to do so and I don't propose adding it.
feel free to take up that particular baton. Ditto, no hook exists yet to
pass the contents of an existing inset to the lyxserver but I anticipate it
being little more than what now happens in Inset::edit.
André, two things for you to ponder and investigate:
1. I can launch the reference dialog from within mathed and the returning
contents are captured by LFUN_REF_APPLY within formulabase.C. The ref_inset
is created (witness the lyxerr message printed from the c-tor) but the
inset is not inserted. Over to you, maestro.
2. I don't think that the current scheme is safe wrt mathed:
In InsetFormulaBase::localDispatch I have:
case LFUN_REF_APPLY: {
InsetBase * base =
bv->owner()->getDialogs().getOpenInset("ref");
RefInset * inset = static_cast<RefInset *>(base);
and in BufferView::Pimpl::dispatch I have:
case LFUN_REF_APPLY: {
InsetBase * base = owner_->getDialogs().getOpenInset("ref");
InsetRef * inset = static_cast<InsetRef *>(base);
I can conceive of an inset outside mathed being pressed and lauching the
dialog, registering with the Dialogs class that it is 'Open'. The cursor
moves inside mathed and so the 'Apply' is captured by mathed's
localDispatch which is BAD for obvious reasons.
One possible solution is to use dynamic_cast rather than static_cast:
case LFUN_REF_APPLY: {
string const data = ...; // extracted from argument
InsetBase * base = bv->owner()->getDialogs().getOpenInset("ref");
if (!base) {
RefInset * inset = new RefInset(data);
mathcursor->insert(MathAtom(inset));
break;
}
// If it's actually an InsetRef *, then this fails
RefInset * inset = dynamic_cast<RefInset *>(base);
if (!inset) {
result = UNDISPATCHED;
break;
}
// modify the contents of the existing inset.
...
}
break;
What do you think? (I realise that this may eventually be a redundant
worry.) Note also that mathed's RefInset still uses getAsString with its
nasty '|++|' separators. It shouldn't/need not any more...
--
Angus
controllers.diff.bz2
Description: BZip2 compressed data
