merge IUndoManager into SfxUndoManager

SfxUndoManager is the only implementation of the IUnderManager
"interface", and it lives in the same header.
Plus this way we can get rid of some covariant parameters,
which will make using std::unique_ptr easier.

Change-Id: I6661b9876b18da830bead78794d237886cd3c5c9
Reviewed-on: https://gerrit.libreoffice.org/57317
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

1 files changed, 10 insertions, 13 deletions

diff --git a/include/framework/undomanagerhelper.hxx b/include/framework/undomanagerhelper.hxx
index 09ac28b01fd2..261936a862e9 100644
--- a/include/framework/undomanagerhelper.hxx
+++ b/include/framework/undomanagerhelper.hxx
@@ -28,10 +28,7 @@
 
 #include <memory>
 
-namespace svl
-{
-    class IUndoManager;
-}
+class SfxUndoManager;
 
 
 namespace framework
@@ -63,15 +60,15 @@ namespace framework
     class SAL_NO_VTABLE IUndoManagerImplementation
     {
     public:
-        /** returns the IUndoManager interface to the actual Undo stack
+        /** returns the SfxUndoManager interface to the actual Undo stack
 
             @throws css::lang::DisposedException
-                when the instance is already disposed, and no IUndoManager can be provided
+                when the instance is already disposed, and no SfxUndoManager can be provided
 
             @throws css::lang::NotInitializedException
-                when the instance is not initialized, yet, and no IUndoManager can be provided
+                when the instance is not initialized, yet, and no SfxUndoManager can be provided
         */
-        virtual ::svl::IUndoManager&    getImplUndoManager() = 0;
+        virtual SfxUndoManager&        getImplUndoManager() = 0;
 
         /** provides access to an UNO interface for the XUndoManager implementation. Used when throwing exceptions.
         */
@@ -95,15 +92,15 @@ namespace framework
         The following locking strategy is used for this mutex:
         <ul><li>Any notifications to the registered XUndoManagerListeners are after the guard has been cleared. i.e.
                 without the mutex being locked.</p>
-            <li>Any calls into the <code>IUndoManager</code> implementation is made without the mutex being locked.
-                Note that this implies that the <code>IUndoManager</code> implementation must be thread-safe in itself
+            <li>Any calls into the <code>SfxUndoManager</code> implementation is made without the mutex being locked.
+                Note that this implies that the <code>SfxUndoManager</code> implementation must be thread-safe in itself
                 (which is true for the default implementation, SfxUndoManager).</li>
-            <li>An exception to the previous item are the <member>IUndoManager::Undo</member> and
-                <member>IUndoManager::Redo</member> methods: They're called with the given external mutex being
+            <li>An exception to the previous item are the <member>SfxUndoManager::Undo</member> and
+                <member>SfxUndoManager::Redo</member> methods: They're called with the given external mutex being
                 locked.</li>
         </ul>
 
-        The reason for the exception for IUndoManager::Undo and IUndoManager::Redo is that those are expected to
+        The reason for the exception for SfxUndoManager::Undo and SfxUndoManager::Redo is that those are expected to
         modify the actual document which the UndoManager works for. And as long as our documents are not thread-safe,
         and as long as we do not re-fit <strong>all</strong> existing SfxUndoImplementations to <em>not</em> expect
         the dreaded SolarMutex being locked when they're called, the above behavior is a compromise between "how it should