GObjectification of UiOps
sardemff7+pidgin at sardemff7.net
Thu Jun 27 03:54:10 EDT 2013
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
>> 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
>> (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).
Quentin “Sardem FF7” Glidic
More information about the Devel