Provide GTK+ 3.0 version of libappindicator

[Michael Terry]

Applications ported to GTK+ 3.0 cannot use libappindicator because it is built for GTK+ 2.0. it would be nice if libappindicator was provided in both 2.0 and 3.0 forms for applications.

[Michael Terry (mterry)]

This would appear blocked on at least dbusmenu-gtk and libindicator.

I've got a rough draft of adding a gtk3 version in a bzr branch, to be linked shortly. It isn't done yet because of the above mentioned non-gtk3 dependencies, but it compiles and parallel-installs. I chose 3.1 as the library version (vs current 0.1) to indicate its gtk3ness and to allow both libraries to march ahead with other incompatible changes (i.e. by bumping both to 0.2 and 3.2).

[Michael Terry (mterry)]

OK, I've added branches for libindicator and dbusmenu. They work for me. I've also updated the libappindicator branch. I will file merge requests.

Now, I don't use 3.1 as the library version. Instead, I use a 3 in the library name and both libraries use the same version. Seemed more appropriate.

[Ted Gould (ted)]

Just to follow up, we need to get these branches so they conditionally compile if gtk 3.0 is not available.

[Michael Terry (mterry)]

You had mentioned that was true because gtk 3.0 would be in universe. Is there any particular reason it has to be in universe? Being in main would be mean you could Build-Depend on it.

I can understand not being on the CD, but surely the MIR for gtk 3.0 would be trivial, given that gtk 2.0 is in main already.

[Ted Gould (ted)]

On Fri, 2010-07-02 at 15:27 +0000, Michael Terry wrote:
> You had mentioned that was true because gtk 3.0 would be in universe.
> Is there any particular reason it has to be in universe? Being in main
> would be mean you could Build-Depend on it.
>
> I can understand not being on the CD, but surely the MIR for gtk 3.0
> would be trivial, given that gtk 2.0 is in main already.

I think it's because the desktop team doesn't want to officially support
it for the Maverick cycle.

[Sebastien Bacher (seb128)]

we didn't get it at all in this cycle but the way GNOME components are doing is to decide a build time what gtk version using so it should build with either gtk2 or gtk3 then it's a packaging decision which one we build

[Michael Terry (mterry)]

But not for a library... You want to provide parallel-installable libappindicator and libappindicator3.0 (or whatever they get called) libraries because other packages might need one or the other. Otherwise, you'd have to move all the rdepends over to GTK+ 3.0 in lock-step.

[Michael Terry (mterry)]

Sebastian explained in IRC that he meant adding a configure flag for the gtk version and then building it twice as part of the debian packaging. That makes sense. I didn't understand that he was proposing two builds.

[Michael Terry (mterry)]

I've updated the dbusmenu branch to follow Sebastian's recommendation of adding a configure flag. So now you can pass --with-gtk=3 to get a gtk3 version (default is --with-gtk=2). One nice thing about this new update is that you can apply it today and have the gtk3 change be merely experimental until gtk3 is nicely packaged (the previous commit required gtk3 to build at all).

My branch also fixes bug 655632 by virtue of allowing the source to build against both gtk2 and gtk3.

Note that the the gtk3 version will require downstream packages to specifically mention gtk3 in their header includes. I did it this way because the existing layout is this:

/usr/include/libdbusmenu-0.1/:
 libdbusmenu-glib
 libdbusmenu-gtk

So I could either add the following and let the pc file handle it for downstreams by specifying a different -I flag:

/usr/include/libdbusmenu3-0.1/:
 libdbusmenu-glib (duplicated)
 libdbusmenu-gtk

Or avoid duplication and keep all the sub-libraries under one package namespace:

/usr/include/libdbusmenu-0.1/:
 libdbusmenu-glib
 libdbusmenu-gtk
 libdbusmenu-gtk3

I thought the second way made made more sense, but I can easily change that if ya'll like.

I'll be updating my other branches shortly.

[Michael Terry (mterry)]

OK, updated libindicator and application-indicator too. For application-indicator, I stopped building a separate indicator itself (just continued building a separate libappindicator). It doesn't make sense to have a gtk2 indicator and a gtk3 indicator for the same thing, AFAICT.

Also with libappindicator, I did *not* update the mono and python bindings. Those continue to be gtk2 only. They should be updated, but I thought this was a good stopping point. Bindings can be done after the rest gets merged.

[Sebastien Bacher (seb128)]

There is a first gtk3 build on https://edge.launchpad.net/~ubuntu-desktop/+archive/gnome3-builds/+packages which can be used to work on porting this source