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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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:
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
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
30 matches
Mail list logo
