We need to support GTK 3.0

[Sam Hartman]

Vala has started giving ominous warnings about gtk being deprecated and recommending that we need to support gtk+3.0. Which presumably means they will drop support for gtk soon.

1) Fixing that may well exceed normal support and maintenance, so I think we may need to add to our road map.

2) We're going to have kind of a big support mess, because I bet it is impossible to support both Centos6 and GTK 3.0 in the same product. This issue will require consideration.

This will probably become critical within 12 months but almost certainly not before the end of 2014.

[Justin Knight (justin-knight)]

To be discussed late October:
Effort, timescales, cost involved in supporting GTK 3.0
When it is required by (dependant on Ubuntu releases) - could be June 2015 or later

[Dan Breslau (dbreslau)]

I have a patch that allows the UI to build with Gtk+-3.0 and libgee-0.8 where those libraries are available; where they're not available, the build falls back to Gtk+-2.0 and libgee-1.0, which is actually older than libgee-0.8. See #1457651 for the patch.

I'm not sure if this patch is sufficient. For example, am I wrong in assuming that we can safely decide which version of the library to use by examining what is available on the build machine, always using the newer version if it's available? Are there supported OS releases in which we know we should *not* use the newer version of a library, even if it's available on the build machine? Are there releases where we should refuse to build if only the older version of a library is available?

I'm also not sure if the scope of this effort is restricted to build time. The Moonshot UI is source-compatible with Gtk+-3.0, but the vala compiler generates a number of deprecation warnings about certain Gtk widgets that we currently use. Removing these warnings would require using APIs that are only available in Gtk+-3.0. Hence if we still need to support Gtk+-2.0 for older OSs, then we'd need to maintain separate UIs for Gtk+-2.0 and Gtk+-3.0. (I expect we'd do this through conditional compilation.)

So, do we need to upgrade our source code to use non-deprecated APIs when compiling with Gtk+-3.0? Or, by compiling and producing a working UI with the existing code base, can we say that this task is complete?

[Sam Hartman (hartmans)]

So, for a C project without vala, this solution would be ideal.
Because of the issue I discussed in the gee-0.8 thread vala complicates
things.
Some aspects of what you ship in your "upstream" tarball will effect
things in annoying ways.

Options might include:

* mucking with automake to not include generated .c files in the
  upstream tarball and forcing people to have vala at build time

* Picking one of new or old to run make dist on and making sure you run
  a make distclean and rerun vala on systems of opposite
  newness/oldness. I'd probably pick new rather than picking old.

That's the options I can think of.
There may be others I only looked at this problem briefly.

--Sam

[Dan Breslau (dbreslau)]

I've marked this as "Fix Released" because we can now build a tarball for either Gtk+-2.0 or Gtk+-3.0, depending on what's in the local build environment. Will re-open if this fix turns out to be insufficient.