[api-dev] Dialog control like JPanel in UNO awt
Hi, I am searching for a JPanel in java like performing dialog control in Openoffice to contain some other controls inside. And this control model should be able to make visible and invisible such that the controls inside it also does the same action. I looked into UnoControlGroupBoxModel, but it seem to be only a visual component to group controls. Is the above task possible in UNO awt? If it is possible what control I should use for that? Thank you -- Best regards, Pivithuru Wijegunawardana University of Moratuwa Sri Lanka
[api-dev] DocumentLoader memory leaking on cleanup
We are using DocumentLoader to manage the opening of PowerPoint files, and have recently discovered what appears to be a memory leak. As a quick background, these are self-advancing presentations, created using Microsoft by the end-user, who then uses our product (CentOS based) to display the files. When the cleanup routine is called, it appears to do its thing, but a bit of time later, the machine is almost frozen from all of its memory being used up... and after taking a look at the processes on the machine, we tracked it back to this. Below is from our log file... It looks like it reaches the end of the slideshow (event OnEndPresentation) and fires the Cleanup routine... but is it working past that point? Appears to not be. Are there any known issues with this sort of thing? Anyone else seeing this? Thanks! Chris 1288025660 : pid: 6935 - Acquiring lock... 1288025660 : pid: 6935 - Lock acquired! 1288025660 : pid: 6935 - Connected successfully to the office 1288025660 : pid: 6935 - XComponentloader successfully instantiated 1288025660 : pid: 6935 - argv[1]=/home/silentm/public_html/multimedia/951918099.Clarian.ppt 1288025660 : pid: 6935 - Document: file:///home/silentm/public_html/multimedia/951918099.Clarian.ppt 1288025661 : pid: 6935 - Starting Presentation... 1288025661 : pid: 6935 - Presentation Started! 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Releasing lock... 1288025661 : pid: 6935 - Lock released! 1288025661 : pid: 6935 - Wait for end! 1288025661 : pid: 6935 - Event : OnUnfocus received 1288025661 : pid: 6935 - Event : OnStartPresentation received 1288025661 : pid: 6935 - Event : OnFocus received 1288025661 : pid: 6935 - Event : OnLoad received 1288025662 : pid: 6935 - Event : OnEndPresentation received 1288025662 : pid: 6935 - Ending! 1288025662 : pid: 6935 - Event : OnViewClosed received 1288025662 : pid: 6935 - Event : OnUnfocus received 1288025664 : pid: 6935 - Cleanup 1288025664 : pid: 6935 - Cleanup - close - dispose - 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
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
Hi Stephan, >> 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. > 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". Thanks & 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
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
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
>> 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
> 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
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
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
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
