[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: Future of cdebconf's gtk frontend: from gtk2 to gtk3

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

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.


Attachment: signature.asc
Description: Digital signature

Reply to: