[QOF-devel] Outline of new qofevent support

Neil Williams linux at codehelp.co.uk
Sat Feb 25 15:45:05 EST 2006


On Tuesday 21 February 2006 5:07 am, Derek Atkins wrote:
> Actually, I just thought of something..  I'd like to have events that
> have both subject AND object..  Right now we just have a Subject +
> Verb (QofEntity + QofEventId).  I'd like to add an object, too, so we
> could have an event Subject + Verb + Object (QofEntity + QofEventId +
> gpointer).

OK. QOF can do that.

> The generator and consumer of the QofEventId need to 
> agree on what the object of the event is.

Absolutely. This would almost certainly mean a different QofEventId for each 
type of object used and expected. That can't be resolved by QOF, it needs to 
be stated in the docs and left to the user to ensure it actually happens that 
way.

Do you actually want a gpointer or would a QofEntity be a better choice?

> Could we add a second set of APIs that parallel the existing set
> that let me pass an extra object back to the event handler?

... object, rather than argument, yes?

> I'd propose:
>
>   typedef void (*QofEventHandlerWithArg)(QofEntity*, QofEventId, gpointer);

WithArg infers non-objects being passed (like a GHashTable or GList, an 
arbitrary struct / iterator, some arbitrary const gchar* or other weird bits 
of memory) - was this your intention or would this be a better, clearer, name 
base?

QofEventHandlerWithObject

Your use case certainly centres on an item that is more of an Object than some 
arbitrary argument.

I prefer the idea of restricting it to objects - or more precisely, a 
QofEntity.

Maybe even use QofEventHandlerWithEntity

>   void qof_event_add_handler_with_arg(QofEventHandlerWithArg);

qof_event_register_handler_with_object
or qof_event_register_handler_with_entity
and ditto below:

>   void qof_event_del_handler_with_arg(QofEventHandlerWithArg);

qof_event_unregister_handler_with_object

>   void qof_event_with_arg(QofEntity*, QofEventId, gpointer);

qof_event_gen_with_object ?

> I admit this would be a LOT easier if QOF were based on gobject and we
> used g_signal...  Mea Culpa.

Issue postponed until closer to libqof2 which in turn is certainly after G2.

> What do you think?

Do you need this for QOF 0.6.2 (which otherwise could be released tomorrow) or 
0.6.3 which is a likely release in the first week of April (coinciding 
possibly with 1.9.3)? (i.e. as this is something you've just recently thought 
up, is the idea due to an immediate need, educated foresight or wishlist?)

(I'd like QOF to have a 5-6 week release cycle during the life of gnucash 
1.9.x and probably beyond during the life of libqof1. There are a lot of 
issues to resolve in libqof1 and I'm tackling them one at a time. I want each 
release to only have one new format added with it's old format being 
deprecated.)

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060225/6506f449/attachment.bin


More information about the gnucash-devel mailing list