Bug#971422: libvte-2.91-0: vte_terminal_spawn_async doesn't accept NULL callback since 0.62

[Simon McVittie]

Control: retitle 971422 libvte-2.91-0: vte_terminal_spawn_async doesn't accept NULL callback since 0.62

On Wed, 30 Sep 2020 at 12:12:22 +0200, Pascal wrote:
> as described in this bug : https://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=970356
> It's impossible to launch mssh .
> 
> mssh -a serveurs
> 
> (mssh:105138): VTE-CRITICAL **: 12:10:20.197: void
> vte_terminal_spawn_with_fds_async(VteTerminal*, VtePtyFlags, const char*, const
> char* const*, const char* const*, const int*, int, const int*, int,
> GSpawnFlags, GSpawnChildSetupFunc, gpointer, GDestroyNotify, int,
> GCancellable*, VteTerminalSpawnAsyncCallback, gpointer): assertion 'callback'
> failed
> 
> an mssh window opens, but remains empty.

The documentation for vte_terminal_spawn_async() and its newer version
vte_terminal_spawn_with_fds_async() says it's valid to call them with a
NULL callback, but since 0.62.x the implementation doesn't allow this.
At least one of the documentation or the implementation must be wrong.

This is a regression in libvte-2.91-0: it doesn't accept something
that previously worked. However, mssh can work around this by passing
a non-NULL callback.

I would recommend making mssh use a non-NULL callback *anyway*, because
it's the only way for vte_terminal_spawn_async() to report errors, which
any non-trivial vte user should be reporting in some way. Something like
this should be suitable:

static void
terminal_spawn_async_cb (VteTerminal *terminal,
                         GPid pid,
                         GError *error,
                         gpointer user_data)
{
  if (error != NULL)
    g_critical ("Error setting up terminal: %s", error->message);
  else
    g_debug ("Terminal set up, process ID: %d", pid);
}

(Or whatever error handling mssh wants to do instead of complaining on
stderr: for example, it might want to emit the session-closed signal
on errors, or something like that.)

    smcv