On Mon, 18 Oct 2010 17:16:32 +0200
Malte Timmermann <malte.timmerm...@oracle.com> wrote:

> I agree that the pointer stuff is bad, but I don't fully agree with
> "broken by design".
> From a user's perspective, it would look more broken when deleting a
> selection with 50+ pages would take a reasonable amount of time, only
> because some expensive Undo information is being created, which
> probably will never be used.

It is still broken by design. Either you provide stable undo operations
for a scenario or you do not provide undo operations for the scenario at
all. Because you can also be certain that the user you speak of would
prefer no undo for tricky operations rather than an undo stack than
sometimes crahes the application.

> I am also not sure if we really need to create the "Eierlegende
> Wollmilchsau" with a new Undo API, or if most people wouldn't already
> be happy with some API at the document level where the can perform
> StartUndoContext/EndUndoContext/Undo/Redo/Repeat/EnableUndo.

No need for that german pig. However, what is desperately needed is a
basic general concept not only for the interface, but also for the
implementation of undo, including some design patterns (like for
example the simple undo guard proposed in i114888). Otherwise we will
end up with conflicting designs, which is hard to clean up. To clarify:
I dont want to rewrite all of undo at once -- but at least we should
have a shared and documented vision how it is _supposed_ to work.



To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org

Reply via email to