Dialog transience relationships

Gabriel Schulhof nix at go-nix.ca
Wed Aug 8 16:35:16 EDT 2007


I need to add proper transience relationships to Pidgin's dialog for
Maemo. On Maemo, any unowned dialogs always float above /all/ toplevel
windows and, because of the reduced screen size, they tend to occupy the
choice parts of the screen. Thus, when an unowned dialog is visible, all
applications on the tablet are rendered useless until the dialog is
dismissed. So, I need to pass GtkWindow *parent type parameters to all
Pidgin functions that pop dialogs.

I find this to be a fairly sticky problem in the case of the "request"
functions (i.e., purple_request_* and the corresponding
pidgin_request_*). These functions have void *user_data parameters, but
those are intended for the ok and cancel callbacks, not the UI itself. I
was thinking about some solutions:

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.

This would be fairly invasive, I think, because it involves changing a
pile of APIs in both libpurple and Pidgin.

2. Wrap user_data using a function like
pidgin_request_user_data_new(parent_window, existing_user_data) and pass
its output as purple_request_*'s user_data parameter, knowing that the
resulting data will end up in pidgin_request_*'s hands where it can be
unpacked and the parent_window can be extracted.

3. Store the "currently active toplevel" in a global variable,
surrounded by accessors. The setter would set the global variable and
attach a weak ref to the window which would unset the global variable if
it still referred to the same window. The getter would simply return the
global variable.

All these solutions are somewhat hackish, but I really can't think of
another way to make sure that these dialogs have proper parents. I'm
hoping that the list can offer some thoughts on these or other solutions
to this problem.

TIA for your help,


More information about the Devel mailing list