On Sat, Aug 23, 2014 at 06:25:14PM +0200, Jakub Wilk wrote:
> >-WX_VERSIONS = ('2.8-unicode', '2.6-unicode')
> >+WX_VERSIONS = ('3.0-unicode', '2.8-unicode', '2.6-unicode')
> >DDJVU_API_MIN_VERSION = 26
> >PYTHON_DJVULIBRE_MIN_VERSION = (0, 1, 4)
> >
> >@@ -55,7 +55,7 @@ def _check_wx():
> >    except ImportError, ex:
> >        raise ImportError('%s; perhaps wxPython is not installed' % (ex,))
> >    if not wxversion.checkInstalled(WX_VERSIONS):
> >-        raise ImportError('wxPython 2.6 or 2.8 with Unicode support is 
> >required')
> >+        raise ImportError('wxPython 2.6, 2.8 or 3.0 with Unicode support is 
> >required')
> >    wxversion.select(WX_VERSIONS)
> 
> This looks good in principle, but when I had both 2.8 and 3.0
> installed, the former was selected... Perhaps it's a bug in
> wxversions?

I think it's a slight design flaw, coupled with the removal of
non-unicode option in 3.0.

For 3.0, you don't want the "-unicode" qualifier, since all builds are
Unicode builds now.  You can see this with:

$ python -c 'import wxversion; print wxversion.getInstalled()'
['3.0-gtk2', '2.8-gtk2-unicode']

But (as documented) wxversion.select() will pick the version from the
list with the most matching optional components, so if you try
('3.0', '2.8-unicode') the latter scores 1 more than the former:

$ python -c 'import wxversion; wxversion.select(("3.0", "2.8-unicode")); import 
wx; print(wx.__version__)'
2.8.12.1

A workaround is to ask for 3.0-gtk2:

$ python -c 'import wxversion; wxversion.select(("3.0-gtk2", "2.8-unicode")); 
import wx; print(wx.__version__)'
3.0.0.0

Or not to ask for 2.8-unicode:

$ python -c 'import wxversion; wxversion.select(("3.0", "2.8")); import wx; 
print(wx.__version__)'
3.0.0.0

We could fix this in Debian (perhaps allow -unicode for 3.0, or to
adjust the score for 3.0 if others specify -unicode or -ansi), but
it's really unhelpful for this to select different versions for
different distros.  I'll try to report this upstream, but the
wxPython devs seem unresponsive to bug reports (but the wxWidgets side
are generally great).

> >-            style=wx.OPEN,
> >+            style=wx.FD_OPEN,
> 
> This is fine, although not strictly necessary, and it breaks
> compatibility with wxPython2.6. Though perhaps I should drop support
> for 2.6 anyway, as I hadn't tested it for years.

My view is that wx 2.6 is completely irrelevant now (even the last 2.8
release was over 3 years ago, last 2.6 release seems to be over 8 years
ago).  And in general, you'll end up having to write code that's
conditional on the version to support both 2.6 and 3.0 (though some
simpler apps may not use any features which would require this).

In the C++ API, wxOPEN is gone in 3.0, so it seems likely that wx.OPEN
will go in Python in the next release series, so this update is really
for forward compatibility.

> >-        self.SetBestFittingSize(size)
> >+        self.SetInitialSize(size)
> 
> OK, although again not compatible with wxPython 2.6.

Indeed, but you get a deprecation warning from the former with 3.0.

> Alas, after applying this patch djvusmooth doesn't work well with
> wxPython 3.0. I spotted two problems:
> 
> * The PageUp and PageDown cannot be used for switching between
> pages. I partially fixed it by using wx.Notebooks instead of
> wx.Choicebook[1]. But the keys still don't work when the focus is on
> a TreeCtrl widget.
> 
> * Editing items in TreeCtrl widgets doesn't work.

I'll take a look.

Cheers,
    Olly


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to