FS#12721 - Allow front-end to supply context for transaction callbacks
Attached to Project:
Pacman
Opened by Xilon (Xilon) - Friday, 09 January 2009, 16:01 GMT
Last edited by morganamilo (morganamilo) - Tuesday, 05 October 2021, 20:06 GMT
Opened by Xilon (Xilon) - Friday, 09 January 2009, 16:01 GMT
Last edited by morganamilo (morganamilo) - Tuesday, 05 October 2021, 20:06 GMT
|
Details
It is possible that front-ends my not have enough
information to do what they want in the various transaction
callbacks. I suggest adding a new element to the pmtrans_t
structure - a void *context. The alpm_trans_init() functions
would of course have a new parameter to pass the data in.
This context element could be anything, but would likely be
some sort of structure with additional information. In my
case, since I'm using an OOP language to wrap around
libalpm, I'd pass in an object, allowing me to interact with
it in the callbacks.
Since there are three callbacks, it might be better to be able to provide three different contexts. In such a case it might be neater to refactor the callback registration from the alpm_trans_init() function and have alpm_trans_register_event_callback(...), alpm_trans_register_conv_callback(...), alpm_trans_register_progress_callback(...). This would be beneficial even if the contexts are not implemented, as these parameters are optional (NULL can be used) and the interface is very long, even though this would be more verbose. Maybe the whole transaction overhaul for universal transactions (FS#9694) would be a good opportunity. |
This task depends upon
Closed by morganamilo (morganamilo)
Tuesday, 05 October 2021, 20:06 GMT
Reason for closing: Implemented
Additional comments about closing: e7fa35baa22bf6710a904815456d3ff679005fc7
Tuesday, 05 October 2021, 20:06 GMT
Reason for closing: Implemented
Additional comments about closing: e7fa35baa22bf6710a904815456d3ff679005fc7