<div dir="ltr">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.<div><br></div><div>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>.</div>
<div><br></div><div>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.</div><div><br></div><div>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?).</div>
<div><br></div><div>As for plugins changing behavior, that's why you allow plugins in the first place, to change/alter/hopefully improve the user's experience.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Jun 27, 2013 at 2:54 AM, Quentin Glidic <span dir="ltr"><<a href="mailto:sardemff7+pidgin@sardemff7.net" target="_blank">sardemff7+pidgin@sardemff7.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 27/06/2013 09:44, Mark Doliner wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Sun, Jun 16, 2013 at 2:16 PM, Ankit Vani <<a href="mailto:a@nevitus.org" target="_blank">a@nevitus.org</a>> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I need some help regarding the possibility of GObjectifying this mechanism. Some<br>
possible directions are:<br>
<br>
(1) Interfaces<br></div><div class="im">
   Since conceptually, UiOps are similar to interfaces, turning them into an<br>
   interface seems like a good choice. The class of an entity would hold its UI<br>
   interface.<br>
   However, an issue faced here is that there isn't any obvious way to request<br>
   a UI interface object from the UI.<br>
   Also, when all objects of an entity are destroyed, the UI interface gets<br>
   destroyed along with the class, and libpurple cannot ask the UI to provide a<br>
   UI interface object as mentioned.<br>
</div></blockquote></blockquote>
<br>
I think we can here use the same mechanism that we already have (purple_core_set_ui_ops) like purple_core_set_ui_object(<u></u>PurpleUiOpsInterface *).<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(2) Signals<br>
(3) Current<br>
<br>
Due to the issues in (1) and (2), I'm inclined to keep UiOps as they are for<br>
now. If however, someone has a better suggestion to implement this mechanism,<br>
please let me know :)<br>
</blockquote>
<br>
Yeah, I think (3) is a good choice. I'm a little uneasy about (2) due<br>
to the lack of compile time checking. (1) seems reasonable, but I<br>
wonder if it's really an improvement over structs.<br>
</blockquote>
<br></div>
As a libpurple user, (3) is “good enough”. (2) is definitely bad regarding build time checks.<br>
<br>
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.<br>
<br>
*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).<br>
<br>
Cheers,<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Quentin “Sardem FF7” Glidic</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@pidgin.im" target="_blank">Devel@pidgin.im</a><br>
<a href="http://pidgin.im/cgi-bin/mailman/listinfo/devel" target="_blank">http://pidgin.im/cgi-bin/<u></u>mailman/listinfo/devel</a></div></div></blockquote></div><br></div>