Proposals for 3.0.0 API changes
will at willthompson.co.uk
Mon Dec 31 10:07:23 EST 2007
On Sun, Dec 30, 2007 at 10:02:23PM -0500, John Bailey wrote:
> In the msn-pecan thread, Gary and I agreed that an API freeze after 2.4.0 in
> order to implement struct member hiding would be a good way to help us on the
> road to having libpurple's objects implemented purely as GObjects. Ka-Hing
> voiced support for the proposal.
+1 (assuming that, if people turn out not to have time to work on hiding
once we have frozen, thawing until they do will not be considered
One thing I'd like to happen for libpurple 3 is to make the request and
notification APIs more friendly for telepathy-haze and similar UIs which
can't just throw up a dialog box with arbitrary text and buttons.
Ideally, requests and notifications would become special cases of
signals. Consider the "%s requires plaintext authentication over an
unencrypted connection. Allow this and continue authentication?"
requests in jabber/auth.c. (Aside from the fact that this should
arguably be an account option,) this should emit a signal like
"allow-insecure-authentication" (using _emit_1 to prevent the callbacks
being called twice, with hilarious results) and only fall back to "just
throw up a dialog" if no handlers exist. This "raise a signal but fall
back to requests" technique occurs in a few places already. I'm not
sure what the API for this signal-plus-some-extra-text-if-you-want-it
functionality should look like; I just throught I'd throw the idea out
there alongside John's ideas for libpurple 3.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel