[virt-tools-list] virt-manager handling of Gtk command line arguments

[Leonardo Augusto Guimarães Garcia]

Hello everyone,

Right now, when someone tries to start a second instance of 
virt-manager, the primary instance will be brought to front. This is 
managed by Gtk and I am really fine with that for the majority of the 
use cases.

When someone specifies a --show-* option and there is already a 
virt-manager instance running, however, it would be desirable that the 
running instance of virt-manager opens the corresponding window, as 
suggested by Cole some time ago. I want to do a major refactoring on how 
we handle command line arguments in virt-manager (using the support 
provided by Gtk) in order to support that, but while I was working on 
that, I faced the following comment in virt-manager code:

     # The never ending fork+gconf/gsettings problems now require
     # us to import Gtk before the fork. This creates a funny race,
     # since we need to parse the command line arguments to know if
     # we need to fork, but need to import Gtk before cli processing
     # so it can handle --g-fatal-args. We strip out our flags first
     # and pass the left overs to gtk

Is this still necessary/true? This code is currently being called after 
the fork (it was called before the fork in virt-manager-0.9.x). Also, it 
seems that Gtk 3 can handle its arguments pretty well (I don't know how 
it was in the past). I wrote a simple test.py program:

import sys
print sys.argv
from gi.repository import Gtk
print sys.argv

And if I run "./test.py --foo --bar --g-fatal-warnings", the output is 
the following:

[laggarcia at localhost ~]$ ./test.py --foo --bar --g-fatal-warnings
['./test.py', '--foo', '--bar', '--g-fatal-warnings']
['./test.py', '--foo', '--bar']

Hence, I think we can just import Gtk in the beginning of the code and 
it will correctly handle its arguments. Do you agree? Can I proceed with 
this cleanup and send a patch?

Best regards,

Leonardo Garcia