On Friday 24 November 2000 00:12, Allan Rae wrote:
> On Thu, 23 Nov 2000, Angus Leeming wrote:
> > * FormRef should have Restore and Apply buttons. Still thinking about how
> > to do this best.
>
> What exactly do you need to consider? Apart from the choice of policy?
[snip explanation of "policy"]
No, no, nooooooo. I understand all this! I mean simply "where do I put a
Restore and an Apply button on the form!!!!" I'm coming round to the opinion
that:
1. Resizing the dialog depending on whether it's called from an Inset or from
the Menu->New Ref is a nightmare in maintainability. I think I'll go back to
the "single popup-appearance for both" option. This will make Rob Lahaye
happy at least ;-) It'll also fix a BUG reported by Rob when resizing from
one "type" to the other without closing the popup.
2. It'll then be fairly easy to add the new buttons.
3. If we could get the kernel to emit a signal when the TOC and Refs changed,
then we could throw away the Update buttons on both popups. This will require
maintaining a vector<string> for each rather than having a method that
creates the relevant vector<string> from scratch when asked by the popups.
This last point can wait, therefore, till 1.1.6 is out.
[...explanation of policy]
> I better add this to the list of things to put in the GUII docs.
Do that!
> > * The ButtonController should reset the appropriate buttons to inactive
> > when a change is applied or an UndoAll() is requested.
>
> Which buttons?
Let me explain what I meant:
In the case of an OkApplyCancelReadOnly Policy, I'd have four buttons on the
popup:
"Restore" "Ok" "Apply" "Cancel"
Conventional connections of each to the ButtonController.
Make some change in the popup and "Restore" "Ok" "Apply" are activated.
Press "Restore" or "Apply" and the relevant action is activated BUT the
buttons do not then become Inactive. They should. (This is only partly true.
See below:)
Press "Apply".
"Restore" goes inactive, but "Ok" and "Apply" remain active.
Press "Restore"
and all is correct. Ie, "Restore" "Ok" "Apply" all go inactive.
Try it (the Citation popup eg). This should be easy to fix.
Similarly, if I make some change in a popup, but then click on another Inset
of the same type, I lose the changes made (GOOD), but the buttons are still
active (BAD). I should put a ButtonController call in the showInset method.
ButtonController::refresh() or ButtonController::valid(false)?
Incidentally, if I put a ButtonController::refresh() in the popup update()
method, all hell breaks lose. It appears that multiple refresh()s are a BAD
thing!
Angus
> >(Incidentally, why do we still distribute XTL if we're not
> > using it?)
> Because it's small and nice to have around. We were reluctant to bin it
> after the developers meeting.
Oh, purlease....
I see that José is talking to the Boost list about XTL. This is wonderful
news, but will probably mean that XTL changes quite fast quite soon. Then
we'll have a piece of superceeded code there. Makes even less sense.
Angus
