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. BR, Bjoern --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
