GObjectification of UiOps

[Gary Kramlich]

Can you point me to the documentation that says GInterface is slow?  I have
never seen or heard this before and quite frankly, it smells like troll
bait.

As for the compile time checks, you don't get with any signals in Gtk but
that doesn't seem to be a problem for them so why is it a problem for us?
 If we really want to use compile time checks, why don't we just hae
"UiOps" instead of signals in general? </sarcasm>.

The real problem here is that while the compile time checks are nice for
plugin authors, it creates twice as much infrastructure in libpurple that
*NEEDS* to be maintained.

The interfaces and UiOps both needs the UI to register them in the core;
 that means more infrastructure code there too, whereas the signals are
just the signals;  The ui implements them or it doesn't because is there
really anything that a ui absolutely must implement (asside from password
prompts and error messages?).

As for plugins changing behavior, that's why you allow plugins in the first
place, to change/alter/hopefully improve the user's experience.


On Thu, Jun 27, 2013 at 2:54 AM, Quentin Glidic <
sardemff7+pidgin at sardemff7.net> wrote:

> 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
>
>
> ______________________________**_________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/**mailman/listinfo/devel<http://pidgin.im/cgi-bin/mailman/listinfo/devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130705/6d0d7cbf/attachment.html>