Switch over to use GObject introspection bindings for all python
modules related to GObject/GTK3/etc. It is not possible to mix
and match old pyggtk/pygobject manual bindings with new introspection
based bindings so it must be all changed in one go.
Imports like
import gtk
Change to
from gi.repository import Gtk
The vmmGObject class is changed to always inherit from GObject.GObject
There is no compelling reason to avoid a GObject dep for the
virt-manager TUI & it horribly messed up the code.
Signal declarations are changed from
vmmChooseCD.signal_new(vmmChooseCD, "cdrom-chosen", [object, str])
To
__gsignals__ = {
"cdrom-chosen": (GObject.SignalFlags.RUN_FIRST, None, [object, str])
}
which is required by new GObject bindings
Most of the rest of the change is simply dealing with renamed
constants / classes.
Alot of legacy compat code was removed - ie helpers which
check to see if certain GTK2 methods are available are no
longer required since we're mandating GTK3 only.
The event loop is replaced with LibvirtGLib's event loop.
Still todo
- Rip out all DBus stuff & make vmmEngine class inherit GtkApplication
which provides unique support & DBus method handling
- Switch to use LibvirtGConfig & LibvirtGObject for libvirt interaction
- Possibly switch to Python 3 too ?
- Figure out why GNOME keyring is missing Introspection support
My suggestion is that the standalone GIT repo for virt-install
only live on as a support branch for legacy platforms.
A stable-0.9 branch of virt-manager can be kept for legacy PyGtk2
based virt-manager releases.
The virt-manager master branch should exclusively use GObject
inspection and ideally Python3 and contain both the virt-manager
and virt-install codebases in one since they are intimately
related to each other & using separate GIT repos has needlessly
complicated life for everyone.
crobinso:
Some locking fixes
Misc cleanups and dropping now-useless code
Fix dbus usage
Fix graph cell renderer regression
Fix a couple tooltip issues
In general it complicates things for minor simplifications in some
cases. I think it's better just to learn that anything invoked from
a thread that _might_ touch the UI should just be dispatched in an
idle callback. Anything UI bits that we need immediately in a thread
can just use some creative trickery (like is done in connectauth) to
block in a safe manner.
Glade is long since deprecated, and the 'glade' tool in F15 and up doesn't
even handle glade format files!
This effectively drops support for running virt-manager on a RHEL5 host,
which has a GTK that is too old to support gtkbuilder.
The process here was:
- On RHEL6, open all glade files with glade3, use Edit->Preferences to
change format to gtk builder. (the gtk-builder-convert tool
produced all sorts of brokenness, and f16 glade3 can't even open
old glade files).
- Open these new files in glade on f16 and resave (since glade is
notorious for reformatting files over new versions, saves churn
the first time someone goes to patch the UI using a modern glade)
On app close, all dialogs are properly cleaned up so there are no
dangling references and python can garbage collect.
While this isn't that important when the app shuts down, it ensures that
lifecycle changes while the app is running (vm start/stop/remove, conn
start/stop/remove) have the infrastructure to properly release resources.