GtkUnique is missing the ability to get more than just a status return value, like we do in Totem:
                line = totem_option_create_line (TOTEM_REMOTE_COMMAND_SHOW_PLAYING);
                bacon_message_connection_set_callback (conn,
                                totem_print_playing_cb, loop);
                bacon_message_connection_send (conn, line);

I don't understand why totem should use that... If the goal is to forbid the user to launch 2 instances of the application, you won't be able to play 2 videos simultaneously, side-by-side, in 2 different windows ?

(In reply to comment #2)
> I don't understand why totem should use that... If the goal is to forbid the
> user to launch 2 instances of the application, you won't be able to play 2
> videos simultaneously, side-by-side, in 2 different windows ?

And that's not supported nor planned. See bug #498826

*** Bug 501591 has been marked as a duplicate of this bug. ***

Bug 501591 was about making sure Totem can start when there is a zombie around (otherwise you'll have to restart the computer... not good). If GtkUnique doesn't handle this case, please remember to open a bug about it after the switch. :)

(In reply to comment #1 bug 501591)
> It is that code to blame, but I'm not sure how you would handle this case.
> Hopefully, switching to D-Bus in the future will take care of that, as the
> receiving end will time out, and allow us to start up.

Wouldn't it be better to check the status of the process and take immediate action if its state is Z(ombie)?

Also, when is the port to GtkUnique going to take place? After it has been moved to GTK+? I think that might take a while... In the mean time, could something be done about zombies in the current startup code?

(In reply to comment #5)
> Bug 501591 was about making sure Totem can start when there is a zombie around
> (otherwise you'll have to restart the computer... not good). If GtkUnique
> doesn't handle this case, please remember to open a bug about it after the
> switch. :)
> 
> (In reply to comment #1 bug 501591)
> > It is that code to blame, but I'm not sure how you would handle this case.
> > Hopefully, switching to D-Bus in the future will take care of that, as the
> > receiving end will time out, and allow us to start up.
> 
> Wouldn't it be better to check the status of the process and take immediate
> action if its state is Z(ombie)?
> 
> Also, when is the port to GtkUnique going to take place? After it has been
> moved to GTK+? I think that might take a while... In the mean time, could
> something be done about zombies in the current startup code?

Show me code that detects zombies and kills them in a reliable and portable way, I'm all for it. I don't think it exists though. And most of the problems with zombies would happen when only one thread in Totem dies/crashes without the rest following (ie. most of the time it's stuck, but not a Zombie).

You could probably add some better code to do the detection of a dead server at the try_server() part of BaconMessageConnection.

(In reply to comment #6)
> Show me code that detects zombies and kills them in a reliable and portable
> way, I'm all for it. I don't think it exists though.

Why don't you think detection is enough?

> And most of the problems
> with zombies would happen when only one thread in Totem dies/crashes without
> the rest following (ie. most of the time it's stuck, but not a Zombie).

Ok. But that's a related problem that might call for additional checks. :)

Uhm, why do you want to force users to open VLC or mplayer just to compare two videos? I often do that after transcoding from one format to another for example.

Selecting 10 files and clicking open should result in one totem window with a playlist. Opening one file and then another should result in two windows being opened. It is useful to be able to pause one video, play another and then unpause the first one without losing the information about current track and position.

2009-04-02  Bastien Nocera  <hadess@hadess.net>

        * configure.in:
        * src/Makefile.am:
        * src/bacon-message-connection.c:
        * src/bacon-message-connection.h:
        * src/plugins/lirc/totem-lirc.c (totem_lirc_to_command):
        * src/totem-object.c (totem_remote_command_get_type),
        (totem_action_exit), (totem_action_remote):
        * src/totem-options.c (totem_options_process_for_server):
        * src/totem-options.h:
        * src/totem-private.h:
        * src/totem.c (totem_message_received_cb), (main):
        * src/totem.h: Remove use of bacon-message-connection and 
        use libunique instead (Closes: #162822)