pythoncard-users

[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

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"

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?'" _/