summaryrefslogtreecommitdiff
path: root/README
blob: 5fcd24b120ceae255ecfba9adc485b7a3c69724d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
The wxpy30-update script
========================

The script wxpy30-update is intended to assist updating software which works
with wxPython 2.8 to work with wxPython 3.0.

If you use the --wx26update option, it will also try to update features from
wxPython 2.6, but is likely to do a less complete job there.  This mode is
off by default because it renames things like "wxApp" to "wx.App", and it
seems that people quite commonly use things like "wxApp" as variable names
in their code.

There are other command line options to control what classes of changes it will
try to make and what files it will update - run it with --help for more
details.  But if run with no arguments, it will attempt to update all files
with a .py extension found in or below the current directory.

The results should definitely be checked by a human, as it is possible for
it to make incorrect updates.  Also, it currently replaces constants
which were removed in 3.0 and which 2.8 just defined to 0 with a literal
0, which looks odd when bitwise-or-ed with other constants.  Also, other
constant name updates can result in the same constant being bitwise-or-ed twice
into a bitmap, which also looks a bit odd.

You should also check any uses of the wxversion module, as no attempt is
currently made to update those.

Feel free to try to make it work better, or to suggest improvements.

WXDEBUG Assertions
==================

In wxWidgets 3.0, upstream now defaults to enabling their "WXDEBUG" checks for
incorrect API usage - in 2.8 this was an option, and the python-wxgtk2.8-dbg
package contains such a build (not detached debug symbols, as you might expect
- the use of the "-dbg" suffix here actually predates detached debug symbol
packages).

A consequence of this change is that code which misuses the wx API and was
quietly being dealt with in a sensible way by python-wxgtk2.8 will pop up
warning dialogs with python-wxgtk3.0.

While overall sorting out such issues is good, these dialogs are intrusive for
users, and just suppressing them leaves us in much the same state we were
already in.  To do this in with wxPython, you just need to call
SetAssertMode(wx.PYAPP_ASSERT_SUPPRESS) on the wx.App object, ideally just
after you create it.  E.g.:

def MyApp(wx.App):
    def OnInit(self):
        # Suppress WXDEBUG assertions, as happens by default with wx2.8.
        self.SetAssertMode(wx.PYAPP_ASSERT_SUPPRESS)

        frame = MyFrame(None, "Title")
        self.SetTopWindow(frame)

        frame.Show(True)
        return True

wx.PySimpleApp
==============

This is deprecated in wxPython 3.0 - the replacement seems to be to use
wx.App(False) instead (thanks to Scott Talbert for this tip).

wx.TopLevelWindow.GetSize() and SetSize()
=========================================

Under GTK, these now include the window decorations - use GetClientSize()
if you just want the "inside" of the window.  If the main window of the
app seems a bit too small now, this is probably why.

wx.Sizer.Remove(wx.Window)
==========================

You now need to call Detach() instead of Remove() (the rationale for this
API change was that Remove() deletes the object for the other things it can
remove, so it's confusing that it doesn't for wx.Window.  This is rather
hard for the update script to automate though.