GObjectification of UiOps

[Quentin Glidic]

On 27/06/2013 09:44, Mark Doliner wrote:
> On Sun, Jun 16, 2013 at 2:16 PM, Ankit Vani <a at nevitus.org> wrote:
>> 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.

I think we can here use the same mechanism that we already have 
(purple_core_set_ui_ops) like 
purple_core_set_ui_object(PurpleUiOpsInterface *).


>> (2) Signals
>> (3) Current
>>
>> 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 :)
>
> Yeah, I think (3) is a good choice. I'm a little uneasy about (2) due
> to the lack of compile time checking. (1) seems reasonable, but I
> wonder if it's really an improvement over structs.

As a libpurple user, (3) is “good enough”. (2) is definitely bad 
regarding build time checks.

I think the best way is to go with (3) for now, and add later (1) as a 
new API, wrapping the old one to create a dumb GObject.

*But* (1) has one major problem for me: performance. GObject interfaces 
are known to be a bit slow, so we must carefully check if there are 
worth it for core UI operations, that might happens often (e.g. I/O stuff).

Cheers,

-- 

Quentin “Sardem FF7” Glidic