[Bug-freedink] Bug#750001: freedink-dfarc: Please update to wxwidgets3.0

[beuc]

Control: severy 750001 normal
thanks

Hi,

wxGlade does not support wxWidgets 3 because upstream says so:
https://bitbucket.org/agriggio/wxglade/commits/acbfabfba67bc795a6ccecaabda933ecb0d0f63d#chg-wxglade.py

For instance it adds wxTHICK_FRAME by itself, in the .wxg and the
generated .cpp.

Can you add to your list the packages that depend on wxPython
(apt-rdepends counts 70) to get a clearer understanding of the
situation.  Please don't change the severity of this bug until then.
You'll get a bug dependency on wxglade, I'll be able to depend on it.

Good news about MXE.

I think you don't have to worry about bugs on 2.8 - if upstream
doesn't want to fix bugs, you could recommend (not enforce) impacted
people to upgrade?

- Sylvain

On Thu, Jun 26, 2014 at 02:12:47AM +0100, Olly Betts wrote:
> # blocks the on-going wxwidgets3.0 transition
> severity 750001 serious
> thanks
> 
> On Sat, May 31, 2014 at 04:23:12PM +0200, address@hidden wrote:
> > I (as upstream) do not wish to update to wxWidgets2.8 yet because
> > wxGlade (used to generate the *_Base.cpp files) doesn't support it,
> > and because MXE (for the Windows cross-build) doesn't seem to either
> > (though it builds 2.9 already).
> 
> In what way does wxGlade not handle the patched code?  The changes
> I made in that area were just updating things which were deprecated in
> 2.8 and have been removed in 3.0; if wxGlade doesn't handle them, it's
> likely broken for wx2.8 too.
> 
> As upstream, you don't have to drop wx2.8 support to add wx3.0 support
> (the patch I sent should work with both), but FWIW MXE appears to
> support wx3.0:
> 
> https://github.com/mxe/mxe/blob/master/src/wxwidgets.mk
> 
> > So while such a move is planned, it's too early to make it.
> > Please consider supporting both 2.8 and 3.0 in Jessie (as with 2.6/2.8).
> > It will also make backports easier.
> 
> It's really not feasible to support two different wx releases in Jessie
> - there are only two people in the wx team who have been at all active
> in recent times.  Since there's no upstream interest in wx2.8, and a
> number of packages actually require wx3.0, wx3.0 is the sane choice.
> 
> Having 2.6 and 2.8 in a release together didn't work out well -
> bugs in 2.6 just piled up because upstream weren't interested.  That's
> not what we want in a large and complex library package.
> 
> > Last, I (as package maintainer) would object to Debian diverging from
> > upstream, especially with forwarded:no patches, so no NMU please.
> 
> Since you are upstream maintainer, we can now consider the patch as
> forwarded.
> 
> The patch I sent doesn't break compatibility with wx2.8 - I did a test
> build to verify this.
> 
> Note that in wx2.8 wxTHICK_FRAME is just defined to wxRESIZE_BORDER, so
> changing wxRESIZE_BORDER|wxTHICK_FRAME to wxRESIZE_BORDER makes no
> different to behaviour.