pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] Linux and PythonCard, there will be a 0.6.3 release soon

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

First of all, ARGH!

Second of all this isn't going to have much impact, if any on Windows users,
but it will impact Linux users, so if you use Linux and are trying out
PythonCardPrototype 0.6.2 be aware that I am working to fix problems and
will do a release by early next week at the latest. I already made the
change to cvs that is described below. Again, if you're a Windows user,
there is nothing wrong with 0.6.2, go ahead and download it and use it.

Cliff Wells and I spent some time in front of a Linux box tonight testing
PythonCard. This is the first time since Rowland and I started the prototype
work back in July that I sat down with PythonCard running under Linux/GTK.
I'm normally a Windows 2000 user and I also have Windows 98 and NT 4 to test
against here at home.

My tests tonight revealed many small problems I was unaware of since nobody
had reported them. The most glaring is a really bad mistake I made with
CaptureMouse() in the resourceEditor. If you're using Linux, delete lines
577 and 578 (the lines commented out below) from resourceEditor.py in
release 0.6.2. I've already updated cvs.

    def on_mouseDown(self, target, event):
        if target.name not in self.sizingHandleNames:
            self.startName = target.name
            if self.stack.app.pw != None:
                self.stack.app.pw.selectComponentsList(target.name,
str(target.__class__.__name__))
            self.hideSizingHandles()
            #if wx.wxPlatform != '__WXMSW__':
            #    target._delegate.CaptureMouse()
        else:
            if wx.wxPlatform == '__WXMSW__':
                self.hideSizingHandles()
            else:
                self.gtkHideSizingHandles(target.name)
                target._delegate.CaptureMouse()

        self.startPosition = self.components[self.startName].position
        self.startSize = self.components[self.startName].size
        self.offset = event.GetPosition()


Cliff and I identified other issues that I'll fix in cvs over the next few
days. These include some GTK assert errors in samples using BitmapCanvas,
path issues, and font problems with TextField (wxTextCtrl). If you are using
PythonCard under Linux I would appreciate bug reports for anything that
throws an exception or just doesn't work as you would expect it to.

Apologies to all those that downloaded 0.6.2 for Linux.

ka

Re: [Pythoncard-users] Re: Possible Project Names

[Magnus L. H. <ma...@he...>]

David LeBlanc <wh...@oz...>:
>
> PyBorg - you _will_ be assimilated ;-)
 
PyberSpace? PyberPunk?

> Dave LeBlanc

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

[Pythoncard-users] Re: Possible Project Names

[David L. <wh...@oz...>]

PyBorg - you _will_ be assimilated ;-)

Dave LeBlanc

Re: [Pythoncard-users] possible project names

[Magnus L. H. <ma...@he...>]

Dan Shafer <da...@gu...>:
[...]
> Holy Grail.
> 
> OK, you hate that?

"Grail" is taken by the grail project, of course.

> How about the fact that this program helps you 
> create UIs and applications in Python and call it:
> 
> Python's Own Terrific, Trenddy User Interface (POTTUI...which has 
> lots of interesting twists.)

Sounds like spitting, doesn't it?

> Yeah, I know. Pretty bad. Gimme a break. This isn't easy, ya know!
> 
> I suppose it would be presumption of the first rank for us to pre-empt:
> 
> Sensational Python Application Machine (ahem)

How about: "The Machine that goes 'Ping!'"

> Alright, alright. Now I'll get serious.
[...]
> At the end of it all, I find I still prefer PythonCard.

Yes, yes, yes!

I guess I must have missed the beginning of this discussion, but can
someone please sum up (preferrably in a sentence or two) why we
wouldn't want to use that name? IMO it has a lot going for it...

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

RE: [Pythoncard-users] initial object model

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

One clarification: This is framework stuff and doesn't impact user code
(samples) yet, except for the tictactoe sample, specifically the
playfieldButton method which needs to know the type of the button clicked.
If you aren't interested in the what, how and why of the framework then this
is one of those messages you can safely ignore. :)

The changes below have already been checked into cvs. In addition to further
refining the component model, I have some definite goals for the next
release (probably 0.7) that I will describe in another message.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> Rowland Smith
> Sent: Thursday, January 17, 2002 1:53 PM
> To: pyt...@li...
> Subject: [Pythoncard-users] initial object model
>
>
> PythonCard has been modified to include some of the basic trappings of a
> component object model.
>
> Probably the major goal of the component model is to support the
> development of a visual gui building tool where simple and compound
> components, both built in and third party, can be layed out in a panel
> and wired together using events and attributes to create a non-trivial
> application.
>
> Current state of the art
>
> 1. A meta model for describing the events and attributes of a component.
>
> This meta model is based on a the pom.ComponentSpec class, that contains
> objects that describe each event that a component generates, and each
> attribute that a component supports.  Currently, attributes do not
> contain type information ( i.e. list, string, etc ) - we still need to
> discuss how we want to define the attribute types.  One thing typing
> will allow us to do is create smart gui editors that can be used by a
> gui builder for editing simple and compound/custom components.
>
> 2. Access to a component's meta model from a component instance via
> the pom.ComponentInspector class.
>
> 3. Each subclass of Event is now required to define a class variable
> 'name', that contains the handler-specific name of the Event.  This is
> the name that is used to represent the Event in user code.  For example,
> MouseClickEvent.name = 'mouseClick'.
>
> 3. A component registry ( registry.ComponentRegistry ) that contains an
> entry for each component and provides access to the component's
> meta model.
>
>     Example:
>
>     reggie = registry.getRegistry()
>     spec = reggie.getComponentSpec( 'Button' )
>
> The ComponentRegistry will be used mainly by any gui editors that want
> to know what events and attributes a component supports.
>
> NOTE: The variable in widget.py, WidgetRegistry, has been replaced by
> the class component.ComponentRegistry.  Any code using WidgetRegistry
> will break, and needs to be updated.
>
>
> The Future?:
>
> 1. An entry in Spec for a custom component editor class.
>
> 2. An entry in Spec for a path to the image that will be used as an icon
> in a gui builder.
>
> I'm not a component expert, and I don't play one on TV, so I'm sure
> there are plenty of component model aspects missing.  Please jump in and
> contribute if you can.
>
> Talk to ya,
> Rowland
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] initial object model

[Rowland S. <ro...@we...>]

PythonCard has been modified to include some of the basic trappings of a 
component object model.

Probably the major goal of the component model is to support the 
development of a visual gui building tool where simple and compound 
components, both built in and third party, can be layed out in a panel 
and wired together using events and attributes to create a non-trivial 
application.

Current state of the art

1. A meta model for describing the events and attributes of a component.

This meta model is based on a the pom.ComponentSpec class, that contains 
objects that describe each event that a component generates, and each 
attribute that a component supports.  Currently, attributes do not 
contain type information ( i.e. list, string, etc ) - we still need to 
discuss how we want to define the attribute types.  One thing typing 
will allow us to do is create smart gui editors that can be used by a 
gui builder for editing simple and compound/custom components.

2. Access to a component's meta model from a component instance via 
the pom.ComponentInspector class.

3. Each subclass of Event is now required to define a class variable 
'name', that contains the handler-specific name of the Event.  This is 
the name that is used to represent the Event in user code.  For example, 
MouseClickEvent.name = 'mouseClick'.

3. A component registry ( registry.ComponentRegistry ) that contains an 
entry for each component and provides access to the component's meta model.

    Example:

    reggie = registry.getRegistry()
    spec = reggie.getComponentSpec( 'Button' )

The ComponentRegistry will be used mainly by any gui editors that want 
to know what events and attributes a component supports.

NOTE: The variable in widget.py, WidgetRegistry, has been replaced by 
the class component.ComponentRegistry.  Any code using WidgetRegistry 
will break, and needs to be updated.


The Future?:

1. An entry in Spec for a custom component editor class.

2. An entry in Spec for a path to the image that will be used as an icon 
in a gui builder.

I'm not a component expert, and I don't play one on TV, so I'm sure 
there are plenty of component model aspects missing.  Please jump in and 
contribute if you can.

Talk to ya,
Rowland

RE: [Pythoncard-users] possible project names

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

> From: Dan Shafer
>
> Snake Oil (greases the skids of Python development)

This I like sort of like.

from dictionary.com - via the searchexplorer sample:
http://www.dictionary.com/cgi-bin/dict.pl?term=snake+oil

"snake oil
n.
A worthless preparation fraudulently peddled as a cure for many ills.
Speech or writing intended to deceive; humbug.

snake oil n : any of various liquids sold as medicine (as by a travelling
medicine show) but medically worthless"

> At the end of it all, I find I still prefer PythonCard. And I think
> PythonCard gives us a wonderful target at which to aim. In the
> interim, however, we may want to release other products that are
> intermediate in nature, the building blocks of what will ultimately
> be PythonCard.

Me too, I'm still in the PythonCard camp. I think we are about ready for a
vote, but I'll give these naming threads a day more before asking people to
email me directly with their vote. I'll tally them up and post the result to
the list. Then we can have a name and put this issue behind us.

ka

Re: [Pythoncard-users] possible project names

[Dan S. <da...@gu...>]

OK, when I'm helping clients name things, a technique I often use is 
to start with the idea that the name of a company or product ought to 
ring out with a clear (if not necessarily complete) description of 
what the thing _is_.

And at the same time, a thing as whimsical as Python (in nomenclature 
only) encourages its spinoffs and supporting cast to be equally 
whimsical, no?

OK, so bear with me.

What is a term used to mean "the ultimate and perhaps almost 
unattainable goal of a particular group or clan?" And what movie did 
Monty Python make that had an identical name?

Holy Grail.

OK, you hate that? How about the fact that this program helps you 
create UIs and applications in Python and call it:

Python's Own Terrific, Trenddy User Interface (POTTUI...which has 
lots of interesting twists.)

Yeah, I know. Pretty bad. Gimme a break. This isn't easy, ya know!

I suppose it would be presumption of the first rank for us to pre-empt:

Sensational Python Application Machine (ahem)

Alright, alright. Now I'll get serious.

I'm going to assume that a certain amount of irreverence is OK here, 
that we don't expect Blue Suits to buy into this cool stuff anyway, 
that we're building this for other people who are either like us or 
wannabe. (Come to think of it, I'm not sure which of those categories 
_I_ belong in!)

Snake Oil (greases the skids of Python development)
Making Python Fully Creative (MPFC - get it?)
BrainFile (rearranging letters in Life of Brian)
Visual Python (vPython) - suffers from a too-close link to VB?
PIE (Python Interface Editor)

At the end of it all, I find I still prefer PythonCard. And I think 
PythonCard gives us a wonderful target at which to aim. In the 
interim, however, we may want to release other products that are 
intermediate in nature, the building blocks of what will ultimately 
be PythonCard.

I'm working on another note, which I may finish tonight at least 
sufficiently to risk pushing it out via this list, that describes in 
non-technical terms what about HyperCard I think is so immensely 
worth preserving in our new endeavor.

And for my part, while I'm delighted to contribute where I can to the 
intermediate product development -- and irrespective of our final 
naming decision -- I am ultimately drawn to this effort by the 
tantalizing notion of being able to do HyperCard better than anyone 
has done it.
-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

Re: [Pythoncard-users] possible project names

[Magnus L. H. <ma...@he...>]

Kevin Altis <al...@se...>:
>
> Charmer
>   Personally I don't like the snake motif often used for Python, but when
> life gives you lemons, make lemonade.
> 
> If nothing else, these name threads (there is another on pythonmac-sig) make
> me appreciate the PythonCard name more; HyperCard will always be in my
> thoughts even if the name does change.
 
Go PythonCard!

> ka

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

[Pythoncard-users] Dan Shafer's PythonCard tutorial

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

I wanted to share the tutorial Dan Shafer wrote for the counter sample (he
created the sample too), which is included in release 0.6.2. A big thanks to
Dan for getting involved in PythonCard and producing this tutorial so
quickly!

ka
ps. I did some last minute edits to all of the files, so if you spot any
errors, please report them.
---
readme.txt:

This is a simple tutorial application showing you how to create a fairly
minimal application in PythonCard which nonetheless has button and
menu interaction.

My thanks to Kevin Altis for his help and support.

To run the sample, just double-click on the counter.py icon. The file
"tutorial.txt" contains step-by-step instructions for recreating the
counter example.

Contributed to the PythonCard community 1/16/02 by Dan Shafer

No rights reserved. Have at it!

---
tutorial.txt:

Basic Counter Tutorial
===================

by Dan Shafer (da...@da...)

Purpose:

Over the years as I've played with various GUI tools and development
environments, I have traditionally created a simple counter application as a
way of getting familiar with the tool's basic operation and gaining some
nodding acquaintance with its language and architecture/API. When PythonCard
appeared in my life courtesy of my old colleague Kevin Altis, I decided that
I should do the same.

Kevin encouraged me to document my efforts and this is the result.

This document walks you step by step through the process of creating an
intentionally simplistic PythonCard application. I don't claim that this is
the best way to accomplish this objective, let alone the only one. It just
happens to be the way I approached it. At the end of this tutorial, I will
make a few observations about other things that I could have done that would
make the example more instructive or interesting.

Note that this tutorial describes how this process is handled in
PythonCardPrototype 0.6.2. Continuing enhancements to the UI, especially in
the resourceEditor, will make the process more and more streamlined over
time. I'll try to keep this tutorial up to date as that happens.

The Application:

This simple application consists of three buttons and a text field. The text
field holds a numeric value (represented as a string) which is manipulated
by the three buttons. The buttons add 1 to the current value displayed in
the field, subtract 1 from that field, and reset the field's value to 0.

The Application Creation Process

Creating an application in PythonCard begins with the creation of a basic
structure. There are two ways to do this. One is to use the PyCard (I refuse
to use the abbreviation 'PC' for a product this slick) Resource Editor,
start with the basic empty window, and code from scratch. The other is to
copy an existing application's folder, rename things, and begin with a
somewhat more complete starting point.

I'm taking the latter course here.

The process in summary:

A. Run resourceEditor to create or modify an existing application.
B. Lay out the application's window in Resource Editor.
C. Script the components that will trigger actions (essentially buttons and
menus)
D. Cleaning up artifacts of the copied program.

Let's go through those steps with my simple Counter tutorial.

A. Run resourceEditor to modify an existing application.

1. Make a copy of the "minimal" project folder in the samples folder of the
PyCard distribution. Put  into its own folder called "counter." (The folder
name isn't important to PyCard.)

2. Rename "minimal.py" to "counter.py" and "minimal.rsrc.py" to
"counter.rsrc.py."

3. Launch resourceEditor, which is also found in the PyCard distribution's
samples folder

4. Close the default window that appears and open the file counter.rsrc.py
in the folder you just created. The window looks identical to the minimal
application when it is running, except for the menu bar which remains the
resourceEditor's menu bar (since we are running resourceEditor at the
moment) rather than the Counter application's menu bar. resourceEditor is a
"live" editor; the application is running while you edit it.

B. Laying out the window for the counter tutorial application.

1. Select the text field containing the words "Hello PythonCard" by clicking
anywhere in it.

2. Double-click on the words in the field and delete them with the Backspace
key. (You may find this a bit tricky since the field is selected, but
double-clicking directly on the text should work.)

3. Type the number "42" (or some other number; I just happen to be a Douglas
Adams fan) into the box.

4. If the Properties Editor isn't already open, select it from the Debug
menu in the window you're working with.

5. Select the "font" property in the right-hand list of properties for the
field1 Text Field object and set the font size to 24.

6. Click Update.

7. Use the resize handles to shape the field so that the entire value "42"
shows and position the field near the right edge of the window and
approximately centered vertically.

8. Select the "editable" property of the Text Field object called field1 and
uncheck the checkbox. (By making the field read-only, we avoid the necessity
of error-checking that would be required if we let the user enter a value
directly into the field.)

9. Click Update.

10. Save the application. (OK, I'm paranoid. You don't have to save every
time I tell you to save. Go ahead. Live dangerously!)

11. From the "Components" menu, select "Add Button..."

12. In the ensuing dialog, change the generic name to 'incrBtn' (for
"increment button") and the label from 'Button n' to 'Increment'. Click OK.

13. Position this button in the upper left portion of the window.

14. Repeat step 9. Change the generic name to 'decrBtn' (for "decrement
button") and the label from 'Button n' to 'Decrement'. Click OK.

15. Position the Decrement button below the Increment button, approximately
in the middle of the window. You may need to increase the size of the window
slightly.

16. Repeat step 9 one more time. Change the generic name to 'resetBtn' and
the label to 'Reset'. Click OK.

17. Position the Reset button to the bottom of the vertical row of three
buttons.

18. Save your work. Or not.

C. Scripting the Buttons

Application scripts are stored in the Python (.py) file that represents the
application. In this case, that means they are in the file counter.py.

1. Using your favorite Python code editor, open the file counter.py. It is a
brief file with a self-explanatory comment and only one event handling
script right now (for the menu event triggered when the user selects Exit
from the File menu).

2. Position your cursor below the last line of the on_menuFileExit_select
(self, menu, event): handler.

3. Enter the following script, remembering that Python is white-space-aware
so that indentations of lines are significant:

    def on_incrBtn_mouseClick(self, target, event):
        startValue = int(self.components.field1.text)
        endValue = startValue + 1
        self.components.field1.text=str(endValue)

Let's examine this script because all the others we will do are all but
identical.

The opening line of a PythonCard event handler always starts with the
keyword "def" which is standard Python for function and method definition.
The next expression in the line starts with the PythonCard keyword "on_" and
is followed by the name of the component we are scripting. In this case,
it's the Increment Button, whose name is "incrBtn." After another connecting
underscore, the last portion of the handler definition line defines the
event for which this handler is to be called. All events take the same basic
set of parameters as shown above.

The next lines are simple Python for the most part. The first line defines a
variable called "startValue" to which we assign the current contents of the
field, coerced to an integer so we can perform arithmetic on it. The second
line adds one to the value we just retrieved. The third line assigns this
new result to the field's text property after coercing it to a string.

4. As long as we're in the application's main code file, let's also make our
program a little more internally consistent. Change the name of the class we
are creating from Minimal to Counter. At the end of this file, replace
"Minimal" with "Counter" in the line that begins "app = "

5. Save your work. (This time I mean it.)

6. From the resourceEditor's File menu, select "Run".

7. When the counter application appears, click the Increment button and
watch the displayed value in the text field to confirm that it is
incrementing as expected.

8. Exit the application.

9. Back in your Python editor, copy the function we just created for the
Increment button and paste it under that function, being sure that
indentation remains correct.

10. Edit the new handler to change the name of the button from incrBtn to
decrBtn and the '+' sign to a minus ('-') sign.

11. Save the application and run it. Test to confirm all works as expected.

12. Exit the application.

13. Back in your Python editor, create a final handler for the Reset button
that looks like this:

    def on_resetBtn_mouseClick(self, target, event):
        self.components.field1.text="0"

14. Save your work and test the application again to be sure it works.

What if the application doesn't run? In that case, you'll have to run the
program from your system's command line to get a look at what errors, if
any, PythonCard is generating. To see this in action (you can skip this if
you either already know how to do this or if you are confident  you'll never
create a bug in a PythonCard application that will cause the program to
fail), let's introduce a typographical error into counter.py.

1. Open counter.py in your favorite Python editor.

2. Change the word "class" to "classy" and save the program.

3. Run the application as you have been doing. You will probably see a brief
console window appear and then disappear. Nothing else happens.

4. Get to a command line for your system, cd (change directory) into the
counter directory and type:

python counter.py

(Adjust the command line so it finds Python and the target file correctly on
your particular system.)

5. You should see a syntax error indicated in the console window. It should
be pointing someplace on the line where we created the intentional typo.

6. Go back to the counter.py file and fix the line. Save the file and then
re-run the application either from the resourceEditor's File menu or from
the command line.

D. Cleaning up artifacts of original program

We already took care of changing the class name and the runtime invocation
name of the application from Minimal to Counter. Now let's change the
resource file to reflect the program's new name.

1. In resourceEditor, go to the Edit menu and select "Stack info..." In the
ensuing dialog, rename Minimal to Counter and click OK.

2. Go to the edit menu and select "Background Info..." Change the name of
the application to PythonCard Counter Tutorial" and click OK.

(NOTE that you should NOT edit these values in the resource file because
parts of  it get regenerated when the application is created and your
changes will be overwritten by the contents of the dialog boxes we just
set.)

That ends the basic tutorial. You now have a finished and working PythonCard
application.

We'll add one optional step for a program like Counter, one which you may
well need to take in any application of even somewhat greater complexity.
We'll add a menu to the application.

1. In the resourceEditor, go to the Edit menu and choose Menu Editor...

2. A dialog box appears with the current menu structure displayed on the
left. As you can see, the Counter application, which was borrowed from
minimal, has a single menu with a single menu option.

3. Click on the "New Menu" button.

4. In the editing area to the right of the display showing the menu, change
the name of the menu to menuCounterMenu and its label to Counter.

5. Now click "New Menu Item" and add a new menu item whose name is
"counterMenuIncrement" and whose label is "Increment."

6. Do the same for new menu items "Decrement" and "Reset."

7. Save your application in resourceEditor.

8. Open the counter.py Python file in your Python editor. Add the handler
name shown here:

    def on_counterMenuIncrement_select(self, menu, event):

9. Copy the three lines of the function on_incrBtn_mouseClick and paste them
into the definition of this menu function. (You'll want to be sure levels of
indentation are consistent.)

10. Follow the same procedure for hooking up the Decrement and Reset menu
options.

11. Save your work.

(You'll have noticed that the new menu doesn't appear in your application in
resourceEditor. Rest assured it will be there when you run the application.)

12. Run the application and confirm everything works as expected.

(NOTE that it would obviously be better design to factor out the duplicated
code into methods that handle the increment, decrement and reset processes
and then call those methods from within the event handlers. We leave that as
an exercise for the reader. Don't you hate when we do that to you?)

[Pythoncard-users] PythonCardProtoype release 0.6.2

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

You can get the latest version of PythonCard at:
http://sourceforge.net/project/showfiles.php?group_id=19015

Remember to backup or just delete your old PythonCardPrototype directory
before installing a new version, so that the old files aren't still in the
package directory. As always, report any problems to the list.

I didn't run setup.py to create a binary installer for Windows and .tar.gz
for Linux. Would anyone like to see those available?

Release 0.6.2 2002-01-16
added counter sample by Dan Shafer
  Dan wrote a great tutorial.txt file that explains how
  to recreate the sample step-by-step
added wxMiniFrame support for Windows in debug.py
  GTK still uses wxFrame
added findnth string function to util.py
  helps textEditor to fix Go to line under Windows
added minimal.spec example for building standalones
  using Gordon McMillan's installer
changed 'isdefault' attribute to 'default'
added shell key bindings and usage link to toc.html
added support in resourceEditor.py for resizing widgets
  under Linux/GTK
updated setup.py and MANIFEST.in for distutils
changed positionToXY to handle tuple of len 2 or 3
changed textEditor.pyw to show the filename in the title bar
moved 'menubar' attribute from 'stack' to the background
  updated all sample .rsrc.py files
  updated Backround __init__ (model.py), menu.py, spec.py, and
    resourceEditor.py
changed launching code in samples.py, resourceEditor.py, and
  findfiles.py to
  os.system(python + ' ' + filename + args + ' &')
updated imagebutton.py component _setBitmap method to workaround
  setting the bitmap after initialization on GTK
added positionSize.rsrc.py and PositionSize class to resourceEditor
  this is an example use of multiple windows
added tentative multi-window support
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/965583
updated SourceForgeTracker XML parsing
changed Message Watcher window to wxPython.stc.wxStyledTextCtrl
  Thanks Neil!
updated the _setIcon method in the Background class to support
  .xpm as well as .ico files for titlebar icons
fixed numerous bugs on Linux
  findfiles should now work on Windows and Linux
  file launching in samples.py, resourceEditor.py and findfiles.py
  now uses sys.executable to launch python programs
    thanks to Cliff Wells for these fixes
added htmlWindow component
  added simpleBrowser sample to experiment with htmlWindow
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/962840
  the list of supported tags is at:
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/964327
added check for whether a component is already loaded to avoid
  unnecessary imports in res.py
fixed addresses sample initialization when Outlook isn't installed

RE: [Pythoncard-users] possible project names

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

Charmer
  Personally I don't like the snake motif often used for Python, but when
life gives you lemons, make lemonade.

If nothing else, these name threads (there is another on pythonmac-sig) make
me appreciate the PythonCard name more; HyperCard will always be in my
thoughts even if the name does change.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Tuesday, January 15, 2002 9:21 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] possible project names
>
>
> Use this thread to make name suggestions and comments.
>
> PythonCard
>   I still like PythonCard, it feels right, but it brings a lot of baggage
> with it.
>
> PyCard
>   I really dislike this. It brings none of the "marketing benefits" of the
> PythonCard name, but some of the baggage of PythonCard due to the Card
> confusion. Not to mention being tired of py this and py that name
> variations
> with the exception of PyCrust which is clever.
>
> Monty
>   Pretty cheeky, but okay. I think this got covered fairly well in a
> previous thread.
>
> Zoot
>   The one I came up with today which actually seems to make some
> sense. Zoot
> is from Holy Grail and of course Carol Cleveland was the best
> looking of the
> Pythons; Dingo might work too, but I like Zoot better. The
> downside is that
> everyone will immediately think of Zoot Suit which is about style
> and looks,
> but then inevitably you think of the Zoot Suit Riots (at least in the
> USA)... sigh.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] FW: wxPython for OS X - now with menus!

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

hallelujah

Now altogether, hip hip hooray, hip hip hooray!

ka

-----Original Message-----
From: pyt...@py...
[mailto:pyt...@py...]On Behalf Of Kevin & Masako
Ollivier
Sent: Tuesday, January 15, 2002 6:08 PM
To: pyt...@py...; wx...@li...;
wxp...@li...
Subject: [Pythonmac-SIG] wxPython for OS X - now with menus!


Hi everyone,

I've (finally!) been able to get menus working on wxPython for Mac OS X. =)
Of course, I did not forget the obligatory screenshot:

http://payson.tulane.edu/kollivier/wxPythonMac-menu.JPG

I tested a number of samples out (including demo.py, hangman.py,
slashdot.py, and wxProject.py) and all the menu code ran fine. There was one
time where there did not appear to be any space between a menu title text
and the shortcut key, but that was the only issue I encountered.

So how did I do it? Actually, all I did was remove a few lines from the
wxWindows/wxMac source code which read in the menubar resource. Here's the
code I removed:

File: src/mac/menu.cpp
in Function wxMenuBar::MacInstallMenuBar

Handle menubar = ::GetNewMBar( kwxMacMenuBarResource ) ;
wxString message ;
wxCHECK_RET( menubar != NULL, wxT("can't read MBAR resource"));
::SetMenuBar( menubar ) ;
::DisposeHandle( menubar ) ;

Feel free to try this at home! I'm sure this will cause problems when
creating compiled apps on OS X though. My question is: is there a place we
can "move" the menubar initialization code so that it will get run by
compiled applications, but not by scripted apps? Maybe add an
"InitMenuBar()" function into the IMPLEMENT_APP macro for Mac?

Once we get this code issue resolved, I'm thinking we may want to build an
"alpha" binary version of wxPython for Mac, so that people can play with it
and see what has been done so far. What do you think? A majority of the
other issues I've found in the samples are simply visual "glitches" (like
text alignment and control overlap issues) that should have a more
straight-forward fix for them. =)

Thanks,

Kevin

RE: [Pythoncard-users] The Intro Blurb

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

> From: Dan Shafer
>
> The current draft of the PythonCard overview is:
>
> >PythonCard brings visual software development on Open Source tools
> >to the masses, picking up where Apple's immensely popular but
> >now-abandoned HyperCard product left off. Written entirely in the
> >widely used and respected object-oriented Python scripting language,
> >PythonCard enables end users to create applications and interfaces in
> >a style that is reminiscent of Microsoft Visual Basic without the
> >baggage of over-complexity for non-programmers. It then enables the
> >developer with some minimal amount of programming or scripting
> >experience to give the user's designs life and power through Python
> >scripting.
> >
>
> I don't find PythonCard (yet, at least) to be reminiscent of VB and
> I'm not sure that if it came out that way, I'd want to use it!
>
> If we intend to abandon the notion that it will be reminiscent of
> HyperCard, then let's make it either reminiscent of something really
> good or of nothing at all, I say!

I say blame the original author, not the messenger ;-)

I know I borrowed some ideas from HyperCard and VB and they are in the
current conventions for the user code and runtime tools, etc. What
PythonCard reminds me of and feels like, I don't know, I just work here, but
I like it. Perhaps we should borrow a phrase from Tweek's Coffee:
http://mr.hankey.de/archiv/episoden/ep217.html
Or perhaps PythonCard, "smells like...victory" ?

So basically, the above intro needs tweakage. I don't have any problem
dropping it entirely until we have something good, so that way it won't make
to 0.6.2 announcement a bad thing.

ka

[Pythoncard-users] The Intro Blurb

[Dan S. <da...@da...>]

The current draft of the PythonCard overview is:

>PythonCard brings visual software development on Open Source tools
>to the masses, picking up where Apple's immensely popular but
>now-abandoned HyperCard product left off. Written entirely in the
>widely used and respected object-oriented Python scripting language,
>PythonCard enables end users to create applications and interfaces in
>a style that is reminiscent of Microsoft Visual Basic without the
>baggage of over-complexity for non-programmers. It then enables the
>developer with some minimal amount of programming or scripting
>experience to give the user's designs life and power through Python
>scripting.
>

I don't find PythonCard (yet, at least) to be reminiscent of VB and 
I'm not sure that if it came out that way, I'd want to use it!

If we intend to abandon the notion that it will be reminiscent of 
HyperCard, then let's make it either reminiscent of something really 
good or of nothing at all, I say!

-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

RE: [Pythoncard-users] put on your marketing caps

[Dan S. <da...@da...>]

>
>To me implying that PythonCard picks up where Hypercard left off suggests
>that PythonCard does what Hypercard does and more so and it doesn't. Someone
>downloading PythonCard expecting it to have similar functionality to
>HyperCard is going to be very disappointed.

Depends on what we build, doesn't it? ;-) I mean, we _could_ 
ultimately reproduce all of the essential behavior of HC that people 
loved in PythonCard, no?

>Hypercard isn't abandoned - Apple still sells it. - see
>www.apple.com/hypercard.

Well, trust me. The product is abandoned. Just because they still 
sell it doesn't mean they are still developing it. I think the last 
release was three years ago and they have no developers currently 
working on it and have no public plans to do so.


-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

[Pythoncard-users] using wxMiniFrame again for Windows, findnth

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

Based on the responses to a thread I started on wx-users, wxMiniFrame is
just plain busted under GTK. In addition, it has a size bug during init that
you have to workaround on Windows. Robin helped me come up with a solution
and I checked it in for debug.py. Unless I screwed up, GTK should work like
it used to with wxFrame but Windows now uses wxMiniFrame.

That means that all of the runtime debug windows such as the Shell and
Property Editor will always stay in front of the main app window under
Windows; it's a feature. More importantly, when you bring a PythonCard app
to the foreground, the runtime windows will be brought forward as well. That
was the real problem I wanted to fix since it was annoying to click on the
app window only to find the Shell or Message Watcher still hiding behind
Internet Explorer or PythonWin or some other app.

Let me know if I broke GTK.

I also added a findnth string function to util.py

# original function by Steve Purcell
def findnth(s, substr, n):
    """find the nth occurance of substr in s

    return the offset"""
    offset = -1
    for i in xrange(n):
        offset = s.find(substr, offset+1)
        if offset == -1: break
    return offset

I started a thread on comp.lang.python about this too. It seems like
something that would be good to have as a standard method.

ka

[Pythoncard-users] Potential pythoncard buyinser seeks

[Pete M. <jo...@ma...>]

A Pythoncard potentially like a terminal emulator? Does it have a 
single, private SERVER version for pycardinates of soda to use?
Or is it free?
On Tuesday, January 15, 2002, at 08:27 PM, pythoncard-users-
re...@li... wrote:

> Send Pythoncard-users mailing list submissions to
> 	pyt...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> or, via email, send a message with subject or body 'help' to
> 	pyt...@li...
>
> You can reach the person managing the list at
> 	pyt...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pythoncard-users digest..."
>
>
> Today's Topics:
>
>    1. Re: possible project names (Magnus Lie Hetland)
>    2. RE: put on your marketing caps (David LeBlanc)
>
> --__--__--
>
> Message: 1
> Date: Tue, 15 Jan 2002 19:26:45 +0100
> From: Magnus Lie Hetland <ma...@he...>
> To: pyt...@li...
> Subject: Re: [Pythoncard-users] possible project names
>
> David LeBlanc <wh...@oz...>:
>>
>> Zotz! the mayan word for vampire! ^^V^^
>>
>> PyFrame
>>
>> PythonFrame
>>
>> Dave LeBlanc
>
> Let me get this straight: You are proposing "Dave LeBlanc" as a new
> name for PythonCard? <wink>
>
>> (PyCard<tm> is a trademark of David LeBlanc, all rights reserved.)
>
> How did you get this TradeMark -- by claiming it on this mailing list?
>
> --
> Magnus Lie Hetland                                  The Anygui Project
> http://hetland.org                                  http://anygui.org
>
>
> --__--__--
>
> Message: 2
> From: "David LeBlanc" <wh...@oz...>
> To: "pythoncard-Users" <pyt...@li...>
> Subject: RE: [Pythoncard-users] put on your marketing caps
> Date: Tue, 15 Jan 2002 10:49:45 -0800
>
>> PythonCard brings visual software development on Open Source tools
>> to the masses, picking up where Apple's immensely popular but
>> now-abandoned HyperCard product left off. Written entirely in the
>> widely used and respected object-oriented Python scripting language,
>> PythonCard enables end users to create applications and interfaces in
>> a style that is reminiscent of Microsoft Visual Basic without the
>> baggage of over-complexity for non-programmers. It then enables the
>> developer with some minimal amount of programming or scripting
>> experience to give the user's designs life and power through Python
>> scripting.
>
> "software development on Open Source Tools"? How about "software 
> development
> with Open Source Tools" - I personally find (as might be suggested by 
> the
> wording) sitting on hammers a bit painful ;)
>
> To me implying that PythonCard picks up where Hypercard left off 
> suggests
> that PythonCard does what Hypercard does and more so and it doesn't. 
> Someone
> downloading PythonCard expecting it to have similar functionality to
> HyperCard is going to be very disappointed.
>
> Hypercard isn't abandoned - Apple still sells it. - see
> www.apple.com/hypercard.
>
> How is it reminiscent of Visual Basic? Does PythonCard really want to
> associate itself with VB? When I develop in VB, I either expect to use 
> an
> editor for this clunky language or I expect a design/script UI tool 
> that has
> multiple panes with a visual layout editor, lists of functions, 
> attribute
> lists, lists of available controls and tons of online badly done help 
> etc.
>
> Microsoft
> Mediocre (darn, one letter short)
>
> The user is not the developer? It takes a developer to give the user's
> designs life and power?
>
> Dave LeBlanc
>
>
>
>
> --__--__--
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
>
> End of Pythoncard-users Digest

RE: [Pythoncard-users] put on your marketing caps

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

> > PythonCard brings visual software development on Open Source tools
> > to the masses, picking up where Apple's immensely popular but
> > now-abandoned HyperCard product left off. Written entirely in the
> > widely used and respected object-oriented Python scripting language,
> > PythonCard enables end users to create applications and interfaces in
> > a style that is reminiscent of Microsoft Visual Basic without the
> > baggage of over-complexity for non-programmers. It then enables the
> > developer with some minimal amount of programming or scripting
> > experience to give the user's designs life and power through Python
> > scripting.
>
> To me implying that PythonCard picks up where Hypercard left off suggests
> that PythonCard does what Hypercard does and more so and it
> doesn't. Someone
> downloading PythonCard expecting it to have similar functionality to
> HyperCard is going to be very disappointed.

We should probably be clear about what it is and where it is going as you've
made clear in the other posts to the list. Revising the home page, the SF
summary and so on is in order. I would say that we are heading towards
picking up where HyperCard left off, so wording to the effect of "The goal
is to pick up where ..."

The word smiths can do a better job than I on that stuff. Of course, all
projects start out with goals, it is just in the open source world you see
the project from beginning to first release shipment while commercial stuff
doesn't generally get seen outside the development group until beta. I think
people familiar with open source understand this, but maybe it is better to
emphasize the alpha quality; alpha means the design is still very fluid.
However, in the case of PythonCard every release is usable as is even if you
never upgrade and keep your own code in sync with th latest changes.

> Hypercard isn't abandoned - Apple still sells it. - see
> www.apple.com/hypercard.

Yes it is being sold, but it is old and stale and hasn't changed since 1998
or something like that and hasn't had major changes since the early
nineties. It will not be ported to OS X. To paraphrase the good doctor,
"It's dead Jim."

> How is it reminiscent of Visual Basic? Does PythonCard really want to
> associate itself with VB? When I develop in VB, I either expect to use an
> editor for this clunky language or I expect a design/script UI
> tool that has
> multiple panes with a visual layout editor, lists of functions, attribute
> lists, lists of available controls and tons of online badly done help etc.

Again, probably a where we are heading, not where we are at. The naming
convention for event handlers will be somewhat familiar to VB folks. Once we
move to a component model it will be even more familiar, especially if there
is an IDE/editor. Having been a casual VB programmer at one time I see
transitioning to Python and PythonCard even now as pretty easy for simple
stuff.

> The user is not the developer? It takes a developer to give the user's
> designs life and power?

Well Dan just through it up as a straw man, so it still needs some trimming
with the hedge clippers or perhaps a little fire here and there.

ka

RE: [Pythoncard-users] put on your marketing caps

[David L. <wh...@oz...>]

> PythonCard brings visual software development on Open Source tools
> to the masses, picking up where Apple's immensely popular but
> now-abandoned HyperCard product left off. Written entirely in the
> widely used and respected object-oriented Python scripting language,
> PythonCard enables end users to create applications and interfaces in
> a style that is reminiscent of Microsoft Visual Basic without the
> baggage of over-complexity for non-programmers. It then enables the
> developer with some minimal amount of programming or scripting
> experience to give the user's designs life and power through Python
> scripting.

"software development on Open Source Tools"? How about "software development
with Open Source Tools" - I personally find (as might be suggested by the
wording) sitting on hammers a bit painful ;)

To me implying that PythonCard picks up where Hypercard left off suggests
that PythonCard does what Hypercard does and more so and it doesn't. Someone
downloading PythonCard expecting it to have similar functionality to
HyperCard is going to be very disappointed.

Hypercard isn't abandoned - Apple still sells it. - see
www.apple.com/hypercard.

How is it reminiscent of Visual Basic? Does PythonCard really want to
associate itself with VB? When I develop in VB, I either expect to use an
editor for this clunky language or I expect a design/script UI tool that has
multiple panes with a visual layout editor, lists of functions, attribute
lists, lists of available controls and tons of online badly done help etc.

Microsoft
Mediocre (darn, one letter short)

The user is not the developer? It takes a developer to give the user's
designs life and power?

Dave LeBlanc

Re: [Pythoncard-users] possible project names

[Magnus L. H. <ma...@he...>]

David LeBlanc <wh...@oz...>:
>
> Zotz! the mayan word for vampire! ^^V^^
> 
> PyFrame
> 
> PythonFrame
> 
> Dave LeBlanc
 
Let me get this straight: You are proposing "Dave LeBlanc" as a new
name for PythonCard? <wink>

> (PyCard<tm> is a trademark of David LeBlanc, all rights reserved.)

How did you get this TradeMark -- by claiming it on this mailing list?

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

RE: [Pythoncard-users] possible project names

[David L. <wh...@oz...>]

Zotz! the mayan word for vampire! ^^V^^

PyFrame

PythonFrame

Dave LeBlanc

(PyCard<tm> is a trademark of David LeBlanc, all rights reserved.)

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Tuesday, January 15, 2002 9:21
> To: pythoncard-Users
> Subject: [Pythoncard-users] possible project names
>
>
> Use this thread to make name suggestions and comments.
>
> PythonCard
>   I still like PythonCard, it feels right, but it brings a lot of baggage
> with it.
>
> PyCard
>   I really dislike this. It brings none of the "marketing benefits" of the
> PythonCard name, but some of the baggage of PythonCard due to the Card
> confusion. Not to mention being tired of py this and py that name
> variations
> with the exception of PyCrust which is clever.
>
> Monty
>   Pretty cheeky, but okay. I think this got covered fairly well in a
> previous thread.
>
> Zoot
>   The one I came up with today which actually seems to make some
> sense. Zoot
> is from Holy Grail and of course Carol Cleveland was the best
> looking of the
> Pythons; Dingo might work too, but I like Zoot better. The
> downside is that
> everyone will immediately think of Zoot Suit which is about style
> and looks,
> but then inevitably you think of the Zoot Suit Riots (at least in the
> USA)... sigh.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] possible project names

[Magnus L. H. <ma...@he...>]

Kevin Altis <al...@se...>:
>
> Use this thread to make name suggestions and comments.
> 
> PythonCard
>   I still like PythonCard, it feels right, but it brings a lot of baggage
> with it.

FWIW, I think PythonCard is a good name, baggage or not. I don't see
the problem of including some card-like features/functionality, even
if one doesn't want that to be the primitive API. I think this
card-stuff is what made HyperCard so easy to use. Even if PythonCard
goes beyond it, that doesn't mean it has to be abandoned completely...
Or does it?

- Magnus (who obviously hasn't followed this discussion closely
  enough, but is arrogant enough to offer an opinion anyway <wink>)

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

RE: [Pythoncard-users] possible project names

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

PythonCard isn't too bad. I think a lot of baggage is self-imposed. I think
we could drop a lot of it by simply changing the project description. And
PythonCard has gained a certain amount of exposure. At the same time, I
don't think a name change would be bad, as long as the name was good.

I'm not wild about PyCard either. And even I'm getting a bit tired of the
PyCrust pun. My future projects will probably go to the other extreme and
avoid cleverness at all costs. PyCrust isn't too bad for the shell, because
its a pretty trivial application. PythonCard, though, deserves a really good
name, imo.

There is already an outliner/info manager called Zoot
(http://www.zootsoftware.com/), although not written in Python or in any way
related to HyperCard.

Just a 2 cent contribution from someone who lately only has time to
contribute by the penny.

---
Patrick K. O'Brien
Orbtech.com
Phone: 314-963-3206


> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Tuesday, January 15, 2002 11:21 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] possible project names
>
>
> Use this thread to make name suggestions and comments.
>
> PythonCard
>   I still like PythonCard, it feels right, but it brings a lot of baggage
> with it.
>
> PyCard
>   I really dislike this. It brings none of the "marketing benefits" of the
> PythonCard name, but some of the baggage of PythonCard due to the Card
> confusion. Not to mention being tired of py this and py that name
> variations
> with the exception of PyCrust which is clever.
>
> Monty
>   Pretty cheeky, but okay. I think this got covered fairly well in a
> previous thread.
>
> Zoot
>   The one I came up with today which actually seems to make some
> sense. Zoot
> is from Holy Grail and of course Carol Cleveland was the best
> looking of the
> Pythons; Dingo might work too, but I like Zoot better. The
> downside is that
> everyone will immediately think of Zoot Suit which is about style
> and looks,
> but then inevitably you think of the Zoot Suit Riots (at least in the
> USA)... sigh.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] possible project names

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

Use this thread to make name suggestions and comments.

PythonCard
  I still like PythonCard, it feels right, but it brings a lot of baggage
with it.

PyCard
  I really dislike this. It brings none of the "marketing benefits" of the
PythonCard name, but some of the baggage of PythonCard due to the Card
confusion. Not to mention being tired of py this and py that name variations
with the exception of PyCrust which is clever.

Monty
  Pretty cheeky, but okay. I think this got covered fairly well in a
previous thread.

Zoot
  The one I came up with today which actually seems to make some sense. Zoot
is from Holy Grail and of course Carol Cleveland was the best looking of the
Pythons; Dingo might work too, but I like Zoot better. The downside is that
everyone will immediately think of Zoot Suit which is about style and looks,
but then inevitably you think of the Zoot Suit Riots (at least in the
USA)... sigh.

ka