[wxPython] scaling bitmaps

[Kevin_Altis]

My suggestion is no different than the other additions Robin has made that
are wxPython-specific such as the DrawPointList. The methods don't have to
be part of wxWindows. The reason for just using wxImage for now is that the
methods can be further optimized later, it won't change the API. My guess is
that a lot of the wxBitmapFromImage... code would probably get duplicated
anyway, so unless there is a major penalty for duplication of data in
memory, the existing C++ methods might as well get reused.

ka

···

-----Original Message-----
From: wxpython-users-admin@lists.wxwindows.org
[mailto:wxpython-users-admin@lists.wxwindows.org]On Behalf Of Cliff
Wells
Sent: Tuesday, February 26, 2002 12:40 PM
To: wxpython-users@lists.wxwindows.org
Subject: Re: [wxPython] scaling bitmaps

On Tue, 26 Feb 2002 11:00:26 -0800 > Kevin Altis wrote:

> If SetPIL and GetPIL calls for wxBitmap simply did the necessary wxImage
> translation at the C++ level that would probably be good enough. So,
don't
> try converting directly to wxBitmap, continue using wxImage,
but wrap all
> the necessary work in C++ instead of Python. I guess there could be
SetPIL
> and GetPIL for wxImage too. For those that don't already know the
relevant
> wiki link is:

Hi Kevin,

I'm hesitant to suggest directly supporting PIL from wxPython for a couple
of reasons:
1. PIL is Python-specific (i.e. no support from the wxWindows community,
where the better C++ programmers are). If this is going to be an
efficient
translation, it'll need to be done in C++, preferably in the
wxBitmap class
and I foresee some possible resistance from the wxWindows developers to
adding Python-specific methods to their C++ code. (Unless we're going to
subclass wxBitmap and maintain the code ourselves... maybe not a
bad idea).
It would probably be easier to hack out a SetData method for wxBitmap and
submit it to the wxWindows developers.
2. PIL is not necessarily the end-all for image manipulation (although it
seems like it at the moment Having a general-purpose SetData() method
on the wxBitmap class allows other toolkits to interface in a more
efficient fashion.
3. I don't know that having [GS]etPIL methods would be any more efficient
than a generic SetData method.

Why don't you think we should skip the wxImage step? It seems that
wxImages are weak counterparts to PIL images and lose their
usefulness once
you start using PIL. wxBitmaps, on the other hand, are necessary, so it
makes sense to just cut wxImage out of the loop.

> I stopped using this code because it leaks memory and I'm not exactly
sure
> where. I probably should be setting some references to None, suggestions
> welcome.

It's probably something to do with using Windows. Why don't you grow up
and get a _real_ OS.
BTW, I'll try and get you those screenshots tonight (I /promise/ <crossing
>).

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwindows.org
http://lists.wxwindows.org/mailman/listinfo/wxpython-users

[Robin]

My suggestion is no different than the other additions Robin has made that
are wxPython-specific such as the DrawPointList. The methods don't have to
be part of wxWindows.

Excatly. It's one of the benefits of SWIG that we can fairly easily mix
custom C++ and/or Python code with what is generated . If that were not the
case then a large chunk of wxPython would not exist.

The reason for just using wxImage for now is that the
methods can be further optimized later, it won't change the API. My guess

is

that a lot of the wxBitmapFromImage... code would probably get duplicated
anyway, so unless there is a major penalty for duplication of data in
memory, the existing C++ methods might as well get reused.

Just for the record, I don't think a generic wxBitmap::SetData will be very
feasible. The platform implementations are just too different...

Where the big immediate benefit will come is reduction of copying of the
image data. Currently there are at least two extra copies of the data made
as it gets converted to and from Python strings to make the transition from
PIL to wxImage.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

[Chris_Barker1]

Kevin Altis wrote:

If SetPIL and GetPIL calls for wxBitmap simply did the necessary wxImage
translation at the C++ level that would probably be good enough. So, don't
try converting directly to wxBitmap, continue using wxImage, but wrap all
the necessary work in C++ instead of Python.

I'm not sure that we would gain much from that. When you use Python code
(as per your example) all the "heavy lifting" is done in C++ anyway.

Cliff Wells wrote:

PIL is quite flexible regarding depth/format:

It has a pretty good set, but do they corespond to teh native formats
ona wide variety of platforms? I suspect not. 16 bit color, for
instance, can be stored as 5 bits percolor, and one wasted, or 5 bits
for two colors, and 6 for another, etc...

Robin Dunn wrote:

Just for the record, I don't think a generic wxBitmap::SetData will be very
feasible. The platform implementations are just too different...

That's my concern as well.

Where the big immediate benefit will come is reduction of copying of the
image data. Currently there are at least two extra copies of the data made
as it gets converted to and from Python strings to make the transition from
PIL to wxImage.

Hmm, that could be helpfull. When you data is bigger than you cache,
this can take quite a while.

I'm really out of my depth here as far as implimentation is concerned,
but I do liek the idea of making this easier...

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (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

[Cliff_Wells4]

Just for the record, I don't think a generic wxBitmap::SetData will be

very

feasible. The platform implementations are just too different...

Which is why I suppose no such method currently exists.

Where the big immediate benefit will come is reduction of copying of the
image data. Currently there are at least two extra copies of the data

made

as it gets converted to and from Python strings to make the transition

from

PIL to wxImage.

So your suggestion would be to provide a way for wxImage to understand PIL
images, or simply a faster way of copying the PIL image into the wxImage
(bypassing Python strings)?

···

On Tue, 26 Feb 2002 13:32:46 -0800 Robin Dunn wrote:

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308

[Robin]

So your suggestion would be to provide a way for wxImage to understand PIL
images, or simply a faster way of copying the PIL image into the wxImage
(bypassing Python strings)?

Yes.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

[Geoff_Gerrietts1]

Quoting Cliff Wells (logiplexsoftware@earthlink.net):

> Just for the record, I don't think a generic wxBitmap::SetData
> will be very feasible. The platform implementations are just too
> different...

Which is why I suppose no such method currently exists.

I think, looking at the PIL source and thinking about how it works, it
might not be all that difficult to write something like this.

In order to do any kind of meaningful export of PIL's image formats,
you hafta pick an encoder and render the image using one of its
encoders. If you can tell which format you expect based on which
platform you're on, you should be able to pick your encoder properly.
It looks to me like you could pull the encoder from _imaging.so and
use it to produce the data you want, though you could just as easily
do that part of the operation in Python using PIL's already-wrapped
tools.

Then it's just a matter of getting wxBitmap to accept a buffer full of
bytes as input rather than file full of bytes.

I don't think I'm oversimplifying -- it doesn't seem that complicated.
I'd even take the task if I had a bit better facility with binding
python to C++. (And may yet given enough free hours, since this
functionality would be useful to me....)

···

On Tue, 26 Feb 2002 13:32:46 -0800 > Robin Dunn wrote:

--
Geoff Gerrietts <ggerrietts@yahoo.com>
-rw-rw-rw-: permissions of the beast

[Chris_Barker1]

Geoff Gerrietts wrote:

Quoting Cliff Wells (logiplexsoftware@earthlink.net):
> > Just for the record, I don't think a generic wxBitmap::SetData
> > will be very feasible. The platform implementations are just too
> > different...
>
> Which is why I suppose no such method currently exists.

I think, looking at the PIL source and thinking about how it works, it
might not be all that difficult to write something like this.

In order to do any kind of meaningful export of PIL's image formats,
you hafta pick an encoder and render the image using one of its
encoders. If you can tell which format you expect based on which
platform you're on, you should be able to pick your encoder properly.

I think this is the big question... how many different formats might you
encounter accross a variety of platforms? I thinkt he answer is: a lot.

It looks to me like you could pull the encoder from _imaging.so and
use it to produce the data you want, though you could just as easily
do that part of the operation in Python using PIL's already-wrapped
tools.

Only if PIL already support it. I suspect that this project would
involve discovering a lot of formats, and writing code to support them.

This really needs a question posted on wx-dev. I'm sure some of those
folks could provide some insite.

I'd even take the task if I had a bit better facility with binding
python to C++.

That's not the hard part. If you can get the C++ wxBitmap to let you
know about the format it needs, and to accept bunch of bytes, and get
encoders written for all teh common formats, making the Pyhon-C++
binding would be pretty easy, and I'm sure you could get help doing it!

-Chris

···

> On Tue, 26 Feb 2002 13:32:46 -0800 > > Robin Dunn wrote:

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (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

[Geoff_Gerrietts1]

Quoting Chris Barker (Chris.Barker@noaa.gov):

Geoff Gerrietts wrote:
>
> Quoting Cliff Wells (logiplexsoftware@earthlink.net):
> > > Just for the record, I don't think a generic wxBitmap::SetData
> > > will be very feasible. The platform implementations are just too
> > > different...
> >
> > Which is why I suppose no such method currently exists.
>
> I think, looking at the PIL source and thinking about how it works, it
> might not be all that difficult to write something like this.
>
> In order to do any kind of meaningful export of PIL's image formats,
> you hafta pick an encoder and render the image using one of its
> encoders. If you can tell which format you expect based on which
> platform you're on, you should be able to pick your encoder properly.

I think this is the big question... how many different formats might you
encounter accross a variety of platforms? I thinkt he answer is: a lot.

There are two platforms that I know are directly supported: Windows
and *nix. The Windows world uses the BMP format, the *nix world uses
the XPM format. That's well-defined, and documented in the wxBitmap
code. I can only assume that a finalized Mac version would have some
other format. All these dependencies are compile-time dependencies,
and it's not a lot of code to write, because PIL's already got the
format conversions built in.

See:
http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin470.htm#wxbitmapoverview

Only if PIL already support it. I suspect that this project would
involve discovering a lot of formats, and writing code to support them.

This really needs a question posted on wx-dev. I'm sure some of those
folks could provide some insite.

PIL does support the formats identified above. See:
http://www.pythonware.com/library/pil/handbook/image-file-formats.htm

> I'd even take the task if I had a bit better facility with binding
> python to C++.

That's not the hard part. If you can get the C++ wxBitmap to let you
know about the format it needs, and to accept bunch of bytes, and get
encoders written for all teh common formats, making the Pyhon-C++
binding would be pretty easy, and I'm sure you could get help doing it!

The wxBitmap doesn't need to tell me anything, because that's
platform-dependent and won't change after compile time. Getting it to
accept a string instead of a file might be tricky without making
changes to the base wxBitmap code (which I don't want to do if I can
avoid); I haven't looked, or even started considering /that/ problem.

The Swig and Python-to-C++ stuff is likely to be a little knotty
because one piece of C code will be invoking methods on another piece
of C code that was originally intended to work with Python.

The point of my response is that the file formats aren't a big issue.
We're using PIL's guts already, and it appears to know, deep in its
guts, how to produce data streams formatted according to these rules.
The trick isn't getting the data into the right form, but rather
getting the data into the wxBitmap.

···

> > On Tue, 26 Feb 2002 13:32:46 -0800 > > > Robin Dunn wrote:

--
Geoff Gerrietts <ggerrietts@yahoo.com>
-rw-rw-rw-: permissions of the beast

[Geoff_Gerrietts1]

Amending my last post, it looks like getting wxBitmap to accept
arbitrary data won't be all that difficult if I'm reading the docs
correctly.

It looks like there's a version of the constructor and a version of
Create which wxPython doesn't appear to be wrapping at the moment,
which would accept buffers of formatted bytes for the purpose of
generating wxBitmap objects.

Either or both should work handsomely, unless I'm misreading terribly.

···

--
Geoff Gerrietts <ggerrietts@yahoo.com>
-rw-rw-rw-: permissions of the beast

[Chris_Barker1]

Geoff Gerrietts wrote:

There are two platforms that I know are directly supported: Windows
and *nix.

When I said platform, I meant it in a broader sense than OS. I also
inculde different color depth displays, etc.

The Windows world uses the BMP format,

From the PIL docs, it does look like BMP has a number of color depth

options, so PIL may , in fact already support all we need for windows.
However, if you are going to do a byte dump, wouldn't you need to know
what format the wxBitmap is expecting? maybe the depth would be all the
info you need, and that wxBitmap can already tell you.

the *nix world uses
the XPM format. That's well-defined, and documented in the wxBitmap
code.

From the PIL docs: (http://www.pythonware.com/library/pil/handbook/image-file-formats.htm)

XPM (read only) :
The library reads X pixmap files (mode "P") with 256 colours or less.

I don't know what X uses for color-depths of greater than 8 bpp, and as
far as I know XPM is a file format (text at that!), not an internal
binary format. Also read-only.

I can only assume that a finalized Mac version would have some
other format.

well, PICT is native, at least on pre-OS-X. PICTS can have lots of stuff
in them, so who knows?

because PIL's already got the format conversions built in.

Clearly I'm not so sure, but I hope you are closer to the truth than me.
I'm sorry to be a nay-sayer. I think this would be useful to do, and I
hope you are right that it's not a huge deal.

I wish you luck...
-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (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

[Cliff_Wells4]

If you look at the Python-specific details at the end, you'll see a
constructor

wxBitmapFromBits(bits, width, height, depth=-1)
Create a bitmap from an array of bits contained in a string.

However, my one attempt to use this failed, as I don't know what format the
bits argument is supposed to be in. However, if it expects a Python
string, it won't really help as it seems likely that the conversion to/from
Python strings is a major bottleneck anyway.

···

On Wed, 27 Feb 2002 13:11:13 -0800 Geoff Gerrietts wrote:

Amending my last post, it looks like getting wxBitmap to accept
arbitrary data won't be all that difficult if I'm reading the docs
correctly.

It looks like there's a version of the constructor and a version of
Create which wxPython doesn't appear to be wrapping at the moment,
which would accept buffers of formatted bytes for the purpose of
generating wxBitmap objects.

Either or both should work handsomely, unless I'm misreading terribly.

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308

[Robin]

There are two platforms that I know are directly supported: Windows
and *nix. The Windows world uses the BMP format, the *nix world uses
the XPM format.

That's the image *file* formats supported direclty by wxBitmap, which is not
what we're after. What is needed is direct conversion from one of PIL's
in-memory formats directly to wxBitmap's internal memory format, or if
that's not easily possible (I don't think so**) then to wxImage's internal
format. The process should minimize image data copying (which is the
problem with the current way of doing it in Python) and image data
transformations. Also it should transfer any transparency in the source to
a wxMask.

** Compare and contrast wxMSW's, wxGTK's and wxMac's
wxBitmap::CreateFromImage methods...

...

The Swig and Python-to-C++ stuff is likely to be a little knotty
because one piece of C code will be invoking methods on another piece
of C code that was originally intended to work with Python.

The point of my response is that the file formats aren't a big issue.
We're using PIL's guts already, and it appears to know, deep in its
guts, how to produce data streams formatted according to these rules.
The trick isn't getting the data into the right form, but rather
getting the data into the wxBitmap.

The SWIG part will be simple, it will just be a wrapper around one function,
something like:

    wxBitmap* wxBitmapFromPIL(Image img);

The simple no-trick-first-pass implementation can just get the RGB data from
PIL point a wxImage at it, call ConvertToBitmap and return the bitmap.
Masks can come after that, and then an attempt to bypass wxImage if anyone
thinks it can/should be done.

There is a way to handle exporting C functions from one Python extension
module to another, it's called CObjects and wxPython is already doing it to
export some helper functions from the core wxc module to the others, such as
htmlc or gridc. I wouldn't be surprised if PIL is already doing a CObjects
based export. If not there are other ways (not as pretty) to do it.

The real trick will be finding someone with enough knowledge of the guts of
PIL at the C level and a desire and time to do this.

From the next message:
It looks like there's a version of the constructor and a version of
Create which wxPython doesn't appear to be wrapping at the moment,
which would accept buffers of formatted bytes for the purpose of
generating wxBitmap objects.

The wxBitmap interface has it but it just finds a wxBitmapHandler and calls
a method of it. The handlers I looked at just returned FALSE instead of
actually doing anything with the data so you can't depend on that unless you
write your own wxBitmapHandler, (but I expect that it would have to do the
same thing that a wxImage --> wxBitmap conversion is doing anyway...)

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

[Geoff_Gerrietts1]

Quoting Cliff Wells (logiplexsoftware@earthlink.net):

···

On Wed, 27 Feb 2002 13:11:13 -0800 > Geoff Gerrietts wrote:

> Amending my last post, it looks like getting wxBitmap to accept
> arbitrary data won't be all that difficult if I'm reading the docs
> correctly.
>
> It looks like there's a version of the constructor and a version of
> Create which wxPython doesn't appear to be wrapping at the moment,
> which would accept buffers of formatted bytes for the purpose of
> generating wxBitmap objects.
>
> Either or both should work handsomely, unless I'm misreading terribly.
>

If you look at the Python-specific details at the end, you'll see a
constructor

wxBitmapFromBits(bits, width, height, depth=-1)
Create a bitmap from an array of bits contained in a string.

However, my one attempt to use this failed, as I don't know what format the
bits argument is supposed to be in. However, if it expects a Python
string, it won't really help as it seems likely that the conversion to/from
Python strings is a major bottleneck anyway.

The bits constructor is different than a data constructor.

The bits constructor expects a monochrome bitmap.

--
Geoff Gerrietts <ggerrietts@yahoo.com>
-rw-rw-rw-: permissions of the beast

[Cliff_Wells4]

Are you sure? It has -1 as the default depth.

···

On Wed, 27 Feb 2002 13:33:57 -0800 Geoff Gerrietts wrote:

The bits constructor is different than a data constructor.

The bits constructor expects a monochrome bitmap.

--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308

[Geoff_Gerrietts1]

Quoting Cliff Wells (logiplexsoftware@earthlink.net):

···

On Wed, 27 Feb 2002 13:33:57 -0800 > Geoff Gerrietts wrote:

> The bits constructor is different than a data constructor.
>
> The bits constructor expects a monochrome bitmap.

Are you sure? It has -1 as the default depth.

If you read up by where they talk about the C++ version, it says "only
use for monochrome". Presumably it's ignoring the depth argument
because it's an array of bits -- one bit per pixel.

--
Geoff Gerrietts <ggerrietts@yahoo.com>
-rw-rw-rw-: permissions of the beast

[Geoff_Gerrietts1]

Quoting Robin Dunn (robin@alldunn.com):

>
> There are two platforms that I know are directly supported: Windows
> and *nix. The Windows world uses the BMP format, the *nix world uses
> the XPM format.

That's the image *file* formats supported direclty by wxBitmap, which is not
what we're after. What is needed is direct conversion from one of PIL's
in-memory formats directly to wxBitmap's internal memory format, or if
that's not easily possible (I don't think so**) then to wxImage's internal
format. The process should minimize image data copying (which is the
problem with the current way of doing it in Python) and image data
transformations. Also it should transfer any transparency in the source to
a wxMask.

** Compare and contrast wxMSW's, wxGTK's and wxMac's
wxBitmap::CreateFromImage methods...

Well, the idea was to use the same "convert from file" logic on an
in-memory file. Sounds like that won't work -- and I don't really want
to write an on-the-fly XPM converter (even though it looks pretty
easy, to look at it) if I don't hafta, and it looks like I hafta since
PIL's not writing that right now.

The SWIG part will be simple, it will just be a wrapper around one function,
something like:

    wxBitmap* wxBitmapFromPIL(Image img);

Hmm, my exposure to SWIG has been dcOracle's wrapper, which is hairier
than a yeti.

The real trick will be finding someone with enough knowledge of the guts of
PIL at the C level and a desire and time to do this.

I'm not sure I'm qualified, but since it's been bandied around for a
while and nobody else seems to be either, I may start working on it,
because this would be a lot more convenient and speedy than the
alternatives we presently have.

The wxBitmap interface has it but it just finds a wxBitmapHandler and calls
a method of it. The handlers I looked at just returned FALSE instead of
actually doing anything with the data so you can't depend on that unless you
write your own wxBitmapHandler, (but I expect that it would have to do the
same thing that a wxImage --> wxBitmap conversion is doing anyway...)

Yeah, that doesn't sound like useful code, exactly.

···

--
Geoff Gerrietts <ggerrietts@yahoo.com>
-rw-rw-rw-: permissions of the beast

[Geoff_Gerrietts1]

Quoting Geoff Gerrietts (ggerrietts@yahoo.com):

Quoting Robin Dunn (robin@alldunn.com):

> The real trick will be finding someone with enough knowledge of the guts of
> PIL at the C level and a desire and time to do this.

I'm not sure I'm qualified, but since it's been bandied around for a
while and nobody else seems to be either, I may start working on it,
because this would be a lot more convenient and speedy than the
alternatives we presently have.

Still don't know if I'm qualified, though I've made decent progress
with PIL's internals. Now my principal concern is whether I'm even
competent enough to build out of CVS.

A fresh checkout of CVS yields errors when building wxPython as follows:

src/gtk/wx.cpp: In function `PyObject *ptrset (PyObject *, PyObject *, int, char *)':
src/gtk/wx.cpp:381: warning: unused variable `PyObject *obj'
src/gtk/wx.cpp: In function `PyObject *ptradd (PyObject *, int)':
src/gtk/wx.cpp:467: warning: `PyObject *obj' might be used uninitialized in this function
src/gtk/wx.cpp: In function `void initwxc ()':
src/gtk/wx.cpp:2564: `wxEVT_MENU_CHAR' undeclared (first use this function)
src/gtk/wx.cpp:2564: (Each undeclared identifier is reported only once for each function it appears in.)
src/gtk/wx.cpp:2565: `wxEVT_MENU_INIT' undeclared (first use this function)
src/gtk/wx.cpp:2567: `wxEVT_POPUP_MENU_INIT' undeclared (first use this function)
src/gtk/wx.cpp: At top level:
src/gtk/wx.cpp:61: warning: `PyObject *t_output_helper (PyObject *, PyObject *)' defined but not used

I've checked and rechecked all the configuration stuff that I'm
supposed to do if I'm building out of CVS, and it looks like I should
be ok.

I've gone looking through all the wxsources and anything that's
installed on my system, and found nothing that resembles these
particular symbols. Is this a CVS hairball? Maybe wxPython's a
half-step behind or ahead of wxGTK and friends getting this in? Are my
SWIG wrappers just out of date (do I really need to go get and rebuild
SWIG to build out of CVS reliably)?

I'm a little lost and I figure someone else probably has answers
faster than I can dig them up. If I'm wrong, I'll spend more time
looking around. But if I'm right... please share!

Thanks,
--G.

···

--
Geoff Gerrietts <ggerrietts@yahoo.com>
-rw-rw-rw-: permissions of the beast

[Robin]

A fresh checkout of CVS yields errors when building wxPython as follows:

...

I've gone looking through all the wxsources and anything that's
installed on my system, and found nothing that resembles these
particular symbols. Is this a CVS hairball? Maybe wxPython's a
half-step behind or ahead of wxGTK and friends getting this in?

It's been a few days since I've updated and built on wxGTK. There have been
a few interface changes lately and the code needs tweaked in a few places
and regenerated. Try again in about an hour.

Are my
SWIG wrappers just out of date (do I really need to go get and rebuild
SWIG to build out of CVS reliably)?

No. Only if you need to make changes to a .i file.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

[Geoff_Gerrietts1]

Quoting Robin Dunn (robin@alldunn.com):

It's been a few days since I've updated and built on wxGTK. There have been
a few interface changes lately and the code needs tweaked in a few places
and regenerated. Try again in about an hour.

Thanks. Sorry to put you under the gun there, wasn't my intention. But
it did work like a charm, I think I've got everything successfully
built from source now.

I've been looking at samples in gizmos.cpp and crossreferencing the
Python API at python.org. Those seem to be reasonable choices for
examples, but would anyone recommend something better?

Thanks,
--G.

···

--
Geoff Gerrietts <ggerrietts@yahoo.com>
-rw-rw-rw-: permissions of the beast