Re: [api-dev] Attempt for an UNO Undo API
Hi Mathias, Not sure I'd sign this. Technically, I could imagine the embedded object adding Undo actions to the Undo manager of the container document (letting those actions survive/handle the temporary destruction of the embedded object when it is deactivated is, well, a challenge only, not an impossibility, I suppose :) ). Whether this is desired from an UX point of view might be a different question. This will break at least if the OLE object is not an OOo object. :-P Sure, the implicit premise for the above statement was embedded OOo object :-P Besides that, of course nothing is impossible in software. That's an urban legend. Except you can show me the piece of code which solves the halting problem. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/28/2010 10:03 AM, Frank Schönheit wrote: Hi Mathias, I think that editing of OLE objects (and linked sheets are just a variant of them) should stay as they are: while you are editing the object, you might be able to undo parts of the editing, but after leaving the OLE object all changes made in this session can only be undone as a whole. A new API can't remove the intrinsic limitations of this concept. Not sure I'd sign this. Technically, I could imagine the embedded object adding Undo actions to the Undo manager of the container document (letting those actions survive/handle the temporary destruction of the embedded object when it is deactivated is, well, a challenge only, not an impossibility, I suppose :) ). Whether this is desired from an UX point of view might be a different question. This will break at least if the OLE object is not an OOo object. :-P Besides that, of course nothing is impossible in software. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/26/2010 03:07 PM, Andrew Douglas Pitonyak wrote: Although I am ignorant in much of this, I do have some random thoughts. Mathias Bauer mentioned allowing the container to control changes for some items (such as he did with notes2), but that this may be a problem with larger objects such as graphics objects and even OLE objects. Right, it doesn't work for OLE objects, but in case the object could provide undo actions that don't require to be in edit mode, it should work for even the largest graphic objects. The difference between graphic objects and OLE objects is that the graphic object does not vanish after editing - it just may be in a different mode. But that is also true for the container itself where different shell objects are created and removed depending on the current editing context. On the other hand, I do not expect that an OLE object will have any ability to actively participate in the undo process, which forces implementation back to the container (or you simply state that changes made to an OLE object internally are not undoable). For some reason, I keep thinking about the implications of a linked sheet in a Calc document. I think that editing of OLE objects (and linked sheets are just a variant of them) should stay as they are: while you are editing the object, you might be able to undo parts of the editing, but after leaving the OLE object all changes made in this session can only be undone as a whole. A new API can't remove the intrinsic limitations of this concept. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Mathias, I think that editing of OLE objects (and linked sheets are just a variant of them) should stay as they are: while you are editing the object, you might be able to undo parts of the editing, but after leaving the OLE object all changes made in this session can only be undone as a whole. A new API can't remove the intrinsic limitations of this concept. Not sure I'd sign this. Technically, I could imagine the embedded object adding Undo actions to the Undo manager of the container document (letting those actions survive/handle the temporary destruction of the embedded object when it is deactivated is, well, a challenge only, not an impossibility, I suppose :) ). Whether this is desired from an UX point of view might be a different question. Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Andrew, Although I am ignorant in much of this, I do have some random thoughts. appreciated, as always :) Mathias Bauer mentioned allowing the container to control changes for some items (such as he did with notes2), but that this may be a problem with larger objects such as graphics objects and even OLE objects. On the other hand, I do not expect that an OLE object will have any ability to actively participate in the undo process, which forces implementation back to the container (or you simply state that changes made to an OLE object internally are not undoable). For some reason, I keep thinking about the implications of a linked sheet in a Calc document. I have no final opinion on this at the moment. I think we'll come back to the topic in version 2.0 of the API, when we exemplarily (will have to) solve this for charts embedded in Calc. There was also talk of throwing multiple types of exceptions when an error occurs. Does this prevent some languages (such as Basic, Perl, and similar) from participating in this scheme? No. Throwing (read: allowing to throw) multiple exceptions is nothing unusual in the UNO API, so those language bindings will have as little (or as much - not sure, for instance, how/if throwing UNO exceptions works there) problems as with any other UNO API. Can/will the undo API affect extensions? I hope so :) Extensions doing multiple changes in a row are one major scenario to be addressed by the API (see my original mail in the thread). Any thoughts on database actions? It does not seem reasonable that a SQL statement will participate, even for an internal Base document, this could be a very long running transaction. I don't think that it makes sense to implement this for databases. In Base, Undo is not even present at the UI (if we talk about data changes - it well exists in UI components such as the query/table/forms/reports designers), so there's nothing the API implementation could be based on, at the moment. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Ingrid, I think a new UndoFailedException is better than css.uno.Exception. A client can react on this with a small cleanup of whatever UndoStack related doings and than proceed further. While catching a css.uno.Exception the proper reaction is much more unclear. Maybe it is necessary to quit the whole process? That's something I'd expect a RuntimeException to be used for (though ... seeing the number of RuntimeExceptions thrown during normal operation of OOo, this argument isn't too valid. Which could bring us back to missing exception specifications in our API designs, if we really wanted to ...). In reacting on the error during Undo, I don't see a real difference between Exception and a specific UndoFailedException. However, in using the API, and maybe propagating exceptions up the stack, a specific exception is slightly better for knowing what went wrong than a generic one, I'd say. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Stephan, - Normal return; the underlying data model is in a state where the respective changes are indeed undone. - Exception failed for some reason, undo call completely rolled back, i. e. the underlying data model is in the state it was in before the call to undo. It would probably be useful (if only for debugging) to transport the for some reason in the exception (as an any containing an exception). Yes, already thought about adding some TargetException or so to the UndoFailedException. Decided against it, since I was not sure whether it has a real benefit. However for debugging is a benefit :), so I'll add it. - Exception failed for some reason, but not rolled back, i. e. the underlying data model is in some valid state, but it is potentially neither the state before the call to undo, nor the state of a successful undo. Again, it would probably be useful to transport the for some reason. I don't think distinguishing those two cases (undo call rolled back completely and undo partially done) makes too much sense. In any case, the only reasonable option for the caller is to clear the respective stack, since it cannot know whether invoking the action will succeed next time (temporary vs. permanent failures). Also, not having the distinction simplifies the implementation of the actions, making them less error-prone. Thanks Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/27/10 10:14, Frank Schönheit wrote: In reacting on the error during Undo, I don't see a real difference between Exception and a specific UndoFailedException. However, in using the API, and maybe propagating exceptions up the stack, a specific exception is slightly better for knowing what went wrong than a generic one, I'd say. A specific exception can be much better than only slightly better here, if you give it useful semantics. (The semantics of a generic exception being that the program is in an unknown state.) -Stephan - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Stephan, I think any kind of error can happen inside an undo implementation for a single action, so I can't think of any reasonable limitation here. A WrappedTargetException might be appropriate, but then again, this is just an euphemism for anything can happen. I see it differently. ... If an initial undo method has been specified to raise n different exceptions, and it is later found out that an additional exception E' would be needed, there are two choices: - E' is of general interest to callers of undo, they would want to react to it in specific ways. This is similar to detecting that a method misses a parameter: Extend the method (add the raises-specification to the existing method definition, rendering it incompatibly, or add a new interface with the fixed method), fix up the implementation, fix up the call sites. Given the hurdles imposed on incompatible API changes, I dare to go this way - experience shows rarely anybody ever goes through this pain, only for having a clean API. Usually one ends up with throwing, guess, WrappedTargetRuntimeExceptions (I thus consider the mere existence of this class a bad hack. Well, a way-too-easy door opener for bad hacks, that is.). For the moment, I declared an UndoFailedException, derived from css.uno.Exception, and let undo/redo throw it. Still an euphemism for anything can go wrong, though, so I am not that happy with it ... Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/26/10 11:48, Frank Schönheit wrote: I think any kind of error can happen inside an undo implementation for a single action, so I can't think of any reasonable limitation here. A WrappedTargetException might be appropriate, but then again, this is just an euphemism for anything can happen. I see it differently. ... If an initial undo method has been specified to raise n different exceptions, and it is later found out that an additional exception E' would be needed, there are two choices: - E' is of general interest to callers of undo, they would want to react to it in specific ways. This is similar to detecting that a method misses a parameter: Extend the method (add the raises-specification to the existing method definition, rendering it incompatibly, or add a new interface with the fixed method), fix up the implementation, fix up the call sites. Given the hurdles imposed on incompatible API changes, I dare to go this way - experience shows rarely anybody ever goes through this pain, only for having a clean API. Usually one ends up with throwing, guess, WrappedTargetRuntimeExceptions (I thus consider the mere existence of this class a bad hack. Well, a way-too-easy door opener for bad hacks, that is.). For the moment, I declared an UndoFailedException, derived from css.uno.Exception, and let undo/redo throw it. Still an euphemism for anything can go wrong, though, so I am not that happy with it ... For undo, I see three interesting return cases: - Normal return; the underlying data model is in a state where the respective changes are indeed undone. - Exception failed for some reason, undo call completely rolled back, i. e. the underlying data model is in the state it was in before the call to undo. It would probably be useful (if only for debugging) to transport the for some reason in the exception (as an any containing an exception). - Exception failed for some reason, but not rolled back, i. e. the underlying data model is in some valid state, but it is potentially neither the state before the call to undo, nor the state of a successful undo. Again, it would probably be useful to transport the for some reason. Everything else (failed, and the underlying data model is in some potentially invalid state) calls for a runtime exception. So, the UndoFailedException might indeed be the way to go here. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Frank, Frank Schönheit wrote: For the moment, I declared an UndoFailedException, derived from css.uno.Exception, and let undo/redo throw it. Still an euphemism for anything can go wrong, though, so I am not that happy with it ... I think a new UndoFailedException is better than css.uno.Exception. A client can react on this with a small cleanup of whatever UndoStack related doings and than proceed further. While catching a css.uno.Exception the proper reaction is much more unclear. Maybe it is necessary to quit the whole process? Kind regards, Ingrid - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Although I am ignorant in much of this, I do have some random thoughts. Mathias Bauer mentioned allowing the container to control changes for some items (such as he did with notes2), but that this may be a problem with larger objects such as graphics objects and even OLE objects. On the other hand, I do not expect that an OLE object will have any ability to actively participate in the undo process, which forces implementation back to the container (or you simply state that changes made to an OLE object internally are not undoable). For some reason, I keep thinking about the implications of a linked sheet in a Calc document. Now it sounds like two possible interfaces, one controlled by the container and one controlled by the object (that may have an edit engine). There was also talk of throwing multiple types of exceptions when an error occurs. Does this prevent some languages (such as Basic, Perl, and similar) from participating in this scheme? Can/will the undo API affect extensions? Any thoughts on database actions? It does not seem reasonable that a SQL statement will participate, even for an internal Base document, this could be a very long running transaction. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/22/2010 09:01 PM, Frank Schönheit wrote: As a sketch for the later evolution, we think that the XUndoManagerSupplier comes handy here: The chart model would be such a supplier, and for the moment, it would return an own, model-local instance of the XUndoManager. The later extension would be to let it provide the XUndoManager of the embedding document. In theory, this should be completely transparent to the client, which would simply add its actions to another instance, without actually noticing it. In practice, the concrete XUndoAction implementations of course might need to be adjusted (what if you do changes to the chart, then delete the chart, then do Undo multiple times? The chart Undo actions might have a reference to an outdated chart model then.). Also, you would not want to provide, in the menu/toolbox, Undo actions of the embedding document while the Chart is activated. I'm still worried about the problem I foresee, but we can postpone that until things get more concrete. Regardless of this, we agreed that in this first step, we will migrate Chart's XUndoManager to the new one, laying a common ground in all applications this way, which will also be prepared for the above-mentioned changes. Ciao Frank PS: If only a Writer developer could lend me a hand for implementing the new ::svl::IUndoManager interface on top of Writer's own home-grown Undo implementation, the whole thing would be nearly finished :) Sure. :-) As promised, we will do our very best. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/22/2010 09:07 PM, Frank Schönheit wrote: Hi Mathias, I think the Chart does qualify for all those Usage scenarios. Changes in Calc can lead to changes within the Chart that should be offered as one UNDO action together. Further the changes made within the Chart should be visible in the global UNDO stack also. I'm not sure if that is a good idea. IMHO an undo action only should record direct actions in the document core of the undo provider. If this action causes changes elsewhere (e.g. by a listener mechanism), they should not be recorded as it can be assumed that the opposite change in the core (when the undo action is executed) will cause the appropriate change in the listening component also. Well, one scenario Ingrid and I discussed here is the deletion of rows/columns which are part of a source range for a chart. If this is undone, the best chart can currently notice is the insertion of a row/column. Whether or not this column was part of the source range is not part of the broadcast event - not much of a chance for Chart to find out. This implies that chart source range handling/undo should be done in Calc. On the other hand, this means Calc (or any application embedding charts) needs to know pretty much details about Chart's handling of data source ranges - imagine all the different chart types, and the degrees of freedom you have for their defining their data sources. Which means that extensions to the Chart core might require extensions to the core of the embedding documents - not really desirable. Those problems are probably solvable (and as said, we don't aim for those solutions for 1.0), but I am not convinced it is as easy as saying undoing an instigating change will automatically undo the resulting change - simply because currently, listeners might not always transport enough information for this. Let me put it that way: undo actions should only record direct actions. If changes in a component cause indirect changes elsewhere (e.g. by a listener connection), these changes should not be recorded in an undo action. Or the other way around: if actions in a sub component are recorded, they should be made directly by the super component. Otherwise you will get ugly code that always needs to know whether it is currently in an undo action or not. This code is very prone to regressions. Been there, done that, got to hate that. If the information provided to a listener is not sufficient, that should be changed. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Mathias, Let me put it that way: undo actions should only record direct actions. If changes in a component cause indirect changes elsewhere (e.g. by a listener connection), these changes should not be recorded in an undo action. Or the other way around: if actions in a sub component are recorded, they should be made directly by the super component. Otherwise you will get ugly code that always needs to know whether it is currently in an undo action or not. This code is very prone to regressions. Been there, done that, got to hate that. If the information provided to a listener is not sufficient, that should be changed. Let's agree to agree in theory :). I don't say its impossible (interestingly, while thinking about different ways to solve the problems raised by Ingrid's Chart-scenario, I also found that something like isUndoRunning is *only* needed if you violate the above, otherwise, we can go without it - which I'd prefer, since it's inherently broken in MT environments. Thus, in the current API in my CWS, it doesn't exist.), for the moment, it's just that I am really curious how difficult this turns out to be in reality ... Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
XUndoAction, XUndoManager, XUndoManagerSupplier - find the generated IDL for the proposed API at http://udk.openoffice.org/files/documents/23/4795/undo.zip Updated this, just in case somebody wants to have a look at the current evolution. Now with more bells and whistles, like locking the Undo manager, listener notification, and the like. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
XUndoAction, XUndoManager, XUndoManagerSupplier - find the generated IDL for the proposed API at http://udk.openoffice.org/files/documents/23/4795/undo.zip Updated this, just in case somebody wants to have a look at the current evolution. Anybody having an opinion on 1. whether XUndoManager.undo/redo, when invoked while an Undo context is open, should a. throw b. silently and implicitly close all open contexts c. ignore the call d. other? 2. whether XUndoAction.undo/redo should be allowed to raise exceptions (except the always-possible RuntimeException)? 3. how to deal with XUndoAction.undo/redo throwing an exception? a. silence the error? b. propagate the error to the caller of XUndoManager.undo/redo c. clear the respective stack, since obviously the top action cannot be invoked, thus the other actions, which may depend on the top action, also can't d. both b. and c. I tend to 1a., 2-yes, and 3d., but would appreciate any opinion on this. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Am 25.10.2010 14:37, schrieb Frank Schönheit: XUndoAction, XUndoManager, XUndoManagerSupplier - find the generated IDL for the proposed API at http://udk.openoffice.org/files/documents/23/4795/undo.zip Updated this, just in case somebody wants to have a look at the current evolution. Anybody having an opinion on 1. whether XUndoManager.undo/redo, when invoked while an Undo context is open, should a. throw b. silently and implicitly close all open contexts c. ignore the call d. other? 2. whether XUndoAction.undo/redo should be allowed to raise exceptions (except the always-possible RuntimeException)? 3. how to deal with XUndoAction.undo/redo throwing an exception? a. silence the error? b. propagate the error to the caller of XUndoManager.undo/redo c. clear the respective stack, since obviously the top action cannot be invoked, thus the other actions, which may depend on the top action, also can't d. both b. and c. I tend to 1a., 2-yes, and 3d., but would appreciate any opinion on this. Agreeing to all, 1a to educate the user of the API to correctly close open contexts... :) Daniel - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/25/10 14:37, Frank Schönheit wrote: Anybody having an opinion on 1. whether XUndoManager.undo/redo, when invoked while an Undo context is open, should a. throw b. silently and implicitly close all open contexts c. ignore the call d. other? 2. whether XUndoAction.undo/redo should be allowed to raise exceptions (except the always-possible RuntimeException)? 3. how to deal with XUndoAction.undo/redo throwing an exception? a. silence the error? b. propagate the error to the caller of XUndoManager.undo/redo c. clear the respective stack, since obviously the top action cannot be invoked, thus the other actions, which may depend on the top action, also can't d. both b. and c. I tend to 1a., 2-yes, and 3d., but would appreciate any opinion on this. IIUC, 1a means throwing for a temporary failure, so 3c appears to be too aggressive? Also, question 2 should rather be what exceptions exactly should be raised, right? -Stephan - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Daniel, 1. whether XUndoManager.undo/redo, when invoked while an Undo context is open, should a. throw ... Agreeing to all, 1a to educate the user of the API to correctly close open contexts... :) :) Education is a good Thing (TM), I agree. There's one point in favor of auto-closing open contexts: There might be script errors, which leave the stack in a corrupted state. At the moment, there would be no chance to correct this - except by trying to leave as many contexts as possible, which is somewhat cumbersome. (At the UI, you wouldn't even have this possibility: If a broken script leaves a context open, then the non-script user has no chance at all.) However, I plan to (at least evaluate whether to) auto-close all open contexts after running a script. That is, if you'd bind a script to, say, some toolbar item, and this script is ran, then the framework could close all contexts left behind by the script. This would still allow for education of API clients :), but wouldn't bother the user too much with the results of broken scripts. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/25/10 16:02, Frank Schönheit wrote: 1. whether XUndoManager.undo/redo, when invoked while an Undo context is open, should a. throw b. silently and implicitly close all open contexts c. ignore the call d. other? 2. whether XUndoAction.undo/redo should be allowed to raise exceptions (except the always-possible RuntimeException)? 3. how to deal with XUndoAction.undo/redo throwing an exception? a. silence the error? b. propagate the error to the caller of XUndoManager.undo/redo c. clear the respective stack, since obviously the top action cannot be invoked, thus the other actions, which may depend on the top action, also can't d. both b. and c. I tend to 1a., 2-yes, and 3d., but would appreciate any opinion on this. IIUC, 1a means throwing for a temporary failure, so 3c appears to be too aggressive? Ah, interesting. No, I didn't think about temporary failures - e.g. ones whose cause may have vanished when undo is called the next time. Do you think it might make sense to have this distinction? permanent vs. temporary failures? In this case 3c is too aggressive, indeed. Sorry, I had mixed things up. Forget my comment. Also, question 2 should rather be what exceptions exactly should be raised, right? Well, yes. Having seen too many APIs where the specified exceptions are too ... limited, I thought of allowing a plain css.uno.Exception. Your question seems to imply you would argue for a more specific error :) I think any kind of error can happen inside an undo implementation for a single action, so I can't think of any reasonable limitation here. A WrappedTargetException might be appropriate, but then again, this is just an euphemism for anything can happen. I see it differently. A UNO method T m(...) raises E1, ..., En has n+2 ways to return: return normally, return by throwing E1, ..., return by throwing En, or return by throwing a runtime exception. For the first n+1 cases, it is specified in what a state the program is after returning from the method (so program code can meaningfully react to the specific case). For the last case (throwing a runtime exception), the state is less specified, and it typically does not make sense to react in a targeted manner (other than to clean up and propagate the error further out). If an initial undo method has been specified to raise n different exceptions, and it is later found out that an additional exception E' would be needed, there are two choices: - E' is of general interest to callers of undo, they would want to react to it in specific ways. This is similar to detecting that a method misses a parameter: Extend the method (add the raises-specification to the existing method definition, rendering it incompatibly, or add a new interface with the fixed method), fix up the implementation, fix up the call sites. - E' is not of general interest to callers of undo, they would not react to it in specific ways, anyway. Then use a runtime exception (potentially WrappedTargetRuntimeException) to propagate it from undo. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Moin, sorry for being late. There have been a lot of mails to read in the last days. ;-) On 15.10.2010 20:23, Ingrid Halama wrote: I think the Chart does qualify for all those Usage scenarios. Changes in Calc can lead to changes within the Chart that should be offered as one UNDO action together. Further the changes made within the Chart should be visible in the global UNDO stack also. I'm not sure if that is a good idea. IMHO an undo action only should record direct actions in the document core of the undo provider. If this action causes changes elsewhere (e.g. by a listener mechanism), they should not be recorded as it can be assumed that the opposite change in the core (when the undo action is executed) will cause the appropriate change in the listening component also. Doing that differently will create such a code mess we have in the Writer core when it comes to Undo. :-) So the Chart would be an ideal candidate for a test implementation. I would like to join your efforts, if time fits. :-) There might be some extra complications to expect regarding the OLE inplace editing mode and the OLE swapping mechanism. That could become ugly, maybe ... . Indeed, chart actions that are recorded while the component is activated, are dangerous, as executing them later when the component is no longer active and perhaps even disposed will at least make the implementation rather tricky - if not even a disaster. As the other nice improvements we can bring to extension developers should be ready rather today than tomorrow, I would opt for a simple implementation that does not try to use combined undo stacks from different components. Being able to group actions caused by API calls that - from the POV of the extension - should be one combined entry in the undo stack is worth the implementation already. Whether we want to use that for combined undo stacks also is something we should decide for version 2.0 of the implementation (it wouldn't influence the API, IMHO). Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Mathias, As the other nice improvements we can bring to extension developers should be ready rather today than tomorrow, I would opt for a simple implementation that does not try to use combined undo stacks from different components. Being able to group actions caused by API calls that - from the POV of the extension - should be one combined entry in the undo stack is worth the implementation already. Whether we want to use that for combined undo stacks also is something we should decide for version 2.0 of the implementation (it wouldn't influence the API, IMHO). Ingrid and /me discussed this offline a few days ago, and we also agreed that the Undo stack combination should not be part of version 1.0 of the API. As a sketch for the later evolution, we think that the XUndoManagerSupplier comes handy here: The chart model would be such a supplier, and for the moment, it would return an own, model-local instance of the XUndoManager. The later extension would be to let it provide the XUndoManager of the embedding document. In theory, this should be completely transparent to the client, which would simply add its actions to another instance, without actually noticing it. In practice, the concrete XUndoAction implementations of course might need to be adjusted (what if you do changes to the chart, then delete the chart, then do Undo multiple times? The chart Undo actions might have a reference to an outdated chart model then.). Also, you would not want to provide, in the menu/toolbox, Undo actions of the embedding document while the Chart is activated. Regardless of this, we agreed that in this first step, we will migrate Chart's XUndoManager to the new one, laying a common ground in all applications this way, which will also be prepared for the above-mentioned changes. Ciao Frank PS: If only a Writer developer could lend me a hand for implementing the new ::svl::IUndoManager interface on top of Writer's own home-grown Undo implementation, the whole thing would be nearly finished :) -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Mathias, I think the Chart does qualify for all those Usage scenarios. Changes in Calc can lead to changes within the Chart that should be offered as one UNDO action together. Further the changes made within the Chart should be visible in the global UNDO stack also. I'm not sure if that is a good idea. IMHO an undo action only should record direct actions in the document core of the undo provider. If this action causes changes elsewhere (e.g. by a listener mechanism), they should not be recorded as it can be assumed that the opposite change in the core (when the undo action is executed) will cause the appropriate change in the listening component also. Well, one scenario Ingrid and I discussed here is the deletion of rows/columns which are part of a source range for a chart. If this is undone, the best chart can currently notice is the insertion of a row/column. Whether or not this column was part of the source range is not part of the broadcast event - not much of a chance for Chart to find out. This implies that chart source range handling/undo should be done in Calc. On the other hand, this means Calc (or any application embedding charts) needs to know pretty much details about Chart's handling of data source ranges - imagine all the different chart types, and the degrees of freedom you have for their defining their data sources. Which means that extensions to the Chart core might require extensions to the core of the embedding documents - not really desirable. Those problems are probably solvable (and as said, we don't aim for those solutions for 1.0), but I am not convinced it is as easy as saying undoing an instigating change will automatically undo the resulting change - simply because currently, listeners might not always transport enough information for this. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Malte, It seems that the idea is that any extension could put it's own Undo actions in some others UndoManager. But what if the Extension terminates (no crash, but by intention), while I still work with the document? 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 and EditEngine simply keep Paragraph* when paragraphs ar Since we're talking about UNO implementations here, there's no such thing as pointers, only references. So, the code triggering the Undo/Redo should be prepared for DisposedExceptions, at least. Last but not least: When one common API for Undo should be used everywhere longterm, it needs to have support for Repeat (which then can lead to other funny situations, when some primary undo actions don't have repeat support, while the according hidden actions have...) At the moment, I don't aim for using one UNDO-API everywhere. In fact, I am convinced that the new UNO API, for now (!), should be a wrapper around existing non-UNO implementations, instead of the other way 'round. Everything else would, so I think, need tremendous efforts. So, I prefer an incremental solution. Which is why I introduced the API here - to gather feedback on how future-proof the design is considered by others. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Ingrid, I must admit that I didn't look more deeply into the proposal yet, so just some comments on your comments: If an action in Calc leads to changes in Chart, and Calc triggers the changes actively, Chart doesn't necessarily need it's own actions in that case. When I perform Undo in Calc, it will also lead to necessary changes in Chart. So depending on the implementation, it can have side effects if some implementation thinks it is responsible for updating other data, which is then also been done buy any others implementations Undo. Whether this will have unwanted effects mainly depends on how much status information the Undo action is using. For example, when the user action leads to inserting some data object in an Array of implementation A , and leads to calling Insert(nPos, pData) in implementation B. A might only recognize nPos and a copy of Data. This is good enough for undo, and also following redo. But since that implementation probably doesn't keep a full data array as Undo data, the implementation will probably look similar. In the end, one Undo could lead to removing one data object in A, but 2 in B (one in it's own Undo, 1 in Calc's Undo). But maybe this doesn't matter, because every implementation knows anyway whether or not an other Implementation does it's own undo stuff? At least it's good to be aware of this. How does an implementation actually know whether or not to create new Undo actions? On manipulations via User/API it needs to, but if manipulations are currently done because of Undo, you mustn't create new Undo actions. I see in Frank's email determining whether an Undo/Redo operation is currently in progress, but couldn't find it in the API. Now looking into the attached API more deeply: It seems that the idea is that any extension could put it's own Undo actions in some others UndoManager. But what if the Extension terminates (no crash, but by intention), while I still work with the document? 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 and EditEngine simply keep Paragraph* when paragraphs are being deleted completely. Last but not least: When one common API for Undo should be used everywhere longterm, it needs to have support for Repeat (which then can lead to other funny situations, when some primary undo actions don't have repeat support, while the according hidden actions have...) Malte. Ingrid Halama wrote, On 10/15/10 20:23: Hi Frank, Frank Schönheit wrote: Hi, An UNO Undo API has been a revenant in this list (and other places) for multiple years now. Not sure if this year's attempt to exorcise (aka: implement) it will be more fruitful than previous ones, but let's see ... The following are some thoughts I have on the topic, and assuming there's not too many people crying that's complete nonsense, the plan is to embark on an implementation in a not too distant future. Comments welcome. Usage scenarios === A. An extension operates on a document, doing multiple changes in a row. All those changes should appear as a single entry in the Undo menu, and be undone in a single step. B. An extension listens for certain changes in a document, and reacts on them with doing more changes to other parts of the document. The latter change should not be visible in the Undo stack, and the Undo action generated by the former change should implicitly also undo the second change. (Imagine the extension as ensuring a consistent state of the document, with its own definition of consistent.) C. An extension listens for certain changes in a document, and reacts on them with doing more changes to other parts of the document. When both changes (the latter implicitly, the former explicitly) are undone, the extension should have a chance to find out that the change instigated by this Undo operation does not justify a new change to the document. D. An extension wants to add own Undo actions to the document's Undo stack, providing a callback for the Undo/Redo operations. Notes - Whenever the term extension is used in the above list, it could equally mean every piece of client code which has UNO access to the document only. I think the Chart does qualify for all those Usage scenarios. Changes in Calc can lead to changes within the Chart that should be offered as one UNDO action together. Further the changes made within the Chart should be visible in the global UNDO stack also. So the Chart would be an ideal candidate for a test implementation. I would like to join your efforts, if time fits. :-) There might be some extra complications to expect regarding the OLE inplace editing mode and the OLE swapping mechanism. That could become ugly, maybe ... .
Re: [api-dev] Attempt for an UNO Undo API
Hi Frank, Frank Schönheit wrote: Hi, An UNO Undo API has been a revenant in this list (and other places) for multiple years now. Not sure if this year's attempt to exorcise (aka: implement) it will be more fruitful than previous ones, but let's see ... The following are some thoughts I have on the topic, and assuming there's not too many people crying that's complete nonsense, the plan is to embark on an implementation in a not too distant future. Comments welcome. Usage scenarios === A. An extension operates on a document, doing multiple changes in a row. All those changes should appear as a single entry in the Undo menu, and be undone in a single step. B. An extension listens for certain changes in a document, and reacts on them with doing more changes to other parts of the document. The latter change should not be visible in the Undo stack, and the Undo action generated by the former change should implicitly also undo the second change. (Imagine the extension as ensuring a consistent state of the document, with its own definition of consistent.) C. An extension listens for certain changes in a document, and reacts on them with doing more changes to other parts of the document. When both changes (the latter implicitly, the former explicitly) are undone, the extension should have a chance to find out that the change instigated by this Undo operation does not justify a new change to the document. D. An extension wants to add own Undo actions to the document's Undo stack, providing a callback for the Undo/Redo operations. Notes - Whenever the term extension is used in the above list, it could equally mean every piece of client code which has UNO access to the document only. I think the Chart does qualify for all those Usage scenarios. Changes in Calc can lead to changes within the Chart that should be offered as one UNDO action together. Further the changes made within the Chart should be visible in the global UNDO stack also. So the Chart would be an ideal candidate for a test implementation. I would like to join your efforts, if time fits. :-) There might be some extra complications to expect regarding the OLE inplace editing mode and the OLE swapping mechanism. That could become ugly, maybe ... . [...] API proposal XUndoAction, XUndoManager, XUndoManagerSupplier - find the generated IDL for the proposed API at http://udk.openoffice.org/files/documents/23/4795/undo.zip That looks quite good so far! Maybe we can give up the ::com::sun::star::chart2::XUndo... things in favor of these new common interfaces :-). Regarding the hidden actions, what is exactly the order of Undo/Redo stack execution? Lets look at the following example: 1. The deletion of a column within calc is action1 and produces an undoaction1. 2. A change notification to the chart leads to action2 the deletion of a data series with values from the deleted column. An according hidden undoaction2 is created. If the user hits Undo now for a working scenario I think UndoAction1 is to be executed first and afterwards the hidden undoaction2. Can this be a general rule? Hidden actions are treated after their visible predecessor? If so, there needs to be some care when putting things onto the stack or from the stack. Kind regards, Ingrid - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Frank, has been a revenant in this list (and other places) for multiple years now. yes, for example: http://www.openoffice.org/issues/show_bug.cgi?id=33781 ;-) would be really great if an undo api could be implemented soon. but as you mentioned, maybe it would be better to keep it simple: - clearing the undo list is the most important feature, for example a document macro called from a form control can simply clear the list after changes have been made. btw: at the moment we use a loop of oDoc.unprotect or sometthing else to overwrite the undo list. - enterUndoContext - leaveUndoContext allows to undo multiple operations in one step, for example undo all changes which have been performed from a document macro. this would be a great help, cause at the moment a user don't know how many steps to go back. Regards Oliver -- GnuPG key 0xCFD04A45: 8822 057F 4956 46D3 352C 1A06 4E2C AB40 CFD0 4A45 signature.asc Description: OpenPGP digital signature
[api-dev] Attempt for an UNO Undo API
Hi, An UNO Undo API has been a revenant in this list (and other places) for multiple years now. Not sure if this year's attempt to exorcise (aka: implement) it will be more fruitful than previous ones, but let's see ... The following are some thoughts I have on the topic, and assuming there's not too many people crying that's complete nonsense, the plan is to embark on an implementation in a not too distant future. Comments welcome. Usage scenarios === A. An extension operates on a document, doing multiple changes in a row. All those changes should appear as a single entry in the Undo menu, and be undone in a single step. B. An extension listens for certain changes in a document, and reacts on them with doing more changes to other parts of the document. The latter change should not be visible in the Undo stack, and the Undo action generated by the former change should implicitly also undo the second change. (Imagine the extension as ensuring a consistent state of the document, with its own definition of consistent.) C. An extension listens for certain changes in a document, and reacts on them with doing more changes to other parts of the document. When both changes (the latter implicitly, the former explicitly) are undone, the extension should have a chance to find out that the change instigated by this Undo operation does not justify a new change to the document. D. An extension wants to add own Undo actions to the document's Undo stack, providing a callback for the Undo/Redo operations. Notes - Whenever the term extension is used in the above list, it could equally mean every piece of client code which has UNO access to the document only. API requirements - entering/leaving an Undo context - all single Undo actions generated within this context contribute to a single Undo action - adding own undo actions to the Undo stack - programmatic undo/redo of the top-most undo/redo action - programmatic clearing of the Undo stack - hiding Undo actions from the user - determining whether an Undo/Redo operation is currently in progress - Undo/Redo listeners Notes - There's intentionally no direct access to the Undo actions on the stack, as this would widely open the door for all kind of intentional or accidental manipulation bypasing the Undo manager - something very hard to keep under control. The last two items on the list are intended to address scenario C. However, it is questionable whether this scenario can legitimately be supported without major changes to the application's core. No matter whether an extension determines a running Undo action by calling some explicit isUndoActive, or by tracing some undoStarted/undoDone notifications - if changes to the document are notified asynchronously, then this mechanism immediately stops working. So, as document change notifications are *usually* implemented synchronously, the mechanism *usually* would work - but is not guaranteed to do all the time. Alternative approaches to address scenario C.: - Every document change notification must send with it a flag whether the change is triggered by an Undo/Redo action. This is quite illusionary, given the API and core changes it would involve - All document change notifications are *required* to be synchronously. - All document change notifications are required to be asynchronously, including the undoStarted/undoDone notifications. Also, all notifications referring to a given document must be guaranteed to arrive in-order at listeners. - Document changes triggered by Undo actions do not result in document change listeners being called. This would not be a good idea at all, since there might be listeners which are nonetheless interested in document changes - not to make depending changes to the document, but for other reasons. As a refinement, only those listeners should be notified which have those other motivations - but that's again something which would require extensive changes to the existing API and core implementations, as there currently is no way, not even a concept, to distinguish those kinds of listeners (and it might be questionable whether there really should). So, not a single of these approaches is really satisfying. Which might imply we should not address scenario C. at all, assuming that the consequences are bearable. API proposal XUndoAction, XUndoManager, XUndoManagerSupplier - find the generated IDL for the proposed API at http://udk.openoffice.org/files/documents/23/4795/undo.zip Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Frank, after a first reading it sounds interesting and of course very useful. I will take a closer look o the interfaces tomorrow if i can make it before i go on vacation. Juergen On 10/4/10 12:27 PM, Frank Schönheit wrote: Hi, An UNO Undo API has been a revenant in this list (and other places) for multiple years now. Not sure if this year's attempt to exorcise (aka: implement) it will be more fruitful than previous ones, but let's see ... The following are some thoughts I have on the topic, and assuming there's not too many people crying that's complete nonsense, the plan is to embark on an implementation in a not too distant future. Comments welcome. Usage scenarios === A. An extension operates on a document, doing multiple changes in a row. All those changes should appear as a single entry in the Undo menu, and be undone in a single step. B. An extension listens for certain changes in a document, and reacts on them with doing more changes to other parts of the document. The latter change should not be visible in the Undo stack, and the Undo action generated by the former change should implicitly also undo the second change. (Imagine the extension as ensuring a consistent state of the document, with its own definition of consistent.) C. An extension listens for certain changes in a document, and reacts on them with doing more changes to other parts of the document. When both changes (the latter implicitly, the former explicitly) are undone, the extension should have a chance to find out that the change instigated by this Undo operation does not justify a new change to the document. D. An extension wants to add own Undo actions to the document's Undo stack, providing a callback for the Undo/Redo operations. Notes - Whenever the term extension is used in the above list, it could equally mean every piece of client code which has UNO access to the document only. API requirements - entering/leaving an Undo context - all single Undo actions generated within this context contribute to a single Undo action - adding own undo actions to the Undo stack - programmatic undo/redo of the top-most undo/redo action - programmatic clearing of the Undo stack - hiding Undo actions from the user - determining whether an Undo/Redo operation is currently in progress - Undo/Redo listeners Notes - There's intentionally no direct access to the Undo actions on the stack, as this would widely open the door for all kind of intentional or accidental manipulation bypasing the Undo manager - something very hard to keep under control. The last two items on the list are intended to address scenario C. However, it is questionable whether this scenario can legitimately be supported without major changes to the application's core. No matter whether an extension determines a running Undo action by calling some explicit isUndoActive, or by tracing some undoStarted/undoDone notifications - if changes to the document are notified asynchronously, then this mechanism immediately stops working. So, as document change notifications are *usually* implemented synchronously, the mechanism *usually* would work - but is not guaranteed to do all the time. Alternative approaches to address scenario C.: - Every document change notification must send with it a flag whether the change is triggered by an Undo/Redo action. This is quite illusionary, given the API and core changes it would involve - All document change notifications are *required* to be synchronously. - All document change notifications are required to be asynchronously, including the undoStarted/undoDone notifications. Also, all notifications referring to a given document must be guaranteed to arrive in-order at listeners. - Document changes triggered by Undo actions do not result in document change listeners being called. This would not be a good idea at all, since there might be listeners which are nonetheless interested in document changes - not to make depending changes to the document, but for other reasons. As a refinement, only those listeners should be notified which have those other motivations - but that's again something which would require extensive changes to the existing API and core implementations, as there currently is no way, not even a concept, to distinguish those kinds of listeners (and it might be questionable whether there really should). So, not a single of these approaches is really satisfying. Which might imply we should not address scenario C. at all, assuming that the consequences are bearable. API proposal XUndoAction, XUndoManager, XUndoManagerSupplier - find the generated IDL for the proposed API at http://udk.openoffice.org/files/documents/23/4795/undo.zip Ciao Frank
