Re: Bug in citation dialog
> It is an admirable goal to pursuit, but my experience is that it is
> fairly difficult to design a truly generic Controller class across
> different toolkits.
Hi Asger,
Sure. However, I was going to start off by designing a class to control the
interaction of the popup with the LyX kernel. This, at least, is common
between all toolkits. Connecting, disconnecting signals, passing an instance
of a Param class to the GUI-dependent Views (ie, a holder for the info to be
changed/input) and finally retrieving this info and returning it to the LyX
kernel.
This would mean that all the Views have to do is modify the Param instance.
Attached is a preliminary go for the Citation dialog. Note that it doesn't
compile (not least because the View hasn't been created!), but it's complete
and minimal and FEELS a lot better than what exists.
I've come to the conclusion that the ButtonController belongs in the View,
rather than in my ControlCitation class (ie the class controlling the
interaction with the kernel). It remains to be seen whether we can create a
generic ButtonController (ie, put more functionality in the abstract
ViewCitation abstract class).
Note also that I envisage xforms' callbacks and others' signals calling the
Controller's apply() and hide() functions.
Ie, we'd go from:
void FormCitation::ApplyCB(FL_OBJECT * ob, long)
{
FormCitation * pre = static_cast(ob->form->u_vdata);
pre->apply();
pre->bc_.apply();
}
to:
void FormCitation::ApplyCB(FL_OBJECT * ob, long)
{
FormCitation * pre = static_cast(ob->form->u_vdata);
pre->parent.apply(); // ControlCitation & parent;
pre->bc_.apply();
}
Angus
MVC.tar.bz2
Re: Bug in citation dialog
[Extending the ButtonController to be a generic controller, which can handle activation and deactivation of elements in the GUI according to when different criteria are valid.] It is an admirable goal to pursuit, but my experience is that it is fairly difficult to design a truly generic Controller class across different toolkits. This is so, because you have to design the Controller to work with very few behavioural guarantees. For instance, with some toolkits, the changing of an input box can trigger a callback, but in this callback, it is not possible to get the contents of the input box in this callback -- it is not updated until after the callback returns. Now, this should not put you off. I only want to warn you that it might be a longer journey that you plan. The best advise I can give is to design as you go: Only implement what is needed for the toolkit at hand, and when another one is to be assimilated, have a look to see if it is possible. If it is, great. If not, refactor it to handle the new toolkit. It would be a mistake to think that you can design it to encompass all strange toolkits from the start. Greets, Asger
Re: Bug in citation dialog
Allan Rae <[EMAIL PROTECTED]> wrote: > > 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. > > How generic? All of the code in BC is xforms specific. That's the point > of the Policy and Controller separation. Perhaps you just want an > abstract base class? Things became a little clearer with sleep! an astract base class for BC and for View is exactly what I want. > I'll get back to reading this fully later tonight (better go do some work > soon) but maybe you should ask: > >Why does input() say the inputs are invalid when Dekel clicks on a key? > > AFAI can see input should be returning true not false. This is correct. I have almost certainly got mixed up here, trying not to activate the buttons by simply clicking on the keys. The bug is mine! However, the point of the previous mail was to extend the ButtonController to get the behaviour I want and that still holds. > Anyway as I said, I'll reread your proposal later tonight and comment > again then. Please do. I value the input. Angus
Re: Bug in citation dialog
On Tue, 9 Jan 2001, Angus Leeming wrote: > Happy New Year to you all and Congratulations to Jürgen and Susanna! Happy New Year to you also. > 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. How generic? All of the code in BC is xforms specific. That's the point of the Policy and Controller separation. Perhaps you just want an abstract base class? Or maybe we need a more extensive range of state machine inputs? Instead of just SMI_VALID and SMI_INVALID we might also add others related to inputs (but I don't see that being necessary)? I'll get back to reading this fully later tonight (better go do some work soon) but maybe you should ask: Why does input() say the inputs are invalid when Dekel clicks on a key? AFAI can see input should be returning true not false. This is more likely to be a problem with the incomplete conversion of some of the dialogs (particularly the inset-related dialogs like citation) to using a button controller. Anyway as I said, I'll reread your proposal later tonight and comment again then. Allan. (ARRae)
Re: Bug in citation dialog
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(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 InputFL_OBJECT action
truechange to kernel
activate Ok/Apply
false
deactivate Ok/Apply
trueno
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 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
Bug in citation dialog
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.
