Re: CVS: commit msevior abi/src/af/xap/xp xap_Dialog.h xap_DialogFactory.cpp xap_DialogFactory.h

From: <msevior_at_physics.unimelb.edu.au>
Date: Mon Aug 28 2006 - 04:34:00 CEST

>
> Update of /cvsroot/abi/src/af/xap/xp
> In directory abiword.snt.utwente.nl:/tmp/cvs-serv3019/src/af/xap/xp
>
> Modified Files:
> xap_Dialog.h xap_DialogFactory.cpp xap_DialogFactory.h
> Log Message:
>
> Allow dialogs to dynamically added to the dialog factory system. Very
> useful for dialog from plugins.
>

OK there is a lot to describe here. This is a new framework that allows
dialogs to be added dynamically to the dialog factory system. This allows
plugins to add their own dialogs and to use the standard abiword
techniques for splitting dialogs into xp and platfrom specific classes,
just like dialogs in the main tree.

Their are two extra features in main tree now. The first is this typedef.

typedef XAP_Dialog *(*pt2Constructor)(XAP_DialogFactory * pFactory,
XAP_Dialog_Id id );

So a pt2Constructor is a pointer to the static_constructor method of an
abiword dialog.

The second is this new method in XAP_DialogFactory:

 XAP_Dialog_Id XAP_DialogFactory::registerDialog(XAP_Dialog
*(*pStaticConstructor)(XAP_DialogFactory *, XAP_Dialog_Id
id),XAP_Dialog_Type iDialogType);

This method registers the static_constructor of your new dialog in the
collection of dialogs held by the factory. You also specify the dialog
type, in the registration process.

It returns the XAP_Dialog_Id number of the newly registered dialog. You
must record this number and use it to request your dialog later.

IMPORTANT!! For reasons tha aren't clear to me at this point, the AbiWord
founders allowed DialogFactories to be generated on every new frame as
well as App-wide. This means that when you register and request your
dialog, do from the app-wide dialog factory. ie Use

XAP_DialogFactory * pFactory = XAP_App::getApp()->getDialogFactory();

To get the factory to register and request your dialogs.

Finally, try as I could, I could not think of a way to get the platform
specific static_constructor method called from pure xp code. For the
AbiCollab dialogs I decided to go with #ifdefs to pick out unix/windows
static_constructors. Like this:

bool AbiCollabFactoryContainer::registerDialogs(void)
{
        XAP_DialogFactory * pFactory = static_cast<XAP_DialogFactory
*>(XAP_App::getApp()->getDialogFactory());
        pt2Constructor pConstructor = NULL;

#ifdef WIN32
        pConstructor = &AP_Win32Dialog_Collaboration::static_constructor;
#else
        pConstructor = &AP_UnixDialog_Collaboration::static_constructor;
#endif
        m_iDialogCollab_Id =
pFactory->registerDialog(pConstructor,XAP_DLGT_NON_PERSISTENT);

#ifdef WIN32
        pConstructor = &AP_Win32Dialog_CollaborationService::static_constructor;
#else
        pConstructor = &AP_UnixDialog_CollaborationService::static_constructor;
#endif
        m_iDialogCollabService_Id =
pFactory->registerDialog(pConstructor,XAP_DLGT_NON_PERSISTENT);

#ifdef WIN32
        pConstructor =
&AP_Win32Dialog_CollaborationService_Documents::static_constructor;
#else
        pConstructor =
&AP_UnixDialog_CollaborationService_Documents::static_constructor;
#endif
        m_iDialogCollabServiceDocs_Id =
pFactory->registerDialog(pConstructor,XAP_DLGT_MODELESS);
}

If someone can think of an elegant way to avoid this please implement it
or let me know.

OK that's it. We can now extend the dialog factory system using plugins.

Cheers

Martin
Received on Mon Aug 28 04:34:37 2006

This archive was generated by hypermail 2.1.8 : Mon Aug 28 2006 - 04:34:38 CEST