Proposal for an extended callbacks field
pidgin at monitzer.com
Thu Jul 26 05:44:10 EDT 2007
On Jul 26, 2007, at 07:49, Etan Reisner wrote:
> On Thu, Jul 26, 2007 at 03:44:56AM +0200, Andreas Monitzer wrote:
> It had no chance of becoming anything but annoying since you didn't
> it up when you ran into it except that very first time. As I've said
> before, discussing things is almost always better than not discussing
> them. Especially when you think you weren't understood clearly the
> time or that the original decision was the wrong one.
Yes, I agree. However, even when I discuss the things with you and
you agree that this callback should be in the prpl struct (just like
the unregister field), what happens when you encounter this for the
>> The functions that are already implemented and have to be used from
>> the application but are not in the prpl struct right now are:
> As I said in my previous email this isn't a prpl_info member and
> does not
> need to be
As I already said in the email you replied to, I didn't imply that
this belongs to the prpl struct, just that a better solution should
be found when you want to have a clean API.
> having the prpl call known functions in the core which then
> handle calling ui_ops and/or emitting signals is a perfectly good
> way to
> handle this and lets any ui or plugin handle it however they want to.
Yes, but the application still has to supply the callback in some way.
> Account Action
You'd have to prompt for the gateway JID, which is a very bad UI (how
should the user know what to enter there?).
> Account Action and blist-node-extended-menu action for most things,
> if we
> need a service discovery browser or an enter-a-jid-to-disco action
> can come later and likely be done with the existing mechanisms.
Yes, as I already said, those are already done, but not all what's
needed, since that limits you to nodes on your contact list and the
server you're connected to.
> Account Action and/or blist-node-extended-menu action.
Same as above.
> User search already exists for XMPP or do you mean something other
> the JUD based searching?
This action prompts the user for the JID of the search service, which
has the same issue as the gateway registration you're proposing: How
the heck should the user know what to enter there?
Right now you're prefilling the field with the search service of the
local server, which is a nice pick, but not the only one possible by
> The UI for this is an Account Action, I seem to
> recall you stating at one point that Adium didn't implement the
> Actions, if that is in fact the case then you should check out
> pidgin and
> see what they are and how they work.
I already fixed that in Adium. The reason they weren't implemented
was the lack of support for the fields request API, which I fixed, too.
>> Note that the first one should probably be replaced by a registration
>> callback in the _PurpleAccountUiOps struct (so you don't have to
>> define a callback in addition to defining this struct). Sean
>> suggested the current solution, since he didn't want to use up one of
>> those four reserved spots on the struct.
> Given the above suggestions of using Account Actions (is there a
> that doesn't work), and my suggested purple_account_registered
> none of the above requires any prpl_info changes. Can you see why
> we don't
> immediately jump on the idea that everything needs to go into the
> prpl_info struct? Is there some reason my suggestions about don't
I think back then I proposed adding the registration callback to
struct _PurpleAccountUiOps, which still looks like an obvious choice
> Yes, this certainly sounds like the status api could use fixing up. At
> first blush it would seem that adding a GList of changed status
> keys would
> do what was necessary for this circumstance, it would simplify the
> do-I-care check immensely.
Yes, agreed. That solution would probably be easy enough. The problem
is that this is certainly a 3.0 change, so I guess it's too early for
More information about the Devel