GObjectification of UiOps
a at nevitus.org
Sun Jun 16 17:16:33 EDT 2013
Currently, various UiOps structures (e.g. PurpleAccountUiOps) are used to notify
the UI of events, so that it can reflect the events to the user. This sturcture
defines function pointers to callbacks implemented in the UI.
I need some help regarding the possibility of GObjectifying this mechanism. Some
possible directions are:
Since conceptually, UiOps are similar to interfaces, turning them into an
interface seems like a good choice. The class of an entity would hold its UI
However, an issue faced here is that there isn't any obvious way to request
a UI interface object from the UI.
Also, when all objects of an entity are destroyed, the UI interface gets
destroyed along with the class, and libpurple cannot ask the UI to provide a
UI interface object as mentioned.
Instead of function pointers, signals can be used. This would eliminate
having two kinds of event mechanisms in libpurple - UiOps and signals. It
would provide one uniform interface for developers.
However, it sacrifices compile-time checks, making changing the API
difficult and error-prone without proper unit testing. It is also hard to
indicate the features that a UI must implement from those that are optional.
It may also be possible to stop signals meant for the UI by plugins - which
would be a bad thing.
Keep the mechanism as it is currently, using UiOps structures, without
Due to the issues in (1) and (2), I'm inclined to keep UiOps as they are for
now. If however, someone has a better suggestion to implement this mechanism,
please let me know :)
More information about the Devel