Happy New Year to you all and Congratulations to Jürgen and Susanna!
I'm slowly getting back into the swing of things here...
Dekel Tsur wrote:
> If I open the citation dialog, adds a new key to the inset keys list, and
> then press on one of the existing inset keys (or on the newly inserted key),
> then the OK button becomes disabled, even though the inset keys list has
> changed.
To fix this bug we need to extend the ButtonController a little. However, this
demonstrates the power of
Asger's Model/View/Controller separation; the bug is present in many dialogs
but correct the controller and all the GUI's benefit. Ok, I know.
ButtonController is Xforms-specific at the moment, but it should be made
generic.
Here's the relevant code as it stands:
void FormBase::InputCB(FL_OBJECT * ob, long data)
{
FormBase * pre = static_cast<FormBase*>(ob->form->u_vdata);
pre->bc_.valid(pre->input(ob, data));
}
That is, the ButtonController bc_ uses the result from FormXXX::input() as a
trigger to activate/deactivate the buttons under its control. (The OK, Apply,
Restore, Cancel/Close buttons.)
FormXXX::input() returns true/false if the input is valid/invalid. At the
moment, however, the ButtonController uses this information indiscriminately
and so the buttons are changed at times when they shouldn't, such as in Dekel's
bug report here.
I think that the power of the ButtonController can best be realised by
modifying ButtonController::valid(bool) to ButtonController::valid(bool,
FL_OBJECT *).
Now we can disciminate between those FL_OBJECTs that affect the parameters
returned to the kernel and those that don't.
Valid Input FL_OBJECT action
true change to kernel
activate Ok/Apply
false
deactivate Ok/Apply
true no
change do nothing
false
do nothing
All we need now is a ButtonController method to add to an internal store of
FL_OBJECTs that will trigger a change in the kernel. Ie, analogous to:
ButtonController::addReadOnly(FL_OBJECT *);
have
ButtonController::addTriggerChange(FL_OBJECT *);
Is there a flaw in my logic? Please feel free to comment.
I'll make the changes in my tree here and test this out, but won't submit till
1.1.6 is out. In my opinion, the existing bug is bearable and I might well
introduce something nastier by trying this now.
For those interested: I'm playing with FormCitation here. I have extended it to
support natbib and am now trying to separate the View from the Controller.
(Blame Asger for this! He's got me interested!) I think that this will have
great benefits for all the GUI's because they'll have to do far less if they
can all share a common Controller that defines exactly how they should interact
with the kernel.
Something like:
template <Class ViewCitation, Class ButtonController>
class ControlCitation {
// methods/slots controlling interation with the LyX kernel
// ie, showInset(), createInset(), ApplyChange() etc.
// Also code to set/receive things in/from ViewCitation.
...
private:
// GUI-specific dialog class does nothing but receive/return an
InsetCommandParams &.
ViewCitation view;
// The existing Xforms-specific ButtonController should be made generic.
BC bc;
}
Thoughts?
Angus
