IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
This patch changes the default checkbox-state of "Delete all
associated storage" to be checked, but adds a prompt with a warning
for users to be sure they notice this change and they know what they
are doing (hopefully).
(crobinso: confirm even if no gconf schema available, cosmetic spacing
fixup, add Martin to AUTHORS)
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.
We should get this for free by using gtk Dialogs for our various UI pieces,
however the stock dialog is pretty restrictive WRT widget spacing, and
prevents us from make our nice blue header, so we are stuck with gtk.Windows
