[virt-tools-list] RFC: drop virt-viewer support for GTK-2 and use GTK-3 features

[Daniel P. Berrange]

On Mon, Jun 09, 2014 at 07:28:04AM -0400, Marc-André Lureau wrote:
> 
> 
> ----- Original Message -----
> > On Mon, Jun 09, 2014 at 12:50:15PM +0200, Guido Günther wrote:
> > > On Mon, Jun 09, 2014 at 11:29:33AM +0100, Daniel P. Berrange wrote:
> > > > Currently the virt-viewer codebase is written to build with both GTK-2
> > > > and GTK-3. This was primarily so that we could continue to support use
> > > > of virt-viewer on older distros like RHEL-6 which lack GTK-3 support.
> > > > GTK-3 has been around for 3 years now and RHEL-7 with GTK-3 support is
> > > > not unreasonably far off in the future.
> > > 
> > > I think that's a great idea!
> > > 
> > > > So I'm thinking it could be a good time for us to drop support for
> > > > GTK-2, and actually make use of some of the more interesting GTK-3
> > > > features we've been holding back on.  In particular I think we should
> > > > make use of the application menus in the GNOME shell top bar, and/or
> > > > the new GTK design whereby apps have a drop down menu in their window
> > > > titlebar. This would let us kill the current menu bar free'ing up
> > > > more
> > > 
> > > Besides of "help" this would probably be the window title bar
> > > (GtkHeaderBar) since the actions are per window/wm (like attaching a
> > > USB device).
> > 
> > Oh and it also means we'd be able to depend on GSettings to store
> > preferences, and not have to have two codepaths for GConf vs GSettings
> 
> I am not fond of this change, because we have to continue support for
> Windows (and other OS) and as you mentioned RHEL6.

RHEL6 is going to be effetively bug-fix only mode once RHEL-7 comes out
though, so we could continue support for that and other old distros, by
having a stable branch off our last GTK2 release.

> Afaik, gtk3 is not very well supported on Windows, because most popular Gtk+
> applications running on Windows are still using gtk2, so testing has been
> very limited, and gtk3 is moving too quickly for Windows devs to follow.

Oh I thought we were already shipping a GTK3 windows build, but it seems
that we're merely testing it during autobuild.sh but then forcing GTK2
for MSI builds :-(

> I am aware of some of the issues we have with gtk2 vs gtk3, but I think
> it's still possible to maintain both.

Sure, we could continue to support both, but if we want to take advantage
of new GTK3 features it's going to mean adding a lot more #ifdef conditional
code. We can certainly do that if we think GTK2 is still important enough,
but I was just hoping that we're at a switch-over point by now.

If we don't do it now, then it would be a good idea to set ourselves a
future target for when to drop GTK2 support. eg perhaps we say we aim to
drop it 1st July 2015 ?

> Furthermore, I think fancier UI/design and integration with GNOME should go
> in Boxes instead. 

I'm not really talking about fancy integration with GNOME here, just
taking advantage of current GTK-3 features and following best practice
recommended design. I don't think existance of Boxes is a reason for not
taking advantage of current state of the art GTK3 features.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|