Frank Schönheit wrote: > > b) hide an action from the undo mechanism
> This is dangerous, IMO: It would potentially leave the document in an > inconsistent state. For instance, imagine a simple text document with a > line of text. Let the user format a portion of this text as bold. Now, > run a macro which removes the text line, and, for some reason, decides > to "hide" this action from the Undo mechanism. (Note that there can be > any reason for this behaviour, including simple bugs in the macro, or > malicious code which does this intentionally.) A malicious extension could simply send all the contents of your hard drive to its evil author and format it afterwards :). Even my benign Python extensions have found several ways to crash OpenOffice.org (the simplest way being an infinite loop). I think it is mostly hopeless to try eliminating the possibility of bugs from extensions. > So, I think your b) can only be implemented in a way that the action is > added to the Undo stack, but perhaps not visible to the user. In the > above example, this would mean that Undo would first Undo the deletion, > then the formatting - while to the user, this is presented as "Undo the > formatting", since the macro decided to "hide" the deletion. Despite my previous pessimistic comment I like this idea very much! Thank you, when I get to it I will go about it this way! > > I cannot tell if these are even possible > > I think it's possible, and I even think it should not be too difficult. > Of course Mathias said differently, and he has more insights into the > application code than I have. I would like to believe you :). > I think an Undo API needs to address / care for (at least) the following: > > 1. A Macro wants to control the granularity of Undo actions which are > created while it works on the document. > In the simplest case, this means it wants to do a "enter undoable > block" at the beginning of the macro, and a "leave undoable block" > at the end, this way creating only one undo action for all > operations. Another source of bugs could be a macro entering an undoable block, but not leaving it (due to an exception for example). While I do not think it can be recognized, its effects could be alleviated, by automatically leaving the undo block when its undo action is called. This way everything would go back to normal after the user has clicked Undo. This would roll back everything until before the run of the buggy macro, but if the user now clicks Redo, everything would be restored. Of course it is not a perfect solution -- do you have any better ideas? Maybe a visual indicator that the program is in an undo block would be useful (in the status bar for example). An extension may have valid reasons to have the user execute a series of actions that will be put into a single undo block, but a visual indicator would never hurt. > 2. A macro wants to trigger Undo/Redo itself Although it is already possible via the dispatch mechanism it really has its place in an Undo API. > 4. Changes to a document done while Undo/Redo is running must, if > course, not contribute to the Undo stack. Very good point. > If I'd try a quick shot aiming at an Undo API, it would be something like Sounds very good! Maybe instead of the undo() and redo() methods in the XUndoManager it could have a Sequence< XUndoAction > getUndoActions() method. But the undo() and redo() methods could be left there as convenience methods for the "casual" developer. Now that I think about it, the Undo Manager has two stacks -- an undo stack an a redo stack. You can only call undo on the action on top of the undo stack and redo on the top of the redo stack. Undoing an action moves it from the top of the undo stack to the top of the redo stack (and vice versa), while adding a new action to the undo stack clears the redo stack. I did not yet investigate how it is currently implemented, but this two-stack model could maybe be reflected in the new UNO interface. Best regards, Daniel Darabos --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
