Hello Dániel, > 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.
Well, yes, but ... we do not need to *knowingly* open the doors. I heartily believe we should not offer a public API which makes it *that* easy to corrupt the document. > Another source of bugs could be a macro entering an undoable block, > but not leaving it (due to an exception for example). Interesting point. it might be worth examining how other applications solve this, in particular a certain competitor. > 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. Not sure. As long as the block is open, there effectively isn't an entry for it on the stack, is it? Or, well, it could perhaps be implemented this way: put the action on the stack when the context is opened, and as long as the context is not closed, add new actions as sub actions of the one "context action" only. However, this might required deeper changes, I suppose the current undo manager implementations don't do it this way. Which leads to the question whether the UNO API would be a wrapper around the existing implementations, or replace them. I'd say replacing is much more challenging. > 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. Nice idea. When you have this, then you can even add a context menu "close context" to the item, for exactly the case where the macro failed to close it. This way, we could prevent breaking the complete Undo mechanism in a document - at least the user is able to repair it, then. >> 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. I wouldn't do this without good reason. Again, it opens the door for any kind of actions to seriously corrupt the document - what if somebody calls "undo" for the sixth action on the stack? This would certainly crash! -, so we should have a *very* good use case for this before doing it. > But the undo() and redo() methods could be left there as > convenience methods for the "casual" developer. Actually, I think they should be the only methods. > 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. Yes, in fact that's how the current Undo manager is implemented, too. > I did not yet investigate how it is currently implemented, but this > two-stack model could maybe be reflected in the new UNO interface. Assuming that we do not expose those stacks - see above -, I'd say they're a concept to document, but effectively, the API user won't (really need to) know about it. Ciao Frank > > Best regards, > > Daniel Darabos > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
