Platform dependencies

wxPython Users
1

I don’t know the whole history, so I’ll ask whether wxWidgets and/or wxPython started out primarily for Windows? I’ve run across some rather basic things that work properly on Windows but not on Mac or (Ubuntu) Linux.

I may already have mentioned that on Mac/Linux wx.SystemSettings.GetMetric() returns -1 for all window metrics other than full screen size, which is definitely annoying, and this has made it necessary to hard-code some numbers such as menu bar height (which presumably will fail on different Linuxes or even on different window managers on the same Linux). Works on Windows.

In wx.StaticText, centre and right styles are ignored on Mac/Linux. They work on Windows.

2

For the history see:

···

On 09/02/13 22:29, Bruce Sherwood
wrote:

  I don't know the whole history, so I'll ask whether

wxWidgets and/or wxPython started out primarily for Windows? I’ve
run across some rather basic things that work properly on Windows
but not on Mac or (Ubuntu) Linux.

    I may already have mentioned that on Mac/Linux

wx.SystemSettings.GetMetric() returns -1 for all window metrics
other than full screen size, which is definitely annoying, and
this has made it necessary to hard-code some numbers such as
menu bar height (which presumably will fail on different Linuxes
or even on different window managers on the same Linux). Works
on Windows.

    In wx.StaticText, centre and right styles are ignored on

Mac/Linux. They work on Windows.

–

  You received this message because you are subscribed to the Google

Groups “wxPython-users” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to .
For more options, visit .
http://www.wxwidgets.org/about/history.htm

–
Steve Gadget Barnes

wxpython-users+unsubscribe@googlegroups.com
https://groups.google.com/groups/opt_out

3

Bruce,
Part of the whole point of FOSS - (Free Open Source Software) - is
that you can contribute as well as everybody else - if something is
causing you an issue there are three things you can do 1) Moan that
the software you are using is a heap of [insert your option here],
2) Raise a bug report so that those working on the software have
something concrete to investigate, 3) download the latest source
code, build it, confirm the problem still exists and investigate it,
fix it and submit a patch against the bug report you raised in 2),
If you have done 2 & 3 and your changes have not been
incorporated then 1 becomes an option but otherwise it just gets up
the nose of all the people who have worked so hard on bringing you
such a brilliant resource.
Note with non-FOSS software such as anything from M$oft, Apple,
etc., 3 is never an option, (often not even if you are a developer
working for the company), 2 may only be an option if you have an
expensive support contract - leaving only 1 as an option which may
be why we have all got into the habit of doing so.
One of the lovely things with wx is the level of contact with the
developers that we have plus we all have the opportunity to
contribute.
Steve

···

On 09/02/13 22:29, Bruce Sherwood
wrote:

  I don't know the whole history, so I'll ask whether

wxWidgets and/or wxPython started out primarily for Windows? I’ve
run across some rather basic things that work properly on Windows
but not on Mac or (Ubuntu) Linux.

    I may already have mentioned that on Mac/Linux

wx.SystemSettings.GetMetric() returns -1 for all window metrics
other than full screen size, which is definitely annoying, and
this has made it necessary to hard-code some numbers such as
menu bar height (which presumably will fail on different Linuxes
or even on different window managers on the same Linux). Works
on Windows.

    In wx.StaticText, centre and right styles are ignored on

Mac/Linux. They work on Windows.

–

  You received this message because you are subscribed to the Google

Groups “wxPython-users” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to .
For more options, visit .

–
Steve Gadget Barnes

wxpython-users+unsubscribe@googlegroups.com
https://groups.google.com/groups/opt_out

4

“wx.ST_NO_AUTORESIZE: By default, the control will adjust its size to exactly fit to the size of the text when SetLabel() is called. If this style flag is given, the control will not change its size (this style is especially useful with controls which also have the wxALIGN_RIGHT or the wxALIGN_CENTRE_HORIZONTAL style because otherwise they won’t make sense any longer after a call to SetLabel()).”

On Mac (I don’t use Linux) it looks like the control adjusts its size to fit the text on creation as well, so the declared size is ignored. Using wx.ST_NO_AUTORESIZE as described above provides the correct alignment even if you are not calling SetLabel()

···

On Saturday, 9 February 2013 22:29:06 UTC, Bruce Sherwood wrote:

In wx.StaticText, centre and right styles are ignored on Mac/Linux. They work on Windows.

–
Regards,
David Hughes

5

Thanks! I was misled by the fact that I was setting the label in the constructor, without use of SetLabel, and that worked on Windows. Then later, when I tried the program on Mac and Linux and it failed, I didn’t think to look at other style options.

Bruce

···

On Sunday, February 10, 2013 5:21:01 AM UTC-7, David Hughes wrote:

On Saturday, 9 February 2013 22:29:06 UTC, Bruce Sherwood wrote:

In wx.StaticText, centre and right styles are ignored on Mac/Linux. They work on Windows.

“wx.ST_NO_AUTORESIZE: By default, the control will adjust its size to exactly fit to the size of the text when SetLabel() is called. If this style flag is given, the control will not change its size (this style is especially useful with controls which also have the wxALIGN_RIGHT or the wxALIGN_CENTRE_HORIZONTAL style because otherwise they won’t make sense any longer after a call to SetLabel()).”

On Mac (I don’t use Linux) it looks like the control adjusts its size to fit the text on creation as well, so the declared size is ignored. Using wx.ST_NO_AUTORESIZE as described above provides the correct alignment even if you are not calling SetLabel()

Regards,
David Hughes

6

I don't know the whole history, so I'll ask whether wxWidgets and/or
wxPython started out primarily for Windows? I've run across some rather
basic things that work properly on Windows but not on Mac or (Ubuntu) Linux.

Bruce,

Regardless of history, wxMac is definitely not as well supported. One
reason is that it simply doesn't get as much use, either from end
users or core developers. Another reason is that the Mac platform has
changed a lot more over the history of wx -- the shift from the old
MacOS to carbon, and now an even bigger change to Cocoa.

However the most common cases are that the different platforms are a
bit different, an often something works on one and not others.
Usually, there is a "right way" to do it that works on all platforms,
but you don't always stumble upon that way with your first go -- you
try something, it works, and you move on.

As a result, whatever platform you do your primary work on is going to
appear to work "better" than the others

So testing on all the platforms you want to support early and often is key.

In wx.StaticText, centre and right styles are ignored on Mac/Linux. They
work on Windows.

wx.StaticText is a wrapper around the platform-native static text
widgets, which are often not even full widgets -- so they have some
cire differences. You may want to try GenStaticText(), it's written in
Python, is a "proper" wx.Window, and should be more platform-neutral.

I was misled by the fact that I was setting the label in the constructor, without use of
SetLabel, and that worked on Windows. Then later, when I tried the program on Mac
and Linux and it failed, I didn't think to look at other style options.

This is a good thing to put in:

http://wiki.wxpython.org/wxPython%20Platform%20Inconsistencies

-Chris

···

On Sat, Feb 9, 2013 at 2:29 PM, Bruce Sherwood <bruce.sherwood@gmail.com> wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

7

Thanks for your comments, Chris. You presumably remember that you gave me a function for creating a bitmap from text, to use as a texture. I’ve been working with classic wxPython but have just started working with Phoenix, in order to be able to have a Python 3 version of VPython based on wxPython. After just a few minutes of addressing simple issues I was able to run most of the standard VPython demos, but not those that depend on your function, and I wasn’t able to decipher from the help on migration how to make the needed change.

Your function ends with

dc.SelectObject( _wx.NullBitmap )

img = _wx.ImageFromBitmap(bmp):

data = fromstring(img.GetData(), dtype=uint8)

and the problem is that the final statement gives an error about 1st arg must be a “pinned buffer”, not a byte array. I’d like to continue to end up with “data” being a numpy array, since that matches the current connection between Python and C++ in VPython. Is there something simple I can do to address the issue? Thanks.

8

Your function ends with

    dc.SelectObject( _wx.NullBitmap )
    img = _wx.ImageFromBitmap(bmp):
    data = fromstring(img.GetData(), dtype=uint8)

this is the numpy fromstring()?

and the problem is that the final statement gives an error about 1st arg
must be a "pinned buffer", not a byte array. I'd like to continue to end up
with "data" being a numpy array, since that matches the current connection
between Python and C++ in VPython. Is there something simple I can do to
address the issue? Thanks.

I haven't used either Phoenix or Python 3, so I don't know that I can
be any help. MAybe Robin has some ideas, or you can ask on the numpy
list what a "pinned buffer" is -- that error did come form numpy, yes?

But a couple things to try in the meantime:

what type does _wx.ImageFromBitmap(bmp) return? Maybe Phoenix on Py3
returns something else.

Also, py3 makes a clear distinction between strings (unicode) and
bytes objects, you might see if the py3 version of numpy as a
"frombytes" function, or somethign like that.

py3 alos has the nre buffer protocol -- ideally, Phoenix would return
something from GetData() that conforms to that, and numpy should be
able to consume that, maybe with:

np.asarray(), even.

see: PEP 3118 – Revising the buffer protocol | peps.python.org

-Chris

···

On Mon, Feb 11, 2013 at 10:55 AM, Bruce Sherwood <bruce.sherwood@gmail.com> wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

9

Hi,

Thanks for your comments, Chris. You presumably remember that you gave me a
function for creating a bitmap from text, to use as a texture. I've been
working with classic wxPython but have just started working with Phoenix, in
order to be able to have a Python 3 version of VPython based on wxPython.
After just a few minutes of addressing simple issues I was able to run most
of the standard VPython demos, but not those that depend on your function,
and I wasn't able to decipher from the help on migration how to make the
needed change.

Your function ends with

    dc.SelectObject( _wx.NullBitmap )
    img = _wx.ImageFromBitmap(bmp):
    data = fromstring(img.GetData(), dtype=uint8)

and the problem is that the final statement gives an error about 1st arg
must be a "pinned buffer", not a byte array. I'd like to continue to end up
with "data" being a numpy array, since that matches the current connection
between Python and C++ in VPython. Is there something simple I can do to
address the issue? Thanks.

Try the following, hopefully it will do what you want:

import wxversion
wxversion.ensureMinimal('2.9.5')

import wx
import numpy

app = wx.App(0)

bmp = wx.Image('done.png', wx.BITMAP_TYPE_PNG)
data = numpy.fromstring(numpy.asarray(bmp.GetData()), dtype=numpy.uint8)

print data

Also, wx.ImageFromBitmap is deprecated in Phoenix, so at some point
you will want to change that to the new constructor:

wx.Image(bitmap)

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #

···

On 11 February 2013 19:55, Bruce Sherwood wrote:

10

Thanks, Andrea – your suggestion does indeed work.

However, it doesn’t work if I change wx.ImageFromBitmap to wx.Image, though with the former function I do get the error message wxPyDeprecationWarning: Call to deprecated item ImageFromBitmap. Use :class:Image instead.

Here’s my context, in which I’m drawing text into a bitmap, from which I make an image (fromstring and asarray have been imported from numpy);

for n, line in enumerate(lines):

dc.DrawText(line, 1, heights[n])

dc.SelectObject( _wx.NullBitmap )

img = _wx.ImageFromBitmap(bmp) # gives warning but works

img = _wx.Image(bmp) # doesn’t work

data = fromstring(asarray(img.GetData()), dtype=uint8)

11

I found it. I just needed to use img = bmp.ConvertToImage()

···

On Monday, February 11, 2013 6:26:03 PM UTC-7, Bruce Sherwood wrote:

Thanks, Andrea – your suggestion does indeed work.

However, it doesn’t work if I change wx.ImageFromBitmap to wx.Image, though with the former function I do get the error message wxPyDeprecationWarning: Call to deprecated item ImageFromBitmap. Use :class:Image instead.

Here’s my context, in which I’m drawing text into a bitmap, from which I make an image (fromstring and asarray have been imported from numpy);

for n, line in enumerate(lines):

dc.DrawText(line, 1, heights[n])

dc.SelectObject( _wx.NullBitmap )

img = _wx.ImageFromBitmap(bmp) # gives warning but works

img = _wx.Image(bmp) # doesn’t work

data = fromstring(asarray(img.GetData()), dtype=uint8)

12

I should comment that I’m delighted to find that after very little effort all aspects of VPython now work with Phoenix on 32-bit Python 3.2 (VPython already works with classic wxPython on 32-bit and 64-bit Python 2.7 on Windows/Mac/Linux.)

13

Hi Bruce,

···

On 12/02/2013 05:11, Bruce Sherwood wrote:

I found it. I just needed to use img = bmp.ConvertToImage()

I see you found your solution, which is mentioned in the Phoenix doc - in case you are not aware of them:
http://wxpython.org/Phoenix/docs/html/Image.html

Werner

14

Hi Bruce,

Thanks, Andrea -- your suggestion does indeed work.

However, it doesn't work if I change wx.ImageFromBitmap to wx.Image, though
with the former function I do get the error message wxPyDeprecationWarning:
Call to deprecated item ImageFromBitmap. Use :class:`Image` instead.

It might be that this overloaded method didn't get in Phoenix yet, or
it is somehow overlooked by the parsers. I'll take a look if the issue
comes from the Python side.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #

···

On 12 February 2013 02:26, Bruce Sherwood wrote:

15

Andrea -- I'm a bit confused here (not running Phoenix to test myself...)

numpy.asarray() should create an array -- why the call to fromstring()?

could you have done:

numpy.asarray(bmp.GetData(), dtype=numpy.uinit8)
or
numpy.asarray(bmp.GetData()).astype(numpy.uinit8)

instead?

-Chris

···

On Mon, Feb 11, 2013 at 1:21 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

data = numpy.fromstring(numpy.asarray(bmp.GetData()), dtype=numpy.uint8)

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

16

Of course it might work, I didn't debug the issue that much, I have
just tried a couple of things just to make it work. There are a few
(very few) places in which Phoenix is stubbornly (although more
correct IMHO) incompatible with Classic, and raw image data
manipulation is one of them...

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #

···

On 12 February 2013 18:00, Chris Barker - NOAA Federal wrote:

On Mon, Feb 11, 2013 at 1:21 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:

data = numpy.fromstring(numpy.asarray(bmp.GetData()), dtype=numpy.uint8)

Andrea -- I'm a bit confused here (not running Phoenix to test myself...)

numpy.asarray() should create an array -- why the call to fromstring()?

could you have done:

numpy.asarray(bmp.GetData(), dtype=numpy.uinit8)
or
numpy.asarray(bmp.GetData()).astype(numpy.uinit8)

instead?

17

In fact, the following is sufficient for the Phoenix version. Thanks for the simplification.

img = bmp.ConvertToImage()

data = asarray(img.GetData())

···

On Tuesday, February 12, 2013 10:00:18 AM UTC-7, Chris Barker - NOAA Federal wrote:

On Mon, Feb 11, 2013 at 1:21 PM, Andrea Gavana andrea...@gmail.com wrote:

data = numpy.fromstring(numpy.asarray(bmp.GetData()), dtype=numpy.uint8)

Andrea – I’m a bit confused here (not running Phoenix to test myself…)

numpy.asarray() should create an array – why the call to fromstring()?

could you have done:

numpy.asarray(bmp.GetData(), dtype=numpy.uinit8)

or

numpy.asarray(bmp.GetData()).astype(numpy.uinit8)

instead?

-Chris

–

Christopher Barker, Ph.D.

Oceanographer

Emergency Response Division

NOAA/NOS/OR&R (206) 526-6959 voice

7600 Sand Point Way NE (206) 526-6329 fax

Seattle, WA 98115 (206) 526-6317 main reception

Chris....@noaa.gov

18

which implies the Pheonix wx.Image.GetData() is returnign a PEP 3118
buffer -- nice!

-Chris

···

On Tue, Feb 12, 2013 at 10:04 PM, Bruce Sherwood <bruce.sherwood@gmail.com> wrote:

In fact, the following is sufficient for the Phoenix version. Thanks for the
simplification.

        img = bmp.ConvertToImage()
        data = asarray(img.GetData())

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

19

Andrea Gavana wrote:

Hi Bruce,

Thanks, Andrea -- your suggestion does indeed work.

However, it doesn't work if I change wx.ImageFromBitmap to wx.Image, though
with the former function I do get the error message wxPyDeprecationWarning:
Call to deprecated item ImageFromBitmap. Use :class:`Image` instead.

It might be that this overloaded method didn't get in Phoenix yet, or
it is somehow overlooked by the parsers. I'll take a look if the issue
comes from the Python side.

No, it was probably just a copy/paste error in the docstring of ImageFromBitmap. I've got it fixed in my local workspace.

···

On 12 February 2013 02:26, Bruce Sherwood wrote:

--
Robin Dunn
Software Craftsman

20

Chris Barker - NOAA Federal wrote:

In fact, the following is sufficient for the Phoenix version. Thanks for the
simplification.

         img = bmp.ConvertToImage()
         data = asarray(img.GetData())

which implies the Pheonix wx.Image.GetData() is returnign a PEP 3118
buffer -- nice!

Yep. It's actually returning a bytesarray object, so it is mutable, and that is probably the source of the original "pinned buffer" error. Numpy probably wants a buffer that is not relocatable when it is mutated, or something like that. Here is the implementation of the GetData wrapper FYI:

     byte* data = self->GetData();
     Py_ssize_t len = self->GetWidth() * self->GetHeight() * 3;
     PyObject* rv = NULL;
     wxPyBLOCK_THREADS( rv = PyByteArray_FromStringAndSize((const char*)data, len));
     return rv;

It looks like there are some similar problems elsewhere, at least as of a few years ago: http://grokbase.com/t/python/python-list/101zg1a2cs/recv-into-bytearray-complains-about-a-pinned-buffer

···

On Tue, Feb 12, 2013 at 10:04 PM, Bruce Sherwood > <bruce.sherwood@gmail.com> wrote:

--
Robin Dunn
Software Craftsman