Hi John,

>     * The ability to hook a callback to the following events:
>           o Whenever something is added to the undo history (with
>             details of what the action was that was added, preferably by
>             supplying the action as an object) OR whenever an action is
>             performed which modifies the document (e.g. the Writer,
>             Calc, etc. document) - again, with details of what the
>             action was.
>           o Whenever the 'undo' function is called (with details of what
>             will be or was undone).
>           o Whenever the 'redo' function is called (with details of what
>             will be or was redone).

API support for Undo/Redo has been added recently, and will be available
in 3.4. There's also listener support for the Undo/Redo stack, however,
you will only be notified that a change actually happened, you will not
get all the fancy details of the change itself. The only concrete
information about the action is its description, i.e. the string
displayed at the UI. Since this is localized, and finally an
implementation detail, it won't help you here.

Besides that describing each change in detail in an Undo notification
event would be expensive, it would also be a *very* complex data
structure your listener would need to examine. If you're really
interested in each and every change in a document, you should probably
add dedicated (typed) listeners: I would assume (but am not sure at all)
that every single modification to a document is notified by special
listeners already.

>     * The ability to save a full copy of the open document (Writer
>       document, spreadsheet, etc.) to a given path (not the path of the
>       document - i.e. saving a copy).

OOo documents implement the XStorable interface:

http://api.openoffice.org/docs/common/ref/com/sun/star/frame/XStorable.html#storeToURL

>     * The ability to load a copy of a document into the existing window
>       without prompting the user (the previous copy would have been
>       saved, so I guess OO.org <http://OO.org> would not prompt for
>       this), OR closing the current window and opening a new one (this
>       second option is not preferred).

Frames (where documents are displayed) implement the XComponentLoader
interface:

http://api.openoffice.org/docs/common/ref/com/sun/star/frame/XComponentLoader.html#loadComponentFromURL

> What I did find that seems promising are the following links:
> 
>     * 
> http://openoffice.2283327.n4.nabble.com/api-dev-Attempt-for-an-UNO-Undo-API-td2954095.html

that's a discussion preceding the actual implementation of an Undo API.

>     * 
> http://api.openoffice.org/docs/common/ref/com/sun/star/chart2/XUndoManager.html

That's API-Undo support for chart only. In 3.4, it will be removed, and
superseded by the new-by-then com.sun.star.document.XUndoManager interface.

>     * 
> http://openoffice.2283327.n4.nabble.com/api-dev-info-CWS-undoapi-new-UNDO-API-td3207049.html

That's the announcement that the Undo API has finally been implemented.

> The third link also looks very promising, but I cannot find the
> referenced 'css.document.XUndoManager' in any of the API documentation.

It is not online, yet, since the online version of the API documentation
always follows the releases, and 3.4 is not released, yet.

> Nor can I find even 'css' or 'cws' in the API index, so this makes me
> think that maybe the undo/redo API is defined but not created yet -
> anyone know this for sure?

"css" is a shortcut for "com.sun.star", and "CWS" refers to a so-called
child workspace, an entity where feature implementations happen before
added to the main development trunk.

Ciao
Frank
-- 
-----------------------------------------------------------------
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

Reply via email to