Re: Control::reactivate_and_undo




> Now I am really confused. If it is only intended for run-time, why have it
> at all. The only control container that would care about coordinated undo is
> a container that is doing embedding, not control hosts. 

Not really.   Consider a control that provides HTML editing for
example (which is the problem we have at hand).  A Composer window is
being written that uses components for all of its tasks.  The fact
that an application is using Bonobo controls should be transparent to
the user: Undo shoulkd work across the entire application.

> I think it a bit
> far-fetched to assume that a dialog box wants to coordinate undo among its
> controls. 

As I mentioned before, Evolution, our GNOME-based mail client uses a
pile of Bonobo controls to perform its work and as far as the user is
concerned, controls should be invisble to him.

> Sure it is possible but it is like using a tank to kill
> ground-squirrels. Typically a dialog box that hosts controls will have some
> other "undo" mechanism that is just throwing away all the changes. For a
> simple dialog, this is by ignoring the changes in the control (not
> extracting them). 

Sure, this is fine for those controls, and not every control is
required to implement the method to do anything interesting.  They can
just ignore it.  

> For a database form, it by canceling the update to the
> database and reverting the data. The only time I see you want coordinated,
> incremental undo is when the control's state is an integral part of a larger
> state, which sounds like an embedding to me.

An embedding in Bonobo has other side effects: model/view separation,
multiple views must be supported, plus printing (the last one is not
even implemented right now).

Miguel.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]