On 10/18/2010 05:16 PM, Malte Timmermann wrote:
Or implementations w/o support for ref counting: For example, each
EditEngine Undo action needs to have an EditEngine*.
And EditEngines in OOo are destroyed and re-created quite frequently.
Maybe using an own Undo manager for the EditEngine is
Hi Malte,
Maybe the Undo needs some valid state, or also being able to dispose
itself when it needs to do, and the the UndoManager needs to listen for
that.
Hmm. This would mean silent removal of Undo actions from the undo action
list - not ideal, from an UX POV.
Also, the Undo manager has
Hi Bjoern,
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
On 18/10/2010 14:55, Malte Timmermann wrote:
The Undo actions could have pointers to some data which doesn't exist
anymore, and the extension can't remove the actions from the
UndoManager. Avoiding pointers could mean making the Undo actions more
expensive (memory, time). For example, Writer
Hi Malte, Michael,
Am Mon, 18 Oct 2010 15:46:00 +0200
schrieb Michael Stahl michael.x.st...@oracle.com:
On 18/10/2010 14:55, Malte Timmermann wrote:
The Undo actions could have pointers to some data which doesn't
exist anymore, and the extension can't remove the actions from the
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
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
