pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] threads & PythonCard

[Roman S. <rn...@on...>]

I've just understood that Tkinter and threads aren't compatible
under Windows. Is wxPython compatible with threads?
Will PythonCard apps be multithreaded?
What will be the way to interprocesscommunications for
PythonCard?

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Sunday, September 16, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Phobia: what's left after drinking 2 out of a 6 pack" _/

[Pythoncard-users] Numerical Python (numpy) and PythonCard

[Kevin A. <al...@se...>]

I was playing with PyGame earlier today to see how drawing times compared to
my code. PyGame is definitely faster, but I don't know what portions of my
wxPython code can be optimized. It will be a while before I know what we can
and can't do with PyGame, but right now it looks like we'll be able to
leverage PyGame for drawing and sound.

Anyway, while trying things out in PyGame, the issue of using a surface
array and numPy came up. Basically, the window bitmap gets stored as a numPy
array which is where all the calculations and plotting take place and then
you convert the numPy array back to a bitmap for the screen. Chris Barker
sent me some code a few weeks ago that also uses NumPy to speed up some
scaling transformations. I don't know whether numPy or PIL is faster for
rotation and other effects.

Anyway, numPy is new to me, just like PIL, so I'm not sure what conversions
I need to support to make it convenient to use. Is it enough to simply
support getArray and setArray type methods for Bitmap and a drawArray for
BitmapCanvas? I would appreciate some feedback from anyone using numPy on
what would be the most helpful.

There is an example conversion of a numPy array to wxImage/wxBitmap at:
http://wxpython.org/cgi-bin/wiki/WorkingWithImages

and there is some array to PIL and PPM code as part of the numPy demos. So,
conversions are easy to add to PythonCard, I just need to know what kinds,
so hopefully someone already doing visualizations with numPy can provide
some guidance.

I will probably move the Bitmap class out of widget.py and into its own
module, which I'm thinking about simply calling image.py. That module will
also contain any generic image conversion and utility functions outside the
Bitmap class. If you are interested in working on that module let me know.

I would like to provide convenient ways to display data from PIL and numPy
and thus make PythonCard a useful tool for users of those packages without
requiring them to learn much new stuff in order to get work done.

ka

[Pythoncard-users] getPILBits and setPILBits

[Kevin A. <al...@se...>]

I added two additional methods to the Bitmap class. The following shell
fragment using the doodle sample shows getting a PIL format RGB image from a
Bitmap and then setting the Bitmap with a PIL image. In both cases, the
transparency is still a problem, which probably has to do with my internal
conversion from GIF to RGB, but I haven't figured out how to properly
convert to and from RGBA or whatever format I should be using. Any PIL
experts in the house?

>>> import PythonCardPrototype
>>> bmp = PythonCardPrototype.widget.Bitmap('trash.gif')
>>> pil = bmp.getPILBits()
>>> comp.bufOff.drawBitmap(bmp, 10, 10)
>>> comp.bufOff.drawPIL(pil, 10, 50)
>>> bmp.setPILBits(pil)
>>> comp.bufOff.drawBitmap(bmp, 50, 10)

The Bitmap  class is used by the Image, ImageButton and BitmapCanvas
widgets. Note that the Image class causes a name conflict with the Image
module of PIL, so I had to add an additional import to widget.py to get
around it.

ka

[Pythoncard-users] drawPIL method added to BitmapCanvas

[Kevin A. <al...@se...>]

I added a drawPIL method to the BitmapCanvas widget so Roman or anyone else
can try some sample tests using images created or manipulated by PIL. The
changes are in cvs and will be part of the next release, which I hope to get
out by Tuesday, if not earlier. When your sample starts up you can check the
variable

  PythonCardPrototype.widget.PIL_FOUND

to make sure PIL exists on the local machine, or you can use a variation of
the test I currently use to set the variable in widget.py:

try:
    import Image
    PIL_FOUND = 1
except ImportError:
    PIL_FOUND = 0

I copied the trash.gif image from the proof directory into the doodle sample
directory and then typed the following lines in the shell to test out the
method.

>>> import Image
>>> source = Image.open('trash.gif')
>>> comp.bufOff.drawPIL(source, 10, 10)

Transparency appears to be lost in the conversion from PIL to wxImage to
wxBitmap, so perhaps Robin or some other wxPython expert can shed some light
on how to preserve the transparency color if available. On the other hand, I
wrote this method pretty quickly, so my code might just be buggy.

ka
---
    def drawPIL(self, image, x, y, transparency=1):
        if PIL_FOUND:
            if not self._drawingInProgress:
                self._bufImage.BeginDrawing()
                self._drawingInProgress = 1

            if (image.mode != 'RGB'):
                image = image.convert('RGB')
            imageData = image.tostring('raw', 'RGB')
            imageWx = wxEmptyImage(image.size[0], image.size[1])
            imageWx.SetData(imageData)
            bmp = wxBitmapFromImage(imageWx)
            #imageWx = apply(wxEmptyImage, image.size)
            #imageWx.SetData(image.convert("RGB").tostring() )
            #bmp = imageWx.ConvertToBitmap()
            self._bufImage.DrawBitmap(bmp, x, y, transparency)

            if self.autoRefresh:
                self._bufImage.EndDrawing()
                self._drawingInProgress = 0
                dcDelegate = wxClientDC(self._delegate)
                dcDelegate.Blit(x, y,
                                bmp.GetWidth(),
                                bmp.GetHeight(),
                                self._bufImage, x, y)

Re: [Pythoncard-users] thoughts on PIL and external packages

[Roman S. <rn...@on...>]

On Fri, 14 Sep 2001, Kevin Altis wrote:

>The more I look at PIL, the more I think we might want to use PIL as our
>native image format and any conversion required by wxPython for displaying
>bitmaps on screen would be hidden by our wrapper classes. Has anyone on the
>list done a lot of work with either wxPython wxImage/wxBitmap and/or PIL?

PIL is great and powerful, but it must be at the back because it doesn't
have display capabilities. Tkinter/PIL could be linked together nicely,
but I am not aware about wxPython. PIL is also pretty standard and more or
less mature.

The great thing about PIL is that it is universal and could be used with
any frontend. It is easy to link it with Numeric, for example, to
have even more powerful filters and transforms efficient.

Also, PIL has hooks to SANE (scanner system) and thus could be used
with web-cams, etc.

So, I am both hands for PIL to be used inside PythonCard!
(With animation, too!)

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Saturday, September 15, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Death is life's answer to the question 'Why?'" _/

[Pythoncard-users] hopalong benchmark

[Kevin A. <al...@se...>]

I wanted to get an idea of what the overhead for the current plot routine,
wxPython, blitting from an offscreen bitmap, etc. These numbers are rough at
best, but I needed to get a feel for the relative speed of drawing using
Python/wxPython.

In all the tests, I plotted one million points into roughly the same window
area. The Java applet was something I wrote a long time ago using AWT and it
isn't optimized, so I'm sure it could be made somewhat faster. One important
point is that all the Java variables and calculations were done with doubles
for better precision, the current Python version suffers from precision
problems that could probably be improved by using NumPy. It would probably
be interesting to do a Jython version, but that's left an exercise for the
reader.

All tests done with an AMD 1.2GHz, GeForce 2MX, 512MB RAM, Windows 2000 SP2,
screen depth @ 16-bits, ActivePython 2.1.212, wxPython 2.3.1

time in (seconds)   ops/sec   drawing type
-----------------------------------------------------------------
                4   250,000   Java applet using AWT
                4   250,000   hopalong.py, calculation only
                                plot() commented out
               19    52,632   hopalong.py, autoRefresh=0
               30    33,333   turtle.py, hopalong.txt script
                                direct screen draws, no offscreen
              118     8,475   hopalong.py, autoRefresh=1
                                1 pixel blit
              868     1,152   hopalong.py, autoRefresh=1
                                full window blit

The drawing time might be dramatically slower for other machines, video
cards, Linux, etc. It is unlikely that wxWindows is optimized for DirectX,
so another interesting test would be the same drawing using PyGame which
uses SDL which is a sort of cross-platform DirectX clone.

There a few observations I can make from the numbers above. The drawing time
for a single operation even with a full window blit after each plot command
is fast enough that interactive drawing say in response to mouse movement is
probably not a problem. The only problem might be that the blit operation
needs to be synced with the vertical refresh of the display to prevent
flashing, which would be up to wxWindows and may not be possible on Linux.

Second, like almost all drawing operations, the calculation time is small,
the real limitation is the I/O, drawing to the screen. I'm actually
surprised at the overhead of drawing to an offscreen bitmap (wxMemoryDC) in
wxWindows. wxWindows does not currently provide much in the way of clipping
rect or regions to determine whether a point plot, line drawing, etc. needs
to be drawn. It might be worthwhile to actually do our own tests to avoid
drawing when it isn't necessary.

The drawing time will go up if the operation is threaded, uses Yield, etc.
so that the user interface can remain responsive during a long calculation.
See
http://wxpython.org/cgi-bin/wiki/LongRunningTasks
for more info about possible solutions we might incorporate. I think we need
to do this, since most of the drawing people will want to do will probably
be interactive in nature and not batched.

The last point is that considering the speed of the hardware the tests were
done on, the combination of Python and wxPython does not appear to be a good
solution for many types of graphics intensive applications. That isn't
surprising, but I don't think we should spend much time trying to address
that solution space. It will be possible to do simple 2D games.

ka
---
partial Java hopalong program

    public int sign(double n) {
        if (n < 0) { return -1; } else { return 1; }
    }

    public void plot(Graphics g, double x, double y) {
        int x1, y1;

        x1 = (int) Math.round(xOffset + scale * x);
        y1 = (int) Math.round(yOffset + scale * y);
        g.drawLine(x1, y1, x1, y1);

    ...
        for (int i = 0; i < iterations; i++) {
            temp = y - sign(x) * Math.sqrt(Math.abs(b * x - c));
            y = a - x;
            x = temp;
		...
            g.setColor(color);
            plot(g, x, y);

        }

[Pythoncard-users] Why ZODB?

[Patrick K. O'B. <po...@or...>]

Here is a good answer to the question of why we might want ZODB for
PythonCard, from the article by Michel Pelletier at
http://www.zope.org/Documentation/Articles/ZODB1:

<quote>

ZODB is a database for Python objects that comes with Zope. If you've ever
worked with a relational database, like PostgreSQL, MySQL, or Oracle, than
you should be familiar with the role of a database. It's a long term or
short term storage for your application data.

For many tasks, relational databases are clearly a good solution, but
sometimes relational databases don't fit well with your object model. If you
have lots of different kinds of interconnected objects with complex
relationships, and changing schemas then ZODB might be worth giving a try.

A major feature of ZODB is transparency. You do not need to write any code
to explicitly read or write your objects to or from a database. You just put
your persistent objects into a container that works just like a Python
dictionary. Everything inside this dictionary is saved in the database. This
dictionary is said to be the "root" of the database. It's like a magic bag;
any Python object that you put inside it becomes persistent.

</quote>

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

[Pythoncard-users] ZODB as persistence mechanism

[Patrick K. O'B. <po...@or...>]

I'm diving into ZODB for a business project so I thought I'd volunteer to
take on some level of responsibility for investigating what it would take to
use ZODB as the persistence mechanism for PythonCard stacks. I think ZODB
has a lot going for it that might make it quite a good match for PythonCard.
At the same time, using ZODB will not be something that could just be tacked
on after the fact. I think the entire framework would have to be refactored
to accommodate the needs of ZODB.

In any case, I'll find out what the issues are and take the lead on the
analysis. If anyone wants to join me please feel free to do so. Here are two
good articles to get you started.

http://www.amk.ca/zodb/guide/zodb.html

http://www.zope.org/Documentation/Articles/ZODB1

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

Re: [Pythoncard-users] thoughts on PIL and external packages

[Andy T. <an...@cr...>]

Kevin Altis wrote:
> The more I look at PIL, the more I think we might want to use PIL as our
> native image format and any conversion required by wxPython for displaying
> bitmaps on screen would be hidden by our wrapper classes. Has anyone on the
> list done a lot of work with either wxPython wxImage/wxBitmap and/or PIL?
> The biggest initial complication I can see is that the PIL ImageDraw module
> http://www.pythonware.com/library/pil/handbook/imagedraw.htm
> appears to be less capable than the wxPython device context drawing
> routines, but I haven't actually used them yet, so I could be wrong. Perhaps
> it will be enough to simply provide easy translation between formats as I
> originally planned and continue to use native wxPython draw methods?!
> 
I'll leave that question and its resolution to other, more qualified, 
people. As the packager du jour though, I'll share my thoughts below;

> Part of the reason I'm bringing this up is that PIL is an external package
> that we wouldn't distribute with PythonCard, even if it was required. We
> might also need NumPy and other packages in the future. We're already
> relying on PyCrust.
> 
> PyCrust 0.6 was released earlier this week in a variety of formats:
> http://sourceforge.net/project/showfiles.php?group_id=31263
> 
> Given that PyCrust now uses distutils and provides a binary installer for
> win32, we should probably not include PyCrust in the PythonCardPrototype
> distribution, but simply point people towards the PyCrust distribution.

Yes, we probably should for the prototype. Once I've ironed out a couple 
of 'kinks' we will also have a binary installer for Win32. I should 
hopefully have an announcement early next week.

> 
> Any thoughts on this? It will complicate the installation of PythonCard,
> which already requires Python 2.1.x and wxPython 2.3.x, but it will make the
> PythonCardPrototype distribution more like other Python packages.

This is fine for the prototype but I think we should take an alternative 
approach when we approach the mythical 1.0 release. As PythonCard is 
intended to allow users to "develop graphical applications quickly and 
easily with a minimum of effort" we should plan to have an integrated 
installer. We should package up all of the components that comprise 
PythonCard and make them available in platform specific distributions 
(.exe, rpm, deb, etc.) That is probably a monster project in itself but 
we have plenty of time to work on it ;-)

> 
> Python sure could use a generic Debian-like installer for packages that
> pulls down the required packages from the web and handles installation, sort
> of a super distutils. I'm now expecting Roman to email and tell me that if I
> would have bothered to read the source I would see that this is the -u
> option of distutils. ;-)

Alas, having had a scout around the code I couldn't find that magical 
switch. This subject crops up on c.l.p on a regular basis and I think we 
are all agreed that we need a Pythonic version of CPAN (or Debian, which 
looks nicer to me). Sadly, no one (to my knowledge) has come up with a 
concrete proposal and implementation yet. Maybe someone should write a 
PEP? On that subject there are a couple of PEPs in the pipeline which 
should help the distributor's nightmare;

PEP 206 (batteries included) at 
http://python.sourceforge.net/peps/pep-0206.html is something we should 
be targetting. Making PythonCard part of a 'sumo' distribution is a good 
first step to becoming the defacto GUI development framework.

See also PEP 250 (Using site packages on Windows) at 
http://python.sourceforge.net/peps/pep-0250.html, which should help 
distributing modules somewhat by making the process on Windows more like 
Unix ones.
> 
> ka
> 
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can"

[Pythoncard-users] thoughts on PIL and external packages

[Kevin A. <al...@se...>]

The more I look at PIL, the more I think we might want to use PIL as our
native image format and any conversion required by wxPython for displaying
bitmaps on screen would be hidden by our wrapper classes. Has anyone on the
list done a lot of work with either wxPython wxImage/wxBitmap and/or PIL?
The biggest initial complication I can see is that the PIL ImageDraw module
http://www.pythonware.com/library/pil/handbook/imagedraw.htm
appears to be less capable than the wxPython device context drawing
routines, but I haven't actually used them yet, so I could be wrong. Perhaps
it will be enough to simply provide easy translation between formats as I
originally planned and continue to use native wxPython draw methods?!

Part of the reason I'm bringing this up is that PIL is an external package
that we wouldn't distribute with PythonCard, even if it was required. We
might also need NumPy and other packages in the future. We're already
relying on PyCrust.

PyCrust 0.6 was released earlier this week in a variety of formats:
http://sourceforge.net/project/showfiles.php?group_id=31263

Given that PyCrust now uses distutils and provides a binary installer for
win32, we should probably not include PyCrust in the PythonCardPrototype
distribution, but simply point people towards the PyCrust distribution.

Any thoughts on this? It will complicate the installation of PythonCard,
which already requires Python 2.1.x and wxPython 2.3.x, but it will make the
PythonCardPrototype distribution more like other Python packages.

Python sure could use a generic Debian-like installer for packages that
pulls down the required packages from the web and handles installation, sort
of a super distutils. I'm now expecting Roman to email and tell me that if I
would have bothered to read the source I would see that this is the -u
option of distutils. ;-)

ka

[Pythoncard-users] PIL to wxImage translation

[Kevin A. <al...@se...>]

Cliff Wells [log...@ea...] passed on some code that he
uses to convert between PIL and wxImage formats. Given the large number of
image manipulation routines in PIL, any wrapper classes we do for PythonCard
will probably use PIL or at least provide easy translation to and from PIL.

def PILToWX(image):
	"convert a PIL image to a wxImage"
	if (image.mode != 'RGB'):
		image = image.convert('RGB')
	imageData = image.tostring('raw', 'RGB')
	imageWx = wxEmptyImage(image.size[0], image.size[1])
	imageWx.SetData(imageData)
	return imageWx

def WXToPIL(image, mode = 'RGBA'):
	"convert a wxImage to a PIL RGBA image"
	imageData = image.GetData()
	size = (image.GetWidth(), image.GetHeight())
	imagePIL = Image.fromstring('RGB', size, imageData)
	if mode != 'RGB':
		imagePIL = imagePIL.convert(mode)
	return imagePIL


Here are some resources I mentioned previously, but are worth mentioning
again.

Python Imaging Library (PIL)
documenation in HTML and PDF formats, plus some PIL articles
http://www.pythonware.com/library/index.htm
source and binary distributions
http://www.pythonware.com/downloads/index.htm

wxPyWiki Working With Images
http://wxpython.org/cgi-bin/wiki/WorkingWithImages

ka

[Pythoncard-users] request for sizer samples

[Kevin A. <al...@se...>]

I've started to look at doing alternative layouts using sizers of some of
the existing samples. Initially, these will be done in the openBackground
handler just like I did for the hopalong and doodle samples. My guess is
that most will require the use of the wxFlexGridSizer class rather than a
simple nesting of wxBoxSizers, but this is new territory for me, so I could
be wrong.

Regardless, I need to build up a number of sample sizer layouts that I can
compare to the fixed point layouts before I can generalize some wrappers.
Most of the samples do not need the window size to grow, they simply must
handle the initial layout correctly regardless of the default font and
widget sizes. This is particularly important for Linux where the existing
fixed-size layouts do not work very well.

I would appreciate any layouts that you can submit. It might also be useful
to see some of the layouts, such as the proof sample done as an HTML table.
See Neil's .hta files in the PythonCardPrototype directory if you need to
know the corresponding form widgets in HTML.

Thanks,

ka

RE: [Pythoncard-users] hopalong sample sizers

[Kevin A. <al...@se...>]

And here's the somewhat simpler openBackground handler sizer setup for
doodle.py

    def on_openBackground(self, target, event):
        self.x = 0
        self.y = 0

        sizer1 = wxBoxSizer(wxVERTICAL)
        comp = self.components
        flags = wxLEFT | wxRIGHT | wxBOTTOM | wxALIGN_BOTTOM
        sizer1.Add(comp.btnColor._delegate, 0, flags, 5)
        sizer1.Add(comp.bufOff._delegate, 1, wxEXPAND)

        sizer1.Fit(self)
        sizer1.SetSizeHints(self)
        self.panel.SetSizer(sizer1)
        self.panel.SetAutoLayout(true)
        self.panel.Layout()

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Friday, September 14, 2001 8:50 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] hopalong sample sizers
>
>
> I modified the openBackground handler in the hopalong sample to
> use wxPython
> sizers. Please let me know if this causes any problems under Linux or
> Windows, it seems to work fine under Windows 2000. This is basically the
> same wxBoxSizer layout used by the Message Watcher if you want to compare
> code. My challenge is to wrap up the wxPython calls (wxBoxSizer is the
> simplest class of the bunch), so that you can get the effect of the code
> below, but specify the setup in the .rsrc.py. If you have any ideas let me
> know. Most layouts will require a more sophisticated sizer arrangement.
>
> For now, you can do manual sizer setups like the one below in your own
> openBackground handler.
>
> ka
> ---
>     def on_openBackground(self, target, event):
>         self.x = 0
>         self.y = 0
>         self.components.bufOff.backgroundColor = 'black'
>         self.components.bufOff.clear()
>
>         sizer1 = wxBoxSizer(wxVERTICAL)
>         sizer2 = wxBoxSizer(wxHORIZONTAL)
>         comp = self.components
>         flags = wxLEFT | wxRIGHT | wxBOTTOM | wxALIGN_BOTTOM
>         sizer2.Add(comp.stcA._delegate, 0, flags, 5)
>         sizer2.Add(comp.fldA._delegate, 0, flags, 5)
>         sizer2.Add(comp.stcB._delegate, 0, flags, 5)
>         sizer2.Add(comp.fldB._delegate, 0, flags, 5)
>         sizer2.Add(comp.stcC._delegate, 0, flags, 5)
>         sizer2.Add(comp.fldC._delegate, 0, flags, 5)
>         sizer2.Add(comp.stcIterations._delegate, 0, flags, 5)
>         sizer2.Add(comp.fldIterations._delegate, 0, flags, 5)
>         sizer2.Add(comp.stcXOffset._delegate, 0, flags, 5)
>         sizer2.Add(comp.fldXOffset._delegate, 0, flags, 5)
>         sizer2.Add(comp.stcYOffset._delegate, 0, flags, 5)
>         sizer2.Add(comp.fldYOffset._delegate, 0, flags, 5)
>         sizer2.Add(comp.stcScale._delegate, 0, flags, 5)
>         sizer2.Add(comp.fldScale._delegate, 0, flags, 5)
>         sizer2.Add(5, 5, 1)  # spacer
>         sizer2.Add(comp.btnDraw._delegate, 0, flags, 5)
>         sizer1.Add(sizer2, 0, wxEXPAND)
>
>         sizer1.Add(comp.bufOff._delegate, 1, wxEXPAND)
>         sizer1.Fit(self)
>         sizer1.SetSizeHints(self)
>         self.panel.SetSizer(sizer1)
>         self.panel.SetAutoLayout(true)
>         self.panel.Layout()
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] hopalong sample sizers

[Kevin A. <al...@se...>]

I modified the openBackground handler in the hopalong sample to use wxPython
sizers. Please let me know if this causes any problems under Linux or
Windows, it seems to work fine under Windows 2000. This is basically the
same wxBoxSizer layout used by the Message Watcher if you want to compare
code. My challenge is to wrap up the wxPython calls (wxBoxSizer is the
simplest class of the bunch), so that you can get the effect of the code
below, but specify the setup in the .rsrc.py. If you have any ideas let me
know. Most layouts will require a more sophisticated sizer arrangement.

For now, you can do manual sizer setups like the one below in your own
openBackground handler.

ka
---
    def on_openBackground(self, target, event):
        self.x = 0
        self.y = 0
        self.components.bufOff.backgroundColor = 'black'
        self.components.bufOff.clear()

        sizer1 = wxBoxSizer(wxVERTICAL)
        sizer2 = wxBoxSizer(wxHORIZONTAL)
        comp = self.components
        flags = wxLEFT | wxRIGHT | wxBOTTOM | wxALIGN_BOTTOM
        sizer2.Add(comp.stcA._delegate, 0, flags, 5)
        sizer2.Add(comp.fldA._delegate, 0, flags, 5)
        sizer2.Add(comp.stcB._delegate, 0, flags, 5)
        sizer2.Add(comp.fldB._delegate, 0, flags, 5)
        sizer2.Add(comp.stcC._delegate, 0, flags, 5)
        sizer2.Add(comp.fldC._delegate, 0, flags, 5)
        sizer2.Add(comp.stcIterations._delegate, 0, flags, 5)
        sizer2.Add(comp.fldIterations._delegate, 0, flags, 5)
        sizer2.Add(comp.stcXOffset._delegate, 0, flags, 5)
        sizer2.Add(comp.fldXOffset._delegate, 0, flags, 5)
        sizer2.Add(comp.stcYOffset._delegate, 0, flags, 5)
        sizer2.Add(comp.fldYOffset._delegate, 0, flags, 5)
        sizer2.Add(comp.stcScale._delegate, 0, flags, 5)
        sizer2.Add(comp.fldScale._delegate, 0, flags, 5)
        sizer2.Add(5, 5, 1)  # spacer
        sizer2.Add(comp.btnDraw._delegate, 0, flags, 5)
        sizer1.Add(sizer2, 0, wxEXPAND)

        sizer1.Add(comp.bufOff._delegate, 1, wxEXPAND)
        sizer1.Fit(self)
        sizer1.SetSizeHints(self)
        self.panel.SetSizer(sizer1)
        self.panel.SetAutoLayout(true)
        self.panel.Layout()

[Pythoncard-users] BitmapDrawing renamed to BitmapCanvas, drawBitmap method

[Kevin A. <al...@se...>]

I renamed the BitmapDrawing widget to BitmapCanvas. I also changed the
current methods to be more efficient when autoRefresh is 0 (false). Finally,
I added a drawBitmap method which accepts a Bitmap object, x, y location,
and whether to draw the image transparently if the bitmap has a transparency
mask.

I copied the trash.gif image from the proof sample into the doodle directory
to show this method in action from the shell.

>>> import PythonCardPrototype
>>> bmp = PythonCardPrototype.widget.Bitmap('trash.gif')
>>> comp.bufOff.drawBitmap(bmp, 50, 50)

Since our own Bitmap wrapper class is used, which is normally initialized
with a filename (a filename of '' gives you an empty bitmap), some extra
work is necessary if you wanted to use say an image created with the Python
Imaging Library (PIL). The Bitmap class has a setBits() method that accepts
a wxBitmap as input and that is what you would use to get a bitmap or image
created with another library into a PythonCard Bitmap.

See the wxPython Wiki
http://wxpython.org/cgi-bin/wiki/WorkingWithImages
for some more ideas.

At some point, we should write a more comprehensive set of wrapper and
conversion routines to simplify moving between PythonCard bitmaps and other
formats. Jeff Griffith mentioned several weeks ago that he was going to work
on icon packs
http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/762295
Jeff, how is this progressing?

Anyone interested in image processing, scientific and business graphing,
game programming, etc. that would like to work on this part of the framework
should speak up. I've talked to Pete Shinners, the PyGame author and there
are definitely ways the two frameworks can work together and we can probably
share some PyGame code as part of PythonCard as well.

ka

[Pythoncard-users] BitmapDrawing widget

[Kevin A. <al...@se...>]

I needed to get away from the television for a while last night, so I
started work on a BitmapDrawing widget for PythonCard. I stayed away from
the news coverage this morning as well to make a sample and put together
this rambling email. I still feel completely drained by the horrific attacks
on Tuesday, so I'm not getting much work done.

The first revision which is checked into cvs doesn't do much. It uses an
offscreen bitmap, supports setting the foregroundColor and backgroundColor,
plot(x, y), line(x1, y1, x2, y2), clear(), refresh(), autoRefresh attribute
(1 or 0), and drawText(aString, x, y); drawText uses the default font. All
the drawing and updating is brute force, it is unclear at this point what
optimizations can be made to speed up some operations.

The resourceEditor, Property Editor, and other parts of the framework don't
fully support the new widget.

One nice aspect of the widget is that it supports all the mouse events just
like the other PythonCard widgets. The doodle sample shows off just some of
these.

There are two samples, doodle and hopalong. Doodle just draws a pixel in the
current pen color while the mouse is down. Hopalong draws a mathematical
function on the screen based on the input values which can be set with the
fields at the top of the window. The drawing time is dramatically slower
when autoRefresh is true (roughly 3 - 4 times slower on my machine) and even
with autoRefresh off it can take 3.4 seconds on my AMD 1.2GHz machine to
draw 100,000 points. There is no way to cancel a drawing operation once it
is started (that is a later experiment), so be patient when drawing a large
number of points. The designs are often more interesting at the million
points or higher range. This is the same hopalong function used in one of
the turtle scripts.

The BitmapDrawing widget is experimental as are any samples that use it and
will likely change often for the next month or so; at this point I don't
even have a fixed set of design goals for the widget. I just wanted to get
something concrete into the framework to work with and help us generate
ideas.

I would like to strike a balance between ease of use, flexibility, and
speed. The current widget can be placed behind or overlapping any other
widgets, thus we can use a BitmapDrawing widget as our bitmap layer in
PythonCard probably with more flexibility than the bitmap drawing tools in
HyperCard. A separate tool will have to be provided to handle the user
interface manipulation of the widget bitmap contents like selection,
zooming, area fill, etc. I will convert the turtle sample to use the widget
sometime in the next month; eventually the turtle will just be part of the
basic PythonCard framework.

The BitmapDrawing widget is distinct from an object canvas where you can
select individual rectangles, lines, text, etc. and I expect that to be a
separate widget. Another library which people might want to look at is
PIDDLE http://piddle.sourceforge.net/ There is nothing that would prevent
doing drawing in PIDDLE and then placing the resulting bitmap into a
BitmapDrawing widget. If we want a unified drawing model that gives us the
best capabilities of PIDDLE and the underlying device contexts of
wxPython/wxWindows so that printing, drawing in PostScript, etc. are roughly
the same, that will need to be taken into account for the BitmapDrawing
widget.

One obvious problem I see with most of the current widgets is a lack of
transparency, which limits what we can do with overlapping widgets and
definitely limits the tricks that could be done with layering
BitmapDrawings. This might be a fundamental limitation of
wxPython/wxWindows.

I would like to support the Python Imaging Library, but am not sure whether
to wrap any of it or just leave its existing API exposed.

Anyway, please share your thoughts and ideas on what you would like to see
for bitmap graphics in PythonCard. You can start separate threads rather
than replying to this email if you want.

ka

[Pythoncard-users] Re: any feature requests?

[PeterAndBrian <pe...@pe...>]

At 12:17 PM 9/12/2001 -0700, Andy Todd wrote:
>In addition, the format and content of the actual application data is in
>the control of the developer and we should not constrain that in any
>way. I think we should support multiple back ends, and to that end we
>already have applications that support ZODB and MySQL. I'm currently
>working on a csv module and will also look at other RDBMS (Oracle and
>PostgreSQL are on my list). The developer of a PythonCard application
>should have the ability to choose where to store their data rather than
>us forcing a solution on them. Eventually we would want to support some
>kind of agnostic persistence layer (much like the approach AnyGui has
>taken to windowing toolkits) but we should wait until the framework and
>API have been worked out a bit more thoroughly.


Andy - I agree, we don't want to constrain anyone from using any data 
storage they see fit.  HyperCard did not prevent users from calling outside 
storage when needed.  But it did provide a built in, automatic, and 
wonderfully simple storage mechanism that met most peoples needs, most of 
the time.

At Wed, 12 Sep 2001 09:56:08 -0700, Kevin Altis wrote:
>I don't think we have a best candidate. What we discussed when the list
>started was a generic card or record class that would support a variety of
>backend data stores (repositories). The textIndexer sample uses ZODB. The
>addresses sample uses a list of dictionaries.


We will certainly need some mechanism, addressable by dot notation and 
immediately usable right out of the box, without any additional software 
requirements beyond Python and the PythonCard framework itself.  I'm not 
competent to code it (at this point), but here's my picture of implicit 
persistence:

Shelve is a memory friendly dictionary-like object that lives in a file, 
whose members can be any type of object.  So one simple approach to 
implicit persistence is for the Card class to bind selected properties of 
each Widget to a dictionary for that card, keyed by object name.  Store 
that dictionary in the Shelve object, keyed to the cardID.  Deal with card 
loading and unloading in the event dispatcher when generating openCard and 
closeCard messages.   Set the widget properties on load and get them on 
unload and the user gets free data persistence.  Make the card level 
dictionary available as "thisCard" via dot notation and you also have a 
dandy place for PythonCard developers to store arbitrary data structures 
they want persisted on a per card basis.

One of the joys of HyperCard was that it opened the door to countless 
neophyte programmers. Sure - it led to lots of "bad" programs in the 
traditional sense.  People abused the Card level storage mechanism in a 
variety of ways and stretched that environment to absurd levels.  But 
everyone starts out writing bad code.  HyperCard's highest achievement was 
allowing those newbies to get started.  I think PythonCard should keep them 
in mind first, without compromising the power or versatility available to 
experienced coders.

Peter

RE: [Pythoncard-users] Re: any feature requests?

[Kevin A. <al...@se...>]

> From: Peter Cleaveland
>
> What's the best candidate to provide the implicit card-level persistence
> HyperCard had?  Not to mention a place to store the code and resources,
> when we get to the point of having a PythonCard IDE.

I don't think we have a best candidate. What we discussed when the list
started was a generic card or record class that would support a variety of
backend data stores (repositories). The textIndexer sample uses ZODB. The
addresses sample uses a list of dictionaries. Neither of these samples has
been generalized for any app to use, but I plan to do a sample at some point
that builds on the resourceEditor and lets you create simple flat-file
databases as we explore our storage options. For metadata, dictionaries and
dbms work fairly well. Given the large amount of RAM available on most
machines today we might be able to use a model that keeps all of the
metadata and data for an application in memory, but writes changes out to
disk as they occur.

At a minimum, we would support getRecord/setRecord, getField/setField type
calls and some rudimentary searching and sorting framework against the
wrapper class. We'll need to provide dot notation access, regardless of the
underlying storage method. This means that applications that want to
optimize their data handling will still need to use SQL or ZODB directly in
order to get the best performance.

I encourage you and others to write your own samples exploring possible
storage methods, just keep in mind how any solution you try can be
generalized for a larger class of applications. Once we get through some
more of the direct GUI issues, I'll get back to this subject area myself.

> Shelve leaps to mind, but I'm not sure the DB files Shelve creates are
> portable across platforms.  Shelve also seems to create more than just a
> single file, which is non-optimal.

I don't know that multi-file is really a problem, the metadata and real data
can simply go into a sub-directory. In particular, artwork (MPEGs, WAVs,
MP3s, JPEGs, cursors, icons, fonts, etc.) are difficult or inefficient to
store as text, nor does it make sense to pickle that kind of data or stick
it into a database. For static data, we discussed using the zip support that
is part of the standard libraries to get the equivelant of a Java .jar/.war
(web archive) file. What we can do is write a wrapper class to handle
reading these resources so that they can be transparently retrieved from
either a zip or directory or URL without the user code worrying about which.

A critical difference between a PythonCard app and a normal GUI app should
be that users can expect to be able to make modifications to the original
application and that means making sure access to all the component parts is
relatively simple.

ka

Re: [Pythoncard-users] Re: any feature requests?

[Andy T. <an...@cr...>]

Peter Cleaveland wrote:
> This is fairly obvious as feature requests go - but I'm curious.
> 
> What's the best candidate to provide the implicit card-level persistence 
> HyperCard had?  Not to mention a place to store the code and resources, 
> when we get to the point of having a PythonCard IDE.

I'd like to address that as two separate issues. We are generally 
talking about two types of information to store here, 'metadata' about 
the application and the application's actual data.

Although HyperCard used to store the whole lot as one item I'm not sure 
its the best approach for PythonCard. As Kevin said in a post the other 
day we want to be able to edit the application 'metadata' (code and 
resource description) in a text editor to broaden the appeal of the 
toolset. We don't necessarily want to store the application data in a 
text form though as that may not be the most efficient solution.

In addition, the format and content of the actual application data is in 
the control of the developer and we should not constrain that in any 
way. I think we should support multiple back ends, and to that end we 
already have applications that support ZODB and MySQL. I'm currently 
working on a csv module and will also look at other RDBMS (Oracle and 
PostgreSQL are on my list). The developer of a PythonCard application 
should have the ability to choose where to store their data rather than 
us forcing a solution on them. Eventually we would want to support some 
kind of agnostic persistence layer (much like the approach AnyGui has 
taken to windowing toolkits) but we should wait until the framework and 
API have been worked out a bit more thoroughly.

Thats not to stop us planning such a persistence model now though ...

> 
> Shelve leaps to mind, but I'm not sure the DB files Shelve creates are 
> portable across platforms.  Shelve also seems to create more than just a 
> single file, which is non-optimal.

I haven't looked at shelve in any great detail, but it seems quite 
popular. I've got an item on my to-do list to change the addresses 
sample application to use pickle or shelve but if you want to step into 
the breach please feel free.

> 
> What we really want is the single-file clarity of cPickle, with the 
> memory friendly aspects of Shelve, in an efficient platform neutral 
> file.  Does anyone know of such a technology?
> 

Ah, the holy grail of storage technology. When we discover it can we 
sell it on to Oracle, IBM, et al? - only joking ;-)

My theory is to leave data storage to the data storage solutions, just 
as we are leaving GUI provision to the GUI toolkit. Please feel free to 
pitch in if you feel differently.

> Peter
> 
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can"

[Pythoncard-users] Re: any feature requests?

[Peter C. <pe...@pe...>]

This is fairly obvious as feature requests go - but I'm curious.

What's the best candidate to provide the implicit card-level persistence 
HyperCard had?  Not to mention a place to store the code and resources, 
when we get to the point of having a PythonCard IDE.

Shelve leaps to mind, but I'm not sure the DB files Shelve creates are 
portable across platforms.  Shelve also seems to create more than just a 
single file, which is non-optimal.

What we really want is the single-file clarity of cPickle, with the memory 
friendly aspects of Shelve, in an efficient platform neutral file.  Does 
anyone know of such a technology?

Peter

[Pythoncard-users] any feature requests?

[Kevin A. <al...@se...>]

I'm working on the Font class and will hopefully have that done by tomorrow
or Wednesday. It will be slightly different from the current release in
order to support the CSS style list such as: "'New Century Schoolbook',
'Times New Roman', 'Times', 'serif'"

Anyway, besides the ongoing need for documentation, sizers are the other
thing on my plate. However, sizers are going to take a lot more testing and
thought before they make it into a release, so I'm looking for other stuff
to play with on the side.

My two top choices right now are wrapping the wxPython wxListCtrl for
multi-column lists and wrapping up a basic double-buffered bitmap drawing
class.

The wxListCtrl is the simpler of the two, but the bitmap drawing would be
more useful for me right now. Does anyone have any other controls (widgets)
that they really need in order to do a sample? I don't plan on doing wxHTML
or the wxGrid until 2.3.2 is out, but somebody else is welcome to work on
those if they want.

I know there are lots of missing pieces to PythonCard right now, so if there
is something you really want to see sooner rather than later, speak up. You
can add your suggestion to the Feature Requests list:
http://sourceforge.net/tracker/?atid=369015&group_id=19015&func=browse

ka

RE: [Pythoncard-users] pycrustrc.py files

[Patrick K. O'B. <po...@or...>]

If you want to know what features are available in the shell, just go to the
shell and type "shell" followed by a dot -- "." -- and you'll see all kinds
of wonderful methods and properties in the autocomplete list. Here is one
that's kind of fun:

>>> shell.SetZoom(1)  # Make the shell text bigger...
>>> shell.SetZoom(2)  # and bigger...
>>> shell.SetZoom(3)  # and bigger...
>>> shell.SetZoom(4)  # and...
>>> shell.SetZoom(0)  # set it back to the default.

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Kevin
Altis
Sent: Sunday, September 09, 2001 9:19 PM
To: pythoncard-Users
Subject: [Pythoncard-users] pycrustrc.py files

<snip>

Patrick might have something to add to this description. It is a very useful
feature we've had almost since we started using PyCrust.

ka

RE: [Pythoncard-users] Message Watcher now uses sizers

[Kevin A. <al...@se...>]

> Just a note of warning, I got some strange error messages until I
> updated to the cvs version of PyCrust. Other than that, looking good.

Sorry about that. Patrick has been making tweaks to PyCrust as he approaches
a real release of version 0.6. The namespace setup changed after I put out
0.4.4.5.

We could put out a prototype-daily release using distutils and the current
version of PythonCardPrototype and PyCrust in cvs as a test today or
tomorrow.

ka

Re: [Pythoncard-users] Message Watcher now uses sizers

[Andy T. <an...@cr...>]

Kevin Altis wrote:
> Thanks to Robin, the Message Watcher window now uses sizers instead of a
> fixed layout. If you have access to cvs, please let me know if you see any
> problems; it seems to be fine on Windows, but I can't test on Linux...
> 
> ka
> 

Just a note of warning, I got some strange error messages until I 
updated to the cvs version of PyCrust. Other than that, looking good.

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

[Pythoncard-users] Save Configuration in Debug menu

[Kevin A. <al...@se...>]

I added a 'Save Configuration' menu option to the Debug menu. It writes out
a pythoncard.user.config.py file to the package directory with the current
config options. It will overwrite any existing pythoncard.user.config.py
file you already have.

It saves the position and size of the following windows:
Message Watcher
Namespace Viewer
Property Editor
Shell

If a debug window is visible when you choose Save Configuration, then that
debug will appear by default when you run PythonCard apps. For example, if
the Shell is visible when you choose Save Configuration, then the next time
you start an app, it will act as if you specified a -s command-line option.

If you prefer to not have any debug windows open by default, then set your
window positions and sizes, hide the windows, then choose Save
Configuration.

There is currently no option to disable logging while the app is running, so
until that is added, you'll manually have to change the option in the
pythoncard.user.config.py file just like you used to do.

ka