[Freewx-maint] wxWidgets 3.x and GTK+ 3

[Olly Betts]

On 6 July 2017 at 08:49, Björn Harrtell <bjorn.harrtell at gmail.com> wrote:
> 2017-07-05 1:38 GMT+02:00 Olly Betts <olly at survex.com>:
>> Björn Harrtell <bjorn.harrtell at gmail.com> wrote:
>> > I'm wondering if there are any plans to package wxWidgets 3.0/3.1
>> > compiled for GTK+ 3?
>>
>> It's not feasible to package wxWidgets 3.1, as it doesn't have a stable
>> ABI - each new upstream version would potentially require a library
>> transition in Debian.
>>
>> I had been hoping to switch to GTK3 with wx 3.2, but currently it looks
>> unlikely to me that upstream will release 3.2 soon, or at least soon
>> enough for it to be feasible to switch to for buster (we probably have
>> about 16 months before the buster freeze.  The 2.8 to 3.0 transition
>> took around a year, though there were quite a lot of incompatibilities
>> to deal with - I'd hope 3.0 to 3.2 is smoother, but even so with the
>> number of reverse dependencies wx has in Debian, a transition will take
>> time).

After discussions with wx upstream, they seem keen to try to get 3.2 out sooner.

3.0 to 3.2 API changes are small, though by default 3.2 drops
compatibility for the large amount of stuff removed/changed between
2.8 and 3.0.  But wx upstream suggested Debian shipping 3.2 with 2.8
compatibility enabled would be better than shipping 3.0.  If they're
happy with that, I'm happier shipping such a configuration.

However, wxPython "classic" seem like it's probably seen its last
release, and migrating rdeps to wxPython "phoenix" seems like it
requires quite a lot of code changes, which means more work for a
transition until enough time has passed for upstreams of projects
using it to have done the necessary changes.  But wxPython "phoenix"
has only just made its first beta release, so we can't expect many
upstreams to have migrated in time for buster.

I really don't have the time or energy for a wxPython transition which
is going to require a lot of cajoling of maintainers and upstreams, so
unless there's someone who does I think we may have to stick with wx
3.0 for buster.

>> The first thing we need to determine is whether the GTK version used
>> affects the ABI of the built libraries, so that would be useful to
>> check.

Actually the gtk2/gtk3 choice is encoded in the library name, so ABI
compatibility isn't relevant as we really need to handle this as an
ABI change anyway.

E.g. here's 3.0 built with GTK2 and 3.1 built with GTK3:

libwx_gtk2u_core-3.0.so
libwx_gtk3u_core-3.1.so

> If 3.2 is way off, perhaps it can still be worth switching to GTK 3 for
> wxWidgets 3.0.

I've now uploaded 3.0.3.1 (built with GTK2) which is due to migrate to
testing in the next day or so, so we're at least up to date with
upstream releases.

I'm looking at a build of this using GTK3 to upload to experimental or
maybe unstable (if it's easy to make the packages parallel install
cleanly).  That'll at least allow rdeps to easily test compatibility
with such a build.

> FWIW my personal interest in this is to extend the life of
> pgadmin3.

Does debian's wx packages switching to GTK3 help there?
https://www.pgadmin.org/download/ says:

| WARNING: pgAdmin 3 is no longer supported.

So I'd expect a switch to GTK3 to if anything be bad for Debian's
pgadmin3 package, as any issues which are actually in the pgadmin3
code won't get solved by pgadmin upstrream.

> However, I'm not confident about the stability of wxWidgets 3.0
> with GTK 3 at this time

My own testing of a build with GTK3 uncovered some issues.  It seems
wx upstream are responsive to GTK3-related bugs, and they've fixed
those they can reproduce.

However, at least one problem I found they can't reproduce.

Cheers,
    Olly