Proposal for an extended callbacks field
pidgin at monitzer.com
Thu Jul 26 16:02:53 EDT 2007
On Jul 26, 2007, at 16:11, Nathan Walp wrote:
> Perhaps you can clarify for me what you would do differently from a
> UI perspective? For flexibility, you need to be able to enter any
> JID under the sun. For usefulness to the average user, you need to
> provide a list of JIDs that may be appropriate. What would your UI
> do. I ask this about register_gateway, as well as user_search.
I implemented a discovery browser using the raw API. This also seems
the cause of my prpl struct-related issues, since I only need those
for the discovery browser.
Generally, I considered implementing the discovery browser into the
xmpp plugin. However, I concluded that this is not a useful idea, due
to three reasons:
* When I started the project, I was told that pidgin will never
support a discovery browser, due to the non-elegance of the UI for
it. This policy seems to have changed about 2h ago, according to Etan.
* The request API is inadequate for this, since such a browser is not
a form but a dynamic user interface with a hierarchical list of items
that have to be dynamically and asynchronously changed, can contain
tooltips, context menus, added/removed and executed. This would mean
that I'd have to create a wholly new UI API, which is much more
complicated than any that's already there, and it'd be XMPP-specific
anyways (and thus would probably not be accepted).
* Sean told me to not bother with implementing stuff into libpurple
that requires a tight coupling with the user interface. I can't think
of anything with a tighter coupling than this feature.
> If you have good ideas about this, I'd love to hear them, as the
> current Pidgin interface is lacking at best.
All the stuff I implemented (except for user tune) was written in a
way that it's useful for pidgin, too, even when the full potential
cannot be achieved without a service discovery browser.
> On a separate note, more in response to this thread in general:
> 1. It seems you've been emailing Sean and maybe Etan outside of
> this list, which is fine for quick questions. However, as far as
> design descisions go, I'd much rather you ask them on-list, so I
> can review the discussion and resulting design, if nothing else.
> I've been in the dark about what you've been up to for months
I'm sorry for that. Those conversations happened on IRC on freenode
mostly, esp the ones with Sean. The problem is that a question like
"how do I do X in libpurple" usually results in a long discussion
about how to design the feature, both on this list and on IRC. This
is often the cause that the discussions happen on the wrong medium.
> 2. The stated goals of the Summer of Code (unless they've changed
> drastically since I last was a mentor) include introducing the
> student to the open source community, and educating them about the
> open source way of doing things. I hope that you have looked on
> this summer as an excellent opportunity to do just that.
Yes, I do.
> You are in a rather special position relative to your peers, in
> that you get to work with 2 open source projects simultaneously,
Two drastically different ones at that...
More information about the Devel