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@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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
