Allan,
you must be in line for the prize for longest emails in history! I think
we're getting to the point where we really should write some formal
documentation for the GUI stuff again.
It'll take a while to digest, but the basic idea is very powerful. And it
appears that changes in classes using the ButtonController will be minimal,
so stability should not be compromised too badly.
I especially like the ability to have multiple Apply buttons. You describe
Perferences as an example where this would be useful. The External Material
dialog has a Load button that's similar.
Here are a couple of thoughts about the peripheral implementation problems
you're musing about.
A thought about the enums problem. You could wrap the enum in a class. Eg
class SMInput {
public:
///
SMInput(int value) {set(value); }
///
int get() const { return value_; }
///
void set(int value) {
Assert(valid(value));
value_ = value;
}
private:
/// the check is daughter class-specific
virtual bool valid(int value) const {
// check that value lies in the range of
// StandardState values.
}
/// The actual value taken
int value_;
/// The possible values for Standard input, extended by the daughter class
/// perhaps.
enum StandardStates {...};
}
> 5. Cancel/Close is the only button handled explicitly because of the
> desire to change the label at appropriate times.
[...]
> Note that the Cancel/Close stuff is merged into a single group
> and will still need to be handled explicitly since that button is
> relabeled not de/activated.
Baruch has mentioned that he'd like to use a standard gnome Cancel button and
Close button., rather then rewrite the labels.
The Preferences dialog's Converters and Formats tabs have a button that
changes from "Modify" to "Add" depending on the input. Strikes me that this
is identical to the CancelClose stuff.
