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.
Attachment:
signature.asc
Description: Digital signature