[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