Libxfce4ui spawn api break
jannis at xfce.org
Sat Oct 31 18:49:49 CET 2009
On Sat, 31 Oct 2009 18:45:04 +0100
Nick Schermer <nickschermer at gmail.com> wrote:
> While i was adding startup notification support to the thunar uca
> plugin, i discovered some applications might need to have the pid of
> the spawned process [to setup a g_child_watch_add(_full)] to monitor
> when it exits (in case of the uca plugin: it refreshed the working
> directory of the action to make sure file changes are visible, even on
> volumes that don't support file monitoring or when file monitoring is
> somehow disabled).
> So I'd like to add a pid return field like this:
> xfce_spawn_on_screen (GdkScreen *screen,
> const gchar *working_directory,
> gchar **argv,
> gchar **envp,
> GSpawnFlags flags,
> gboolean startup_notify,
> guint32 startup_timestamp,
> const gchar *icon_name,
> GPid *child_pid, /* <-- new variable */
> GError **error);
> The xfce_spawn_command_line_on_screen() function won't be touched.
> Any objections, better ideas?
It's ok from my perspective. As I said on IRC I think we should add
this to the release model document:
The API of a component may be broken during the development cycle if
the symbols to be broken were introduced in that same cycle.
Since everyone is advised to keep core components in sync and in a
release ready state, this would allows for more experiments within
development cycles. Once a development cycle ends and the final release
is made, all new symbols are frozen.
If we can agree on that, go ahead. I personally think
xfce_spawn_on_screen() should be at least as powerful as
gdk_spawn_on_screen(). And if it misses the PID, then we should add it
as long as we can.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the Xfce4-dev