Dialog transience relationships

Mark Doliner mark at kingant.net
Tue Aug 14 13:01:20 EDT 2007


On Tue, 14 Aug 2007 09:52:48 +0300, Gabriel Schulhof wrote
> On Tue, 2007-08-14 at 00:31 -0500, Mark Doliner wrote:
> > On Wed, 08 Aug 2007 23:35:16 +0300, Gabriel Schulhof wrote
> > > 1. Add a parameter of the form void *ui_data to all the
> > > {pidgin,purple}_request_* functions just before void *user_data. This
> > > parameter can be NULL, but, if set, it is a GtkWindow * of the parent.
> [...]
> > I also like the other suggestion about using a hint to specify if the dialog
> > should be associated with the buddy list, or the accounts window, or a
> > conversation window.  It seems like that would cover most cases.
> 
> I figured that might be better. Currently, I'm using const char *ui_hint
> instead of void *ui_data, and I'm working with the following list:
> 
> "account"
> "blist"
> "buddy"
> "register-account"
> "xfer"
> "chat"

"chat" should probably be "conversation."  In Pidgin and libpurple we generall
use the term "IM" to refer to person to person messages, "chat" to refer to
group chat rooms, and "conversation" to refer to both.

> I figure, I could list all the toplevels and, based on these hints /and/
> things like the PurpleConversation parameter to these functions, 
> which also may be there, decide on a toplevel to pick as the "window 
> of transience".

Good idea.

> The way I identify all the locations where purple_request_* calls 
> need changing is to have changed request.h and then try to compile,
>  and watch for warnings (in the case of purple_request_action(), 
> which is a (...) function) and errors.

"grep" might be more effective.  If you just change the function declaration
then you might miss calls to purple_request_action() that happen in protocols
that don't get compiled on your system because you don't have a certain
library.  Like the silc protocol, or sametime or bonjour.

-Mark




More information about the Devel mailing list