GObjectification of UiOps

[Ankit Vani]

Hi

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:

(1) Interfaces
    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
    interface.
    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.

(2) Signals
    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.

(3) Current
    Keep the mechanism as it is currently, using UiOps structures, without
    any GObjectification.

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 :)

Ankit Vani