I promised a design discussion of why GObject signals are not a good solution for event delivery.
In the new model, the plugin controller allocates and deallocates the plugin private context and the per-plugin-instance per-window contexts (e.g. struct Task in the existing code). In order to do this it needs to sequence when the plugin is invoked to fill in and deallocate its private context, and present the private context in a way that both the plugin controller and the plugin can have access to their parts, which is critical to having the plugin API work properly. This is easy to do when we have exact knowledge of who has subscribed to receive the events. There is also the issue of synchronizing the menu reload. There is a well known technique that is used in database systems and file systems to do this. But again, this requires knowledge of who has subscribed to the event and might be holding pointers to the structure. Again, when it is the plugin controller that is delivering the event it is easy to sequence introducing the new data structure and deallocating the old copy. It is simpler since we do not have to handle general argument marshalling. We know exactly what callbacks will be invoked with what parameters. Finally, it is not that much code. The entire system is 300 lines, of which 50 handles the menu reload. ------------------------------------------------------------------------------ _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
