Commit: New Types of plugins Fix Hyperlinks

CVS: ----------------------------------------------------------------------
CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: src/af/xap/xp/xap_App.cpp src/af/xap/xp/xap_App.h
CVS: src/af/xap/xp/xav_View.cpp src/text/fmt/xp/fv_View_cmd.cpp
CVS: src/wp/ap/xp/ap_Menu_Functions.cpp
CVS: src/wp/ap/xp/ap_Toolbar_Functions.cpp
CVS: ----------------------------------------------------------------------
New plugin notification system.
Fix insert hyperlink.

Hi everyone,
            Julian Stachell got me thinking about how we could support the
dashbaord clever notification system. We'd both like to do it with a plugin
but before now we had no generic means of getting abiword to tell plugins
(and other listeners of interesting events.

So I wrote 3 new methods in XAP_App to do this and hooked them up to
our view listeners.

These are a powerful framework for doing notifications but we have not
exploited them for plugins.

To unerstand the view listeners look at the files:

 abi/src/af/xap/xp/xav_Listner.h
 abi/src/af/xap/xap/xav_View.(h,cpp)

 The idea is this. New listeners are built from the xav_Listener base
 class.

They then register themselves as opaque listeners in a vector held by
AV_View (via the addListener method).

 Upon an interesting event in abiword (such as typing, clicking in the
 document, changing views, new views getting focus)

The method:

 The AV_View::notifyListeners(const AV_ChangeMask hint)

Is called. The AV_ChangeMask hint is just a bit array that encodes what
 kind of thing happened.

This method just loops through all pointers in the vectors and calls the
notify method in thr AV_Listener class and passes the hint down to them.

via

notify(AV_View * pView, hint)

OK now these listners are attached to each view and do things like
greyout menu items and toolbar icons for features at are illegal in a
particular context of the document or show if the current span is bolded
etc etc.

They are common to each view of the document.

We want something more general. We want every change to every view on
every document to be broadcast to plugins or other listeners like our
current timer based listeners on non-modal dialogs.

Now AbiWord has a singleton class XAP_App.

abi/src/af/xap/xp/xap_App.(h,cpp)

Every piece of code in the AbiWord address space has access to this
class by calling the code:

XAP_App * pApp = XAP_App::getApp()

I have placed a new set of methods in XAP_App that plugins can
register with.

It will has the same API as the AV_View listeners.

XAP_App::addListener(AV_Listener * pListener, AV_ListenerId *pListenerId)
bool XAP_App::removeListener(AV_ListenerId listenerId)
XAP_app::notifyListeners(AV_View * pView, const AV_ChangeMask hint)

So I've added the command

getApp()->notifyListeners(this,hint);

Within the AV_View::notifyListeners(hint) method.

So a plugin has to then construct itself, register itself to XAP_App
via the XAP_App::addListener(pListener, *pId) method.

upon deactivation it must call XAP_App::removeListener(...)

>> Then whenever the "notify" method is called

YourPlugin::notify(AV_View * pView, hint)

your listener can decide what to do based on the hint and pointer to the
current view.

This has now been coded and is available for testing :-)

--------------------------------------------------------------------

On an entirely different note insert hyperlink has been fixed. My fault,
sorry.

Cheers

Martin
Received on Fri Oct 1 17:02:23 2004