pythoncard-users Mailing List for PythonCard (Page 201)

Kevin Altis:
> > From: Jeff Griffith
> >
> > I just finished up the first round of app testing on Linux. Here are a
> > few screenshots I grabbed.
> >
> > http://www.people.hbs.edu/jgriffith/pythoncard/
>
> Wow, they don't look so good on Linux. I seem to remember problems like
that
> with Neil's original screenshots, but I can't seem to find those now.
 I put them back up - don't know why they got deleted:
http://pythoncard.sourceforge.net/snapminimal.png
http://pythoncard.sourceforge.net/snapproof.png
http://pythoncard.sourceforge.net/snapwidgets.png
> Either
> there aren't many Unix users trying PythonCard right now or they must just
> expect that kind of ugliness, because nobody has brought it up as a big
> issue. No wonder Unix folks always want to use sizers. It also shows that
I
> really need to preserve any -1 settings for size (width, height). I'll
have
> to figure out a clever way of doing that in the resourceEditor.
 The sizes of widgets and fonts and the visual appearance depends on which
GTK+ theme you are using. Therefore Jeff's screenshots look a lot different
to mine (he has chosen a theme similar to Motif and I chose one similar to
Windows) and as various parameters, such as font size, change other elements
need resizing. Explicitly setting fonts in your application is frowned upon
because you should be able to choose this in the GTK+ theme control panel
for global effect. Windows has similar features but they are used less often
and for smaller visual changes - few Windows users know how to change the
dialog font which causes many dialogs to display badly.
> Did you do an ascii or binary transfer? Unix folks please speak up so we
can
> address issues with line endings or anything else that I'm missing because
> I'm using Windows 2000. I got Unix out of my system a long time ago and
> don't plan on going back, so somebody else is gonna have to help here.
 Most Python code copes well with the extra \r characters but the resource
files don't so one thing that can be done is to explicitly replace all
'\r\n' with '\n' before evaling on Linux.
 Neil

Peter,
I forwarded your message to the PythonCard mailing list where others could
respond as well. Joining the mailing list would be the first thing to do.
Then you could start using PythonCard to create a simple application. That
will give you a chance to review the documentation and the system to see
what works for you and where we need to improve. Beyond that, Kevin and the
other folks might have other things with which they could use help.
Good luck. Be sure to let us know how you are coming along.
Pat
---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."
-----Original Message-----
From: nobody [mailto:no...@so...]On Behalf Of Peter Cleaveland
Sent: Friday, August 31, 2001 7:25 PM
To: po...@or...
Subject: PythonCard sounds great - how can I help
Hi,
My name is Peter Cleaveland. I got my start
programming HyperCard in 89 and loved it. I used
it for everything, including a now defunct
client/server app to manage Tandem mainframes
(using WindowScript and MitemView). It's too bad
the way Apple neglected it, and I read with
interest, recent suggestions to release it to the
open source community.
I'm just learning Python, and thought recently
that perhaps PythonCard might be a good idea. And
low and behold, I find I'm not the only one.
I'd love to join the project. How can I help?
Peter Cleaveland

Got another volunteer for you, Kevin.
---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."
-----Original Message-----
From: nobody [mailto:no...@so...]On Behalf Of Peter Cleaveland
Sent: Friday, August 31, 2001 7:25 PM
To: po...@or...
Subject: PythonCard sounds great - how can I help
Hi,
My name is Peter Cleaveland. I got my start
programming HyperCard in 89 and loved it. I used
it for everything, including a now defunct
client/server app to manage Tandem mainframes
(using WindowScript and MitemView). It's too bad
the way Apple neglected it, and I read with
interest, recent suggestions to release it to the
open source community.
I'm just learning Python, and thought recently
that perhaps PythonCard might be a good idea. And
low and behold, I find I'm not the only one.
I'd love to join the project. How can I help?
Peter Cleaveland

> From: Jeff Griffith
>
> I just finished up the first round of app testing on Linux. Here are a
> few screenshots I grabbed.
>
> http://www.people.hbs.edu/jgriffith/pythoncard/
Wow, they don't look so good on Linux. I seem to remember problems like that
with Neil's original screenshots, but I can't seem to find those now. Either
there aren't many Unix users trying PythonCard right now or they must just
expect that kind of ugliness, because nobody has brought it up as a big
issue. No wonder Unix folks always want to use sizers. It also shows that I
really need to preserve any -1 settings for size (width, height). I'll have
to figure out a clever way of doing that in the resourceEditor.
Your worldclock and widget screenshots show that the turning off the text
border isn't working either. The 'edit' button should be transparent. Are
these just not supported in GTK? If GTK support under wxWindows is really
limited, we are probably going to have to have platform-specific options and
appropriate warnings when those options are used in the .rsrc.py file or
code.
You don't need to do more screenshots, let's try and work through the
framework issues so that the current samples look good on Linux, Solaris,
etc. first. I need to do some sizer experiments, maybe next week after fonts
are resolved.
Anyone else with sizer experience or ideas in this area? I still favor
supporting multiple resource layouts identified by platform and default
language setting that would automatically be chosen when the app is started
so a layout could be tuned to Windows, Mac, Solaris, Linux, etc. but we will
still need sizers and anchors.
My major concern with sizers is that they are going to be conceptually
difficult for people to grasp. Alternatively, if what we really want is
something like HTML tables, then lets just go for that if that will solve
the problem. I don't know how you deal with whitespace in general with
sizers, most layouts I've seen look really amateurish because everything is
packed together. That is sort of at the other end of the spectrum from what
your screenshots show, which is that absolute positioning and sizing doesn't
fail gracefully. Anyway, this is a big and hard subject, so we need a lot of
discussion.
> One issue I ran into was the eval() statement had a hard time with the
> resource files. I think this is due to the windows to unix EOL
> differences. The files were unzipped on windows and ftp'd to Linux. I
> figured that would be enough to keep from running into the problem but I
> guess it wasn't.
Did you do an ascii or binary transfer? Unix folks please speak up so we can
address issues with line endings or anything else that I'm missing because
I'm using Windows 2000. I got Unix out of my system a long time ago and
don't plan on going back, so somebody else is gonna have to help here.
ka

I just finished up the first round of app testing on Linux. Here are a
few screenshots I grabbed.
 
http://www.people.hbs.edu/jgriffith/pythoncard/
One issue I ran into was the eval() statement had a hard time with the
resource files. I think this is due to the windows to unix EOL
differences. The files were unzipped on windows and ftp'd to Linux. I
figured that would be enough to keep from running into the problem but I
guess it wasn't.
I'll try to provide more screenshots as I dive deeper into
pythoncard-land.
Later
-Jeff Griffith

I like this samples launcher a lot. Makes testing the samples a breeze. Good
job, Kevin.
---
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: Friday, August 31, 2001 11:52 AM
To: pythoncard-Users
Subject: [Pythoncard-users] started work on a samples launcher app
I went ahead and started a samples launcher program
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/samples/samples.py
I only launches on Windows right now. Someone please provide the code for
launching on Unix. Also, I think people that are using Python 2.2 or
something other than 2.1.x need a way of specifying which Python interpreter
to use. Is there a good way of doing this?
If there is a readme.txt for a sample it displays that as the description,
so I'm going to add at least a minimal readme.txt to each sample that
doesn't already have one using the text from docs\samples.txt
ka
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
http://lists.sourceforge.net/lists/listinfo/pythoncard-users

> >Anyone want to volunteer to do the distutils setup for PythonCard?
>
> That if what I was wanting to do. But I can't at this time :-(
> Distutils are quite easy when no compilation required.
> If you want, I could try to do it next week?
>
> Sincerely yours, Roman Suzi
That would be great! RPMs for Linux, a binary installer for win32, whatever
for Solaris and eventually a Mac version. The Mac wxPython port looked like
it was coming along nicely earlier this week, but I haven't heard whether
anyone got the final "5%" done that would make it actually work.
Of course, we'll need a distutils for PyCrust as well, but that should be
even simpler.
ka

Perhaps he meant a distutils package?
---
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: Friday, August 31, 2001 12:05 PM
To: pyt...@li...
Subject: RE: [Pythoncard-users] FW: PythonCard feedback
> I do not have latest PythonCard checkedout,
> but for the sake of structure it is better to make
> a package of it.
PythonCardPrototype has been a package since release 0.3, which version are
you using?
ka
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
http://lists.sourceforge.net/lists/listinfo/pythoncard-users

The samples launcher (samples.py) seems to be working fine on Windows, but I
can't test it on Unix, so I don't know if the os.spawnv code below is
correct. If someone in Unix land can confirm that it works or provide a
better solution that would be great.
samples.py, samples.rsrc.py, and the readme.txt are at:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/samples/
 def on_btnLaunch_mouseClick(self, menu, event):
 name = self.components.listSamples.selected
 path = name
 name = name + '.py'
 args = self.getCommandLineArgs()
 if sys.platform[:3]=='win':
 # this only works on Windows
 os.popen('start ' + os.path.join(path, name) + args)
 else:
 args = ['python', os.path.join(path, name)] + args.split()
 os.spawnv(os.P_DETACH, 'python', args)
Once this issue is solved, I'll go ahead and do a 0.4.4.1 release that
contains the samples launcher.
ka

On 2001年8月31日, Kevin Altis wrote:
>Anyone want to volunteer to do the distutils setup for PythonCard?
That if what I was wanting to do. But I can't at this time :-(
Distutils are quite easy when no compilation required.
If you want, I could try to do it next week?
Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Friday, August 31, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "CURSOR: What you become when your system crashes." _/

I've updated the sample names to match their directory names. The older
names were from the days before we we're using packages and had to be
different in order to avoid name collisions in some cases.
'test_sounds' -> 'sounds'
'test_dialogs' -> 'dialogs'
'tic' -> 'tictactoe'
'test_widgets' -> 'widgets'
'test_turtle' -> 'turtle'
ka

I went ahead and started a samples launcher program
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/samples/samples.py
I only launches on Windows right now. Someone please provide the code for
launching on Unix. Also, I think people that are using Python 2.2 or
something other than 2.1.x need a way of specifying which Python interpreter
to use. Is there a good way of doing this?
If there is a readme.txt for a sample it displays that as the description,
so I'm going to add at least a minimal readme.txt to each sample that
doesn't already have one using the text from docs\samples.txt
ka

> I do not have latest PythonCard checkedout,
> but for the sake of structure it is better to make
> a package of it.
PythonCardPrototype has been a package since release 0.3, which version are
you using?
ka

On 2001年8月31日, Kevin Altis wrote:
I do not have latest PythonCard checkedout,
but for the sake of structure it is better to make
a package of it.
I will try to do it too. What do you think, Kevin?
Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Friday, August 31, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "CURSOR: What you become when your system crashes." _/

> From: Guido van Rossum
>
> The Unix instructions are a bit misleading (am I correct that you
> don't use Unix much? :-). Moving the files to "your python21
> directory" makes no sense, they should be moved into
> <prefix>/lib/python2.1/site-packages/ where <prefix> defaults to
> /usr/local (but may be /usr/bin when Python came as part of your Linux
> distribution).
>
> I *highly* recommend that for the next release you study distutils and
> use it to do the installation -- it takes care of the Unix details
> too.
>
> Referring to "double-clicking" samples also reveals your Windows
> bias. :-)
Okay, the man has spoken. Will some *nix user please provide the complete
text required for the installation based on what is at:
http://pythoncard.sourceforge.net/getting_started.html
Also, what is the appropriate terminology for running a program in *nix from
the GUI interface? Surely, you don't have to run Python programs from the
command-line?
Anyone want to volunteer to do the distutils setup for PythonCard?
> (It would be cool if there was a meta-sample that presented a GUI to
> run any of the other samples, optionally specifying the command line
> options, and with an option to view the source of each sample. Have
> you seen the wxPython demo? Very slick!)
Anyone up for doing this? The programs need to be launched as their own
independent program/process, so you probably need to use os.spawnv() on
Windows (though 'start' may also work), and os.fork() or os.execv() on *nix.
The 'Launcher.py' program in Mark Lutz's Programming Python 2nd Edition
shows how to do this and I'm sure there are similar examples elsewhere.
ka

-----Original Message-----
From: gu...@cj...
[mailto:gu...@cj...]On Behalf Of Guido van
Rossum
Sent: Friday, August 31, 2001 6:03 AM
To: Kevin Altis
Subject: Re: PythonCard feedback
> http://pythoncard.sourceforge.net/getting_started.html
The Unix instructions are a bit misleading (am I correct that you
don't use Unix much? :-). Moving the files to "your python21
directory" makes no sense, they should be moved into
<prefix>/lib/python2.1/site-packages/ where <prefix> defaults to
/usr/local (but may be /usr/bin when Python came as part of your Linux
distribution).
I *highly* recommend that for the next release you study distutils and
use it to do the installation -- it takes care of the Unix details
too.
Referring to "double-clicking" samples also reveals your Windows
bias. :-)
Please add more complete descriptions to the list of samples. (You
can save some space by not pretending to show a directory structure.)
It would be helpful if the .py file to start a sample was always the
same name as the directory name, *or* if it was always the same
(e.g. "start.py" or "main.py"). As it is, you sometimes have a test_
prefix and you sometimes have a shorter name (tictactoe/tic.py). (I
liked the latter -- though some of the images appeared to leave a
think horizontal black line at the bottom after being erased, possibly
an off-by-one error in your code, possibly in wxPython.)
In the section about command line options, you should probably begin
by mentioning that when you start any of the samples, some standard
command line options are accepted.
(It would be cool if there was a meta-sample that presented a GUI to
run any of the other samples, optionally specifying the command line
options, and with an option to view the source of each sample. Have
you seen the wxPython demo? Very slick!)
The worldclock sample is cool; it may be easier to understand if you
dropped the references to JS and history.
The next thing beyond getting started would be a look at a simple
example that shows what each piece of boilerplate does, and how you
can vary them.
--Guido van Rossum (home page: http://www.python.org/~guido/)

PythonCard is a software construction kit (in the spirit of Apple's
HyperCard) written in Python.
You can download the latest release at:
http://sourceforge.net/project/showfiles.php?group_id=19015
Samples included in the latest release: addresses, conversions, dbBrowser,
dialogs, findfiles, minimal, proof, resourceEditor, searchexplorer, sounds,
SourceForgeTracker, textIndexer, tictactoe, turtle, widgets, worldclock
To see screenshots of some of the samples, visit:
http://pythoncard.sourceforge.net/samples.html
A description of each sample is included in the docs directory.
PythonCard home page
http://pythoncard.sourceforge.net/
SourceForge summary page
http://sourceforge.net/projects/pythoncard/
Mailing list
http://lists.sourceforge.net/lists/listinfo/pythoncard-users
PythonCard requires Python 2.1.x or later and wxPython 2.3.x. wxPython is
available at http://www.wxpython.org/
PythonCard relies on wxPython, it will support the Macintosh once wxPython
has been ported to the Mac.
PyCrust 0.6
PyCrust by Patrick K. O'Brien is included as part of the PythonCardPrototype
releases. If you would like to find our more about PyCrust or get a separate
distribution, please visit the home page at
http://sourceforge.net/projects/pycrust/
----------------------------
Changes since release 0.4.3 (2001年08月23日):
Release 0.4.4 2001年08月30日
added getting_started.html to docs\html
added basic status bar support
 statusbar.py module
 see test_turtle.py for an example
turtle sample updated
 test_turtle.py now uses a status bar and displays the
 time required to draw a design
 added line(x1, y1, x2, y2) method to turtle
added extra parametes to FileDialog to support saving files
 see resourceEditor for an example
 see dialog.py for complete list of options
added Namespace Viewer using PyFilling (part of PyCrust 0.6)
fixed numerous Property Editor edit/display bugs
 widgets are now displayed in the proper order
added Font support to all widgets
 Font class moved to font.py module
 the actual text descriptions of the fonts is going to
 change, so if you use them, just be aware that the format
 of the font descriptions will change by the next release
 a font can be passed to the Font dialog to set the initial
 font displayed
commented out 'import warnings' for Python 2.0 support
 but PyCrust usage still means that you need Python 2.1.x
 if any Debug windows like the shell will be used
fixed unitialized empty bitmaps on win98
added append method to Choice class
added setFocus method to Widget
dbBrowser sample updated to version 0.2
resourceEditor changes
 resourceEditor can now save .rsrc.py files
 make sure to only work on copies in case of bugs
 also some hand editing of .rsrc.py is still necessary
 depending on what you're trying to do
 Duplicate Widget menu item now causes the duplicate to
 be offset 10 pixels so it can be selected to select
 added template.rsrc.py for defaults
worldclock sample demonstrates simple use of logging

The first draft is now live at
http://pythoncard.sourceforge.net/getting_started.html
This is basically what I sent in email earlier today with lame HTML
formatting. Feel free to make corrections and suggestions on content and
layout, but please provide HTML fixes if you think it can be formatted
better.
ka
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Thursday, August 30, 2001 10:21 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] adding a Getting Started document
>
>
> A number of emails I've received today have prompted me to do a Getting
> Started document for PythonCard. It should have been done long ago, but
> documenation is the hardest part and I'm lazy, so...
>
> Anyway, I will probably post a first draft later today, but feel free to
> respond to this message with any points you think should be covered, your
> own experiences, or any other contributions you want to make to
> the Getting
> Started.
>
> Thanks,
>
> ka
> ---
> Kevin Altis
> al...@se...
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Cool.
The Bitmap class in widget.py might have to be refactored to support what
you are working on, but then again maybe not. Bitmap should probably be put
into its own module file along with other bitmap and image manipulation
functions and classes. We can do this as you get closer. Remember that for
the most part the wxPython objects are hidden inside our own classes,
typically they are the _delegate attribute in a class. That will impact
pickling something like a Bitmap, which you probably don't want to do.
The file extension is used to automatically determine the file type right
now.
We can extend the current resource format to support other "globals" such as
what you're describing, so they could be automatically loaded and available
in an image list or dictionary.
ka
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Jeff
> Griffith
> Sent: Thursday, August 30, 2001 12:42 PM
> To: pyt...@li...
> Subject: [Pythoncard-users] Icon Packs
>
>
>
> I've decided to begin work on 'icon packs' for the pythoncard project.
> If you look through the source code for the wxPython demo, you'll notice
> some of the images are embedded in the code. They use a combination of
> zlib and pickle to accomplish this. I've already started work on a
> script that will store images in .py files. This would allow icons to
> be imported into your projects instead of loaded off the filesystem.
>
> ... here is a pretend python session
>
> >>> from icons.gtk import *
> >>> saveas_icon
> <object wx_image>
> >>> open_icon
> <object wx_image>
>
> This would also ease the distribution of pythoncards if most all the
> deliverables are .py files that py2exe could easily pack.
>
> I'll keep you guys uptodate on its progress.
>
> Thanks
> -Jeff Griffith

I've decided to begin work on 'icon packs' for the pythoncard project. 
If you look through the source code for the wxPython demo, you'll notice
some of the images are embedded in the code. They use a combination of
zlib and pickle to accomplish this. I've already started work on a
script that will store images in .py files. This would allow icons to
be imported into your projects instead of loaded off the filesystem. 
... here is a pretend python session
>>> from icons.gtk import *
>>> saveas_icon
<object wx_image>
>>> open_icon
<object wx_image>
This would also ease the distribution of pythoncards if most all the
deliverables are .py files that py2exe could easily pack.
I'll keep you guys uptodate on its progress.
Thanks
-Jeff Griffith

This post to edu-sig seems like a good start. Comment at will.
ka
-----Original Message-----
From: edu...@py... [mailto:edu...@py...]On
Behalf Of Kevin Altis
Sent: Thursday, August 30, 2001 11:50 AM
To: ed...@py...
Subject: RE: [Edu-sig] would you use PythonCard?
> From: Jason Cunliffe
>
> Your post prompted me to check out PythonCard.
> Downloaded it to Win89se syetem with Python 2.1 installed.
You'll also need wxPython for Python 2.1 http://www.wxpython.org/
The pre-built binaries are at:
http://www.wxpython.org/download.php#binaries
> Took a summer break from computers recently, so I'm probably
> being very dumb
> but cannot find any 'getting started' instructions anywhere.
There aren't any docs other than what is in the docs directory, I'm working
on them, so I'll use this opportunity to create some 'content' for the first
draft Getting Started document.
> How do I start PythonCard?
> Do / Can / Should I run it from PythonWin, IDLE or Pycrust?
> What are the first 10 things to do to get it up and running?
Assuming Python 2.1 and wxPython are installed and running correctly, you
need to move the PyCrust and PythonCardPrototype package directories to your
python21 directory. If you want, you can move the 'samples' directory to a
more convenient place.
The only thing you run are the standalone samples or a sample you write
yourself. All you have to do is double-click one of the .py files like
'samples\minimal\minimal.py'. You can also run the files from the
command-line, and the command-line is probably preferred if you want to
invoke one of the debug windows (see below) with the program. The one thing
you should not do is run a sample from within PythonWin or IDLE since
neither of those IDEs launches an app in a separate process, so you'll run
into GUI contention issues. You can launch from an IDE like Komodo. What I
typically do is edit in PythonWin and keep a shell window (DOS prompt) open
to run the program once I make an edit change; alternatively keep a shortcut
to the program or an Explorer window open to the directory the program is in
so you can double-click it. Sometime in the future, there will be a
PythonCard environment that allows you to edit scripts and run.
The files ending in '.rsrc.py' are the resource files and are not runnable
themselves. There is a description of each sample in samples.txt of the docs
directory. The following files are standalone samples (directory structure
shown):
samples
 addresses
 addresses.py
 conversions
 conversions.py
 dbBrowser
 dbBrowser.py
 This sample requires mySQL to be installed and running.
 dialogs
 test_dialogs.py
 findfiles
 findfiles.py
 minimal
 minimal.py
 You should copy the minimal folder when you're ready to start
 your own PythonCard program. See the tutorial.txt file in the
 docs directory for more information.
 proof
 proof.py
 resourceEditor
 resourceEditor.py
 This is the GUI editor for resource files. Release 0.4.3 doesn't
 support saving files, but you can open any .rsrc.py file, add
 widgets, delete, move and resize, and duplicate widgets. The
 Property Editor window is used to change attributes of each widget
 such as the backgroundColor.
 searchexplorer
 searchexplorer.py
 sounds
 test_sounds.py
 SourceForgeTracker
 SourceForgeTracker.py
 textIndexer
 textIndexer.py
 This sample requires either Zope or standalone ZODB to
 be installed.
 tictactoe
 tic.py
 turtle
 test_turtle.py
 widgets
 test_widgets.py
 worldclock
 worldclock.py
You can change the .py extension to .pyw on any of the samples if you want
to get rid of the console window that pops up when you run the program.
Command-line options
Valid command-line options are: -m (Message Watcher), -p (Property
Editor), -s (Shell) and in cvs -n (Namespace Viewer); the Namespace Viewer
is in cvs, but not in a release version yet. Invoking any of those options
will actually give you all of them and then you can hide/show any of the
windows via the Debug menu.
You can set the default position and size of each window and whether it
appears by default by copying the 'pythoncard.config.py' file in the
PythonCardPrototype directory and renaming the copy to
'pythoncard.user.config.py' This is what mine looks like:
{ 'gui':'wxPython',
 'logfile':'pythoncard.log',
 'showMessageWatcher':0,
 'messageWatcherPosition':(900, 0),
 'messageWatcherSize':(200, 300),
 'messageWatcherVisible':1,
 'showPropertyEditor':0,
 'propertyEditorPosition':(750, 350),
 'propertyEditorSize':(360, 240),
 'propertyEditorVisible':1,
 'showShell':0,
 'shellPosition':(50, 600),
 'shellSize':(700, 230),
 'shellVisible':1,
 'showNamespace':0,
 'namespacePosition':(0, 0),
 'namespaceSize':(800, 300),
 'namespaceVisible':1,
 'defaultStackPosition':(5, 5),
 'enableLogging':0
}
I don't have any of the windows enabled by default since I use several of
the samples all day long (worldclock, searchexplorer, and
SourceForgeTracker) and don't want a debug menu or debug windows for them. I
run a sample from the shell when I want debug windows.
> anyone I think. What level of programming experience do you think
> PythonCard
> is good for?
If someone is up for Python, I don't think PythonCard takes much more
effort, less if you think of the pain of doing command-line input/output. It
is mostly a matter of copy and paste and following some coding conventions,
which we're in the process of documenting. You don't have to worry about
event tables, id bindings, window handles, pack, etc. At this point, the
widget set is much more limited than if you programmed wxPython directly,
but we're closing the gap each day.
> Myself I love Pthon and much more besides, but still find it very
> frustrating installing and running Python packages. Anything you can do to
> enhance this aspect of PythonCard is for the good I am sure. Meanwhile I
> signed up to the PythonCard mailing list and will do some more homework,
> browse the archives etc.
We've debated back and forth on the installation issue. On one hand, we
should support dist-utils, but we also need to make it so that you just
double-click and run a normal installer since requiring the user to type
'setup install' defeats part of the purpose. Since we're at the prototype
stage, that's a bit much for releases that happen every few days. For now,
you just drop the directories into your python21 directory and you're set.
> Thanks in advance any help
> - Jason
Thanks a lot, keep the questions coming. I'm going to work on the Getting
Started and post to the pythoncard-users mailing list later today.
ka
_______________________________________________
Edu-sig mailing list
Ed...@py...
http://mail.python.org/mailman/listinfo/edu-sig

A number of emails I've received today have prompted me to do a Getting
Started document for PythonCard. It should have been done long ago, but
documenation is the hardest part and I'm lazy, so...
Anyway, I will probably post a first draft later today, but feel free to
respond to this message with any points you think should be covered, your
own experiences, or any other contributions you want to make to the Getting
Started.
Thanks,
ka
---
Kevin Altis
al...@se...

If you want a simple statusBar, you can now just put 'statusBar':1 in your
resource stack description. For example, here's minimal.rsrc.py with a
statusBar
{ 'stack':{ 'type':'Stack',
 'name':'Minimal',
 'title':'Minimal PythonCard Application',
 'size':( 200, 100 ),
 'statusBar':1,
The statusBar is part of the height of the window, so you'll probably have
to increase your window height if you decide to add one.
I put the StatusBar class in a separate file in anticipation of someday
having a much more elaborate class that supports various widgets like a
background, but that you won't have to manage yourself. For now, it is
braindead simple, all you can do is get and set the text. Here's a few lines
in the shell using the modified minimal.rsrc.py file.
>>> bg.statusBar.text = 'hello statusBar'
>>> bg.statusBar.text
'hello statusBar'
Due to a bug in the resourceEditor, if you open a .rsrc.py file that has a
'statusBar':1 then you'll have to quit the resourceEditor before opening a
.rsrc.py that doesn't have one defined. I have a question into Robin to find
out how to dynamically delete the status bar and when I get an answer I'll
fix it and update what's in cvs.
ka

Kevin Altis:
> Okay, but I still need to know what you're proposing, so I can implement
it.
 I'm not really proposing anything particular as I'm somewhat unsure here
and even managed to guess wrong about "light" being implemented. Just
raising issues.
> I still don't know whether underline works on *nix or just Windows.
 Underlined fonts aren't supported directly by X or GTK+ IIRC. Scintilla
uses explicit underline drawing to avoid relying upon the platform to
implement this as part of text drawing.
 Neil

> From: Jeff Griffith
>
> I can't take it anymore. I'm dying to find a way to become involved.
Excellent. Any and every contribution is good at this point. Got any
specialty areas or particular interests?
> This afternoon I began working on documenting all the widget
> attributes and
> event triggers. My initial plan was to code a single widget and show in
> very simple terms what the code would look like if you wanted to handle
> events triggered by that widget.
That sounds good. Even unfinished documentation is worth posting and then we
can modify and clean it up.
> While attempting this, I was still pretty unfamiliar with how to build
> python cards. I spent 15 minutes feeling my way around the applications,
> trying things out within PyCrust.
>
> What happened next I didn't expect. Within those first 15
> minutes I reached
> that historically elusive "aha" moment. I was stunned at how intuitive
> programming for pythoncard was. The Message Watcher window along with the
> Resource Editor get the credit for making it so obvious how to code cards.
Sweet!
> So now I have no desire to document every widget event and attribute. Its
> just too obvious how everything is put together.
Well everyone has a different aha threshold, but I think most people just
have apprehension about something new, so we just need something to kick
start it for everyone else.
> So here is my question, are there any special requests of the developers.
> Can you think of anything that would be nice to have any ol'
> average joe do?
>
> Documentation, run tests, make graphics, order pizza, mow your lawn? feed
> the cat? Anything?!?!
Andy thinks we need a logo, but I don't subscribe to the school of "print
the t-shirts, announce the product, take the orders, design the product..."
;-) If someone ever does a logo, please no SNAKES, I would rather have John
Cleese's bald spot as a logo!
But seriously, we need to do docs, tutorials, screen shots, and lots of
samples stressing the framework to point out what needs to be added,
changed, or just plain thrown out. Just ask lots of questions (there are no
dumb questions at this point), someone will provide answers, then we'll wrap
it up as FAQs and DOCs.
ka