Re: Control::reactivate_and_undo

[Nat Friedman <nat helixcode com>]

Chuck Jazdzewski writes:
 > 
 > reactivate_and_undo() is certainly only design-mode behavior 

    It is?  Ok, now I'm confused.  What's design-mode behavior and how
is it distinct from run-mode behavior?

 > It is not clear, however, that to support undo you
 > must be an embedding so that argues for a separate undo interface that
 > Embeddable might inherit from.)

    What about a separate interface altogether, which you QI for but
which the embedding does not derive from?

 > reactivate_and_undo(). It is unclear to me how, in the current spec, you
 > would indicate this.

    Yeah, that's a compelling reason not to put methods which some
people might not want to implement in your interfaces.  The only way
to find out that the methods are not implemented is to try invoking
them.

    So I think it's fine to move this to another interface, though, as
long as it's available for controls.  On the libbonobo side of things, 
I'll probably remove the signal and make it a callback, so that, when
the callback is setup, I can add the interface and the remote end will 
know that we support undo.  Something like:

void
bonobo_control_set_undo_and_reactivate_callback (
        BonoboControl *control, Fn callback)
{
        add_undo_interface (control);
        set_undo_callback (control);
}

I'd like to see what other people think, though.

Nat