Libxfce4ui spawn api break

Nick Schermer nickschermer at gmail.com
Mon Nov 2 11:35:29 CET 2009


2009/11/1 Brian J. Tarricone <brian at tarricone.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/01/2009 02:41 PM, Nick Schermer wrote:
>>
>> It turns out returning the pid is not useful, because you can create
>> only 1 child watch per pid and we already need a child watch for
>> handling startup notification.
>> I though about adding a GChildWatchFunc and gpointer, which could be
>> called from the child watch we connect, but then there is not way to
>> disconnect the function, so that is not really a solution either.
>
> Oh hmm, yeah, that kinda sucks.  Stupid glib.
>
> Well, I guess it depends on how much work you want to do...  We could
> create a xfce_add_child_watch() that *does* allow more than one child
> watch (just store a list of callbacks in a hash table keyed by pid), and
> put that in libxfce4util.
>
> Not sure that's really a good idea, though... I hate adding new API for
> a one-off need.

Well right now it's only 1 place where we need it, but it's not
uncommon to watch a child. Not that I agree we should add a lot of api
for it, but still.

Another option would be a function that returns the XfceSpawnData on
succeed. Normally we free the data when the spawn is completed, but as
an alternative we could not free the data and leave that to the owner
(when the _full function is called).

XfceSpawnData *
xfce_spawn_on_screen_full (...);

void
xfce_spawn_set_callback (XfceSpawnData *data,
                                        GChildWatchFunc function,
                                        gpointer data,
                                        GDestroyNotify notify);

void
xfce_spawn_disconnect (XfceSpawnData *data);

Not a free function since the spawn could still be running, so
disconnect will unset the users' callbacks and enable auto-freeing
again or directly free if the spawn was completed. That is not a lot
of work, more like splitting the current code a bit.

Nick



More information about the Xfce4-dev mailing list