dont use SwClient/SwModify in unocore: Section

Change-Id: Ic594c5129664b309ce1b6ddd0c715a17df5a3265
Reviewed-on: https://gerrit.libreoffice.org/54091
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@libreoffice.org>

1 files changed, 14 insertions, 0 deletions

diff --git a/sw/inc/calbck.hxx b/sw/inc/calbck.hxx
index 9f809ea24dbd..595a3deab14d 100644
--- a/sw/inc/calbck.hxx
+++ b/sw/inc/calbck.hxx
@@ -21,6 +21,7 @@
 #define INCLUDED_SW_INC_CALBCK_HXX
 
 #include <svl/hint.hxx>
+#include <svl/broadcast.hxx>
 #include <svl/poolitem.hxx>
 #include "swdllapi.h"
 #include "ring.hxx"
@@ -71,6 +72,19 @@ namespace sw
         virtual ~ModifyChangedHint() override;
         const SwModify* m_pNew;
     };
+    // Observer pattern using svl implementation
+    // use this instead of SwClient/SwModify whereever possible
+    // In writer layout, this might not always be possible,
+    // but for listeners outside of it (e.g. unocore) this should be used.
+    // The only "magic" signal this class issues is a ModifyChangedHint
+    // proclaiming its death. It does NOT however provide a new SwModify for
+    // listeners to switch to like the old SwModify/SwClient did, as that leads
+    // to madness.
+    class SW_DLLPUBLIC BroadcasterMixin {
+        SvtBroadcaster m_aNotifier;
+        public:
+            SvtBroadcaster& GetNotifier() { return m_aNotifier; }
+    };
     /// refactoring out the some of the more sane SwClient functionality
     class SW_DLLPUBLIC WriterListener
     {