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

[Cole Robinson]

On 08/12/2013 05:10 PM, Leonardo Augusto Guimarães Garcia wrote:
> 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)

What does 'the support provided by GTK' mean ? Can you give an example. As in,
does this throw out optparse ?

> 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']
>

Right, that is known to work. We need to import GTK before running optparse,
or optparse chokes on --g-fatal-warnings. And we need to fork before running
GTK. But we only know if we need to fork by running optparse. So it's not
really a race like the comment says, but an ordering issue.


> 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?
> 

I just tried moving GTK before the fork, and it breaks ./virt-manager with no
options on F19. So I don't think that's an option. Unfortunately this stuff is
historically a nightmare, and it all stems from not having any way to force
SSH to give us an askpass dialog unless we process is daemonized.

- Cole