Hi folks! [ Feel free to forward this to people/derivatives using d-i and who might be interested in joining the discussion; I intend to contact gtk maintainers anyway once we reach a consensus, so that they know how we're going to use their udebs. ]
With wheezy out, I finally looked at the libgtk-3-0-udeb which has been floating around for a while, and attempted porting cdebconf to use it. It led to filing #708475[CAIRO], which means that the gtk3 udeb isn't usable until cairo is fixed (trip through NEW for that), and until gtk+3.0 is rebuilt against it. [CAIRO] http://bugs.debian.org/708475 I've just pushed a pu/gtk3 branch to cdebconf.git[GIT] for now, which does the following: 1. introduce gtk2gtk3.h, which is a convenience header where I've added a few wrappers to compensate for deprecated functions. (I've used a double underscore as a prefix to make those obvious.) 2. patch a few more things with #if 0/#else/#endif, since those weren't necessarily easily wrappable in the same way: some function pointers need a different signature, and that was becoming nasty. [GIT] http://anonscm.debian.org/gitweb/?p=d-i/cdebconf.git The end result is that the graphical installer works enough to confirm that the gtk3 udeb and the to-be-introduced new cairo udeb work. And that porting cdebconf to gtk3 can happily continue (basically, the rendering and snapshotting code paths need love). I expect to update (that includes possible rewrites) the pu/gtk3 branch, and possibly upload the resulting package to the experimental distribution; but also to *not* merge it/upload to unstable at the moment. Besides code changes, a gtk3 theme is going to be appreciated once the heavy work is over (probably to be shipped from rootskel.git/src/etc). Now, question: ,--- | Do we need, or want, to keep the option of building upcoming cdebconf | releases against gtk2 once the gtk3 port finds its way to master? `--- In a nutshell that would mean: a. a few more lines to configure.ac; nothing dramatic™. b. propagating an extra define to the said wrapper, so that we define __foo(...) as foo(...) in the gtk2 case. c. dealing with the signature changes mentioned in the second point above. The last point could lead to some kind of ugly code. I didn't look into it too much, but duplicating functions entirely would be hated; and adding too many #ifdef/#else/#endif due to incompatible APIs wouldn't be loved either. But if there are convincing arguments for a dual-gtk support, I guess we could figure something out. Mraw, KiBi.
signature.asc
Description: Digital signature
