Re: Control::reactivate_and_undo

[Maciej Stachowiak <mjs eazel com>]

Nat Friedman <nat@helixcode.com> writes:

>     Now, in libbonobo this translates to a "reactivate_and_undo"
> signal being raised by the BonoboControl GtkObject.  The control
> implementation can choose to implement it or not to implement it, at
> his option.
> 
>     I do know that we need this functionality in controls.  So I think 
> it should either remain there as-is or be relegated to a separate
> interface that we QI for.
> 
>     Thoughts?

I don't know much about this specific issue, but I think that a
separate interface one QIs for is superior to having a method in an
interface which any given implementation may or may not support. If
it's a separate interface you can query for, then you can easily find
out at any time if the operation will work, and fall back to another
behavior if it doesn't.

And actually, `reactivate_and_undo' desn't really solve all the
problems brought up by Undo in the presence of compound documents in
any kind of nice way, for instance if you want to keep a reasonably
long undo chain that still works if the user switches which components
he is editing many times. I'd think more along the lines of a
Bonobo::Undoable and corresponding Bonobo::Undoable{Client,Observer,
Container} interface which allows the control to pass opaque but
serializable undo mementos to the container would be much more
useful.


And while I'm busy spouting off about Bonobo from a position of
mostly-COM-ignorance, what's up with Bonobo::View? The only methods it
provides are `set_zoom_factor', which reeks of the same
should-be-a-separate-interface-itis as `reactivate_and_undo', and
`do_verb', which doesn't seem to make a whole lot of sense except in
the concept of Bonobo::Embeddable's functionality for querying about
available verbs.

Clue Donations Appreciated,

Maciej