pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] translating other layout formats to PythonCard

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

I forgot to mention that layout and data translation could be done for
things besides HyperCard. Someone could write a translator for Visual Basic
forms, Delphi, SuperCard, MetaCard, Boa, wxDesigner, some HTML forms,
various database form designers, etc. It is generally much easier and
quicker to use an existing layout and then modify the layout than to create
one from scratch.

Keep this in mind and if you are interested in writing a translator, just
post the issues to the list.

ka

[Pythoncard-users] translating HyperCard stacks to PythonCard

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

First of all, this is all Dan Winkler's fault ;-) for putting the idea in my
head last night, so that I felt compelled to do at least a proof of concept.
Any stupidity in the HyperTalk below is because I haven't done any HyperTalk
coding in a long time. I've included both the script and the script output
at the end of this message. You can make a copy of the minimal sample
directory, copy the output below and replace the contents of the
minimal.rsrc.py file to see what the layout looks like.

The script builds a valid minimal.rsrc.py file to be used with a copy of the
minimal.py script. The HyperCard stack info title, position, size (the
height has 20 added to it to make up for the title bar height in HC). Only a
single background is processed and only the background fields are exported,
so there are no background buttons, card buttons or fields, etc. Once we
start doing actual data storage as part of the framework, I'll add the
function to iterate through all the cards of a background and dump the data
to a nested dictionary for importing into PythonCard; it is easy to do, just
a bit premature this early in the life of the prototype.

I put a breakpoint at the end of the exportToPythonCard routine so that I
could copy the sInfo variable to the clipboard and then paste it into a text
file with DOS line endings before moving it over to my machine. That's why
there isn't code for writing the file included below, though it is certainly
easy to add.

There are quite a few utility scripts on the web that will export stack data
and stack descriptions. It probably makes more sense to simply read the
output from one of those utilities and convert to our own format. I'm not
talking about translating the HyperTalk to Python, only the layout and data
of the stack.

Anyway, this is a good project for a Mac HyperCard user/developer to tackle
while they're waiting on wxPython to get ported to the Mac. Feel free to
dive in.

ka

---- the script I put in the stack script of Addresses
on exportToPythonCard
  put stackInfo() into sInfo
  put backgroundInfo() after sInfo
  put "] }" & return & "] }" & return & "}" & return after sInfo
  -- write results to a 'export.rsrc.py' file
  -- loop through the cards of the background and export
  -- the data to a dictionary
end exportToPythonCard

function stackInfo
  put "{'stack'}" into bob
  put "{'stack':{'type':'Stack'," & return into s
  put "'name':'" & the short name of this stack & "'," & return after s
  put "'title':'" & the short name of this stack & "'," & return after s
  put "'position':(" after s
  put the topLeft of card window & "), " & return after s
  put "'size':(" after s
  put the width of this card & ", " after s
  put (the height of this card) + 20 & ")," & return after s
  put "'backgrounds':" & return & "[" & return after s
  return s
end stackInfo

function backgroundInfo
  put "{'type':'Background'," & return into s
  put "'file':'minimal.py'," & return after s
  put "'classname':'Minimal'," & return  after s
  put "'name':'bgMin'," & return after s
  put "'components':" & return & "[" & return after s
  repeat with i = 1 to the number of flds
    put fldDescription(i) after s
  end repeat
  return s
end backgroundInfo

function fldDescription i
  -- determine the field type
  put fldType(i) into fieldType
  if fieldType = "StaticText" then
    put "'text':'" & the value of bg fld i & "', " & return into textStr
    put "'alignment':'" & the textAlign of bg fld i & "', " & return after
textStr
  else
    if the sharedText of bg fld i then
      put "'text':'" & the value of bg fld i & "', " & return into textStr
    else
      put "" into textStr
    end if
    -- this doesn't look all that great, so I commented it out
    -- if the style of bg fld i = "transparent" then
    -- put "'border':'none', " & return after textStr
    -- end if
  end if

  -- then build up the attributes appropriately
  put "{'type':'" & fieldType & "', 'name':'" & fldName(i) & "'," & return
into s
  put "'position':(" & the topLeft of bg fld i & "), " & return after s
  put "'size':(" & the width of bg fld i & ", " after s
  put the height of bg fld i & "), " & return after s
  put textStr after s
  if fldVisible(i) = 0 then
    put "'visible':0, " & return after s
  end if
  put "}, " & return after s
  return s
end fldDescription

function fldName i
  return the short name of bg fld i
end fldName

function fldType i
  if the sharedText of bg fld i then
    -- maybe look at lockText as well?
    if the textAlign of bg fld i = "left" then
      return "TextField"
    else
      return "StaticText"
    end if
  else if the dontWrap of bg fld i then
    return "TextField"
  else
    -- should probably check the
    return "TextArea"
  end if
end fldType

function fldVisible i
  if the visible of bg fld i then
    return 1
  else
    return 0
  end if
end fldVisible



---- the resulting minimal.rsrc.py file

{'stack':{'type':'Stack',
'name':'Addresses',
'title':'Addresses',
'position':(208,183),
'size':(416, 276),
'backgrounds':
[
{'type':'Background',
'file':'minimal.py',
'classname':'Minimal',
'name':'bgMin',
'components':
[
{'type':'TextField', 'name':'Name',
'position':(100,17),
'size':(241, 24),
},
{'type':'TextField', 'name':'Company',
'position':(100,39),
'size':(241, 23),
},
{'type':'TextField', 'name':'Street',
'position':(100,72),
'size':(183, 23),
},
{'type':'TextField', 'name':'City',
'position':(100,94),
'size':(183, 23),
},
{'type':'TextField', 'name':'State',
'position':(100,116),
'size':(183, 23),
},
{'type':'TextField', 'name':'Zip',
'position':(100,138),
'size':(183, 23),
},
{'type':'TextField', 'name':'Phone 1',
'position':(114,176),
'size':(169, 17),
},
{'type':'TextField', 'name':'Phone 2',
'position':(114,192),
'size':(169, 17),
},
{'type':'TextField', 'name':'Phone 3',
'position':(114,208),
'size':(169, 17),
},
{'type':'TextField', 'name':'Phone 4',
'position':(114,224),
'size':(169, 17),
},
{'type':'StaticText', 'name':'Name Label',
'position':(7,24),
'size':(68, 16),
'text':'Name',
'alignment':'right',
},
{'type':'StaticText', 'name':'Company Label',
'position':(7,46),
'size':(68, 16),
'text':'Company',
'alignment':'right',
},
{'type':'StaticText', 'name':'Street Label',
'position':(8,79),
'size':(68, 16),
'text':'Street',
'alignment':'right',
},
{'type':'StaticText', 'name':'City Label',
'position':(8,101),
'size':(68, 16),
'text':'City',
'alignment':'right',
},
{'type':'StaticText', 'name':'Zip Code Label',
'position':(8,145),
'size':(68, 16),
'text':'Zip Code',
'alignment':'right',
},
{'type':'StaticText', 'name':'Telephone Label',
'position':(7,180),
'size':(68, 16),
'text':'Telephone',
'alignment':'right',
},
{'type':'TextField', 'name':'Sort order',
'position':(0,0),
'size':(30, 19),
'text':'1',
'visible':0,
},
{'type':'TextField', 'name':'Name Order',
'position':(141,0),
'size':(73, 19),
'text':'last word',
'visible':0,
},
{'type':'StaticText', 'name':'State Label',
'position':(8,123),
'size':(68, 16),
'text':'State',
'alignment':'right',
},
{'type':'TextArea', 'name':'Notes',
'position':(7,64),
'size':(278, 183),
'visible':0,
},
{'type':'TextField', 'name':'Correct Name',
'position':(100,0),
'size':(241, 24),
'visible':0,
},
] }
] }
}

Re: [Pythoncard-users] Announce: dbBrowser sample application

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

And the corrections start already ;-)

To access MySQL databases you will need MySQL installed, get it from 
http://www.mysql.com/ (you can also get another version from 
http://www.mysql.org/ but I'm not getting into that fight, thanks).

You will also need the MySQLdb package, which can be found at either of;
http://www.cs.fhm.edu/~ifw00065/
or
http://dustman.net/andy/python/MySQLdb/

I'm running version 0.3.5 of the MySQLdb package and version 3.23.37 of 
MySQL. Confirmation that the code works with other version will be most 
welcome.

The other 'gotcha' is that you will need to know the name of the 
database you want to connect to. By default MySQL creates databases 
called 'test' and 'mysql' when you install it. If you are stuck try the 
on line documentation at http://www.mysql.com/doc/ . After that you are 
definitely on your own - unless you send me a really nice e-mail.

I'm also posting this notice as the first piece of documentation. If you 
have access to cvs it will be in readme.txt.

Andy Todd wrote:

> Folks,
> 
> Its not just Kevin who is grinding out code for PythonCard, despite any 
> impressions to the contrary you may get from reading this list ;-)
> 
> Although it has taken me longer than a couple of hours, I've finally got 
> a working version of my sample application, dbBrowser. It is in the 
> current cvs tree as a sample application 
> (http://sourceforge.net/cvs/?group_id=19015). It probably isn't ready to 
> be included in the daily package yet, but I will leave that call to 
> Kevin. It does utilise some 'features' of PythonCard that aren't in the 
> other samples though, mainly in the area of dynamic widget definition 
> (and removal).
> 
[blah, blah, blah]


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

[Pythoncard-users] Announce: dbBrowser sample application

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

Folks,

Its not just Kevin who is grinding out code for PythonCard, despite any 
impressions to the contrary you may get from reading this list ;-)

Although it has taken me longer than a couple of hours, I've finally got 
a working version of my sample application, dbBrowser. It is in the 
current cvs tree as a sample application 
(http://sourceforge.net/cvs/?group_id=19015). It probably isn't ready to 
be included in the daily package yet, but I will leave that call to 
Kevin. It does utilise some 'features' of PythonCard that aren't in the 
other samples though, mainly in the area of dynamic widget definition 
(and removal).

dbBrowser is a PythonCard application designed to let you browse data 
that resides in a relational database. Over time it may grow into a more 
fully featured database client, but to do that I will need some feedback 
so please have a bash and let me know what you think.

Now, the drawbacks;

There is no documentation, so caveat emptor. dbBrowser currently only 
works with MySQL. In future versions I'm planning to support (at least) 
PostgreSQL, Oracle and some level of ODBC support. I'm also thinking 
about supporting csv and comma delimited files, but probably not just 
yet unless the clamour is deafening. If anyone wants to try plugging in 
another database my first documentation task is to define the interface 
that dbBrowser.py will expect to be exposed by plug in modules (if you 
want a head start have a look at mySQLBrowse.py).

Now, the excuses;

This is my first serious application in either Python or PythonCard so 
please, even if you haven't got MySQL, I'll welcome any constructive 
criticism of my code. Thanks in advance. The code is still under 
development, so feedback will help me build a better application. There 
are a couple of bits of code that even I reckon are necessary for 
revision and they are commented as such in the code.

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

[Pythoncard-users] GUI resourceEditor sample

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

I've checked into cvs the first version of a GUI resource editor for
PythonCard.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/samples/resourceEditor/

You can open any .rsrc.py file and it will change the window size and
position to match the stack attributes and create all of the 'components'
for the background. The resourceEditor will also attempt to set the
background attributes such as backgroundColor, image, and tiled. It does not
change the menubar or window title. If you open up a .rsrc.py file that
doesn't have a menubar, such as worldclock.rsrc.py then the window height
will be off by the height of the menubar; I guess I should list that as a
bug.

I'm not going to do a daily release until tomorrow at the earliest (this is
too new and I'm too tired), so if you can get it from cvs and let me know
what works and doesn't work, that would be very helpful. Please see the
readme.txt first before posting a known issue. I have no idea if the drag
and resize will work correctly on Solaris and Linux, so my fingers are
crossed.

I just started this app today, so it doesn't do much right now. We really
need to get multiple windows working (which is probably a few weeks in the
future) and a decent property editor before you'll be able to get away from
editing .rsrc.py files by hand.

If anyone would like to volunteer to work on the Property Editor or want to
take the resourceEditor and make it fabulous, please raise your hand. I can
help anyone that wants to come up to speed. You will have to code wxPython
directly in places in order to work on either the Property Editor or
resourceEditor even though most of the resourceEditor is simple PythonCard
stuff.

Please post what features you would like to see to the list. If you just
want it to emulate Visual Basic or Delphi or some other favorite environment
you've used in the past, please provide specifics for those people on the
list that haven't used that particular tool before.

ka

RE: [Pythoncard-users] list replies now directed to the list

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

> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Ronald
> D Stephens

> OK I am running Pycrust. I type in pom or pom.py and get
>
> >>> pom
> Traceback (most recent call last):
>   File "<input>", line 1, in ?
> NameError: name 'pom' is not defined
>
> ???

First, why are you trying to run the pom? It is a module, not a standalone
application. The only thing you should run directly are in the samples
directory. Second, are you running PyCrust standalone (PyCrust\PyCrust.py)
or are you running one of the samples with the shell (e.g. minimal -s)? When
PyCrust is run standalone it doesn't know anything about PythonCard.

> Also, is there a way to view the list messages like on Yahoo, or
> only by seeing them as they come to me bu email??

If you visit the home page at http://pythoncard.sourceforge.net/ there are
two archive links. ASPN has the best interface and is searchable.
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/PythonCard
The searchexplorer sample application has a search topic that will search
all the Python-related lists on ASPN, which is called appropriately enough
"Python mail lists (ASPN)".

ka

Re: [Pythoncard-users] list replies now directed to the list

[Ronald D S. <rd...@ea...>]

OK I am running Pycrust. I type in pom or pom.py and get 

>>> pom
Traceback (most recent call last):
  File "<input>", line 1, in ?
NameError: name 'pom' is not defined

???

Also, is there a way to view the list messages like on Yahoo, or only by seeing them as they come to me bu email??

As always, braindead as usual...;-)))))

By the way, a word to the wise, sell your stocks NOW..

OK, if you wait to long teo sell, jus tdont worry and be happy being a looooong term investor....

Ron Stephens





----- Original Message ----- 
From: "Kevin Altis" <al...@se...>
To: "pythoncard-Users" <pyt...@li...>
Sent: Sunday, August 19, 2001 2:03 PM
Subject: [Pythoncard-users] list replies now directed to the list


> Replies to list messages are now directed to the list.
> 
> ka
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> http://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] list replies now directed to the list

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

Replies to list messages are now directed to the list.

ka

RE: [Pythoncard-users] command events in textIndexer

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

To further emphasize the benefits of using the 'command' attribute I added
buttons to the textIndexer sample that mirror the Go menu. I didn't have to
make any changes to the code, only the .rsrc.py file since the command
methods were already defined for the Go menu items. Here is the addition to
the .rsrc.py file:

    { 'type':'Button',
      'name':'btnFirstCard',
      'position':(30, 210),
      'label':'First',
      'command':'goFirst'},
    { 'type':'Button',
      'name':'btnPrevCard',
      'position':(110, 210),
      'label':'Previous',
      'command':'goPrev'},
    { 'type':'Button',
      'name':'btnNextCard',
      'position':(190, 210),
      'label':'Next',
      'command':'goNext'},
    { 'type':'Button',
      'name':'btnLastCard',
      'position':(270, 210),
      'label':'Last',
      'command':'goLast'},

You can change the 'command' attribute of a widget dynamically at runtime if
you want, try it out with the Property Editor. If you have an action that
you want to associate with multiple widgets, menu items, toolbar buttons
(when we add those), etc. you should probably consider using a command;
using commands can reduce the amount of code you need to write and make the
logic of your UI clearer.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Saturday, August 18, 2001 12:13 PM
> To: Pythoncard-Users
> Subject: [Pythoncard-users] command events in textIndexer
>
>
> In order to increase the usefulness of the textIndexer as a testing ground
> for the PythonCard prototype I used command events for all of the menu
> items. Rowland added command events quite a while ago, but this
> is the first
> time I have used them. Since we haven't really talked about the 'command'
> attribute before I thought I would show what it looks like by comparing
> equivalent functionality in searchexplorer and textIndexer.
>
> searchexplorer.rsrc.py
>     { 'type':'MenuItem',
>       'name':'menuEditCopy',
>       'label':'&Copy\tCtrl-C'},
>
> searchexplorer.py
>     def on_menuEditCopy_select(self, menu, event):
>         widget = self.findFocus()
>         if hasattr(widget, 'editable') and widget.canCopy():
>             widget.copy()
>
> textIndexer.rsrc.py
>     { 'type':'MenuItem',
>       'name':'menuEditCopy',
>       'label':'&Copy\tCtrl-C',
>       'command':'editCopy'},
>
> textIndexer.py
>     def on_editCopy_command(self, menu, event):
>         widget = self.findFocus()
>         if hasattr(widget, 'editable') and widget.canCopy():
>             widget.copy()
>
> As you can see there isn't much to it. Any widget can have an associated
> command event, so a button could also be tied to 'editCopy'. Part of the
> reason for doing command events is that you can disable a command and then
> it will be disabled for all associated menus and widgets. Rowland
> will have
> to go into more detail when he has a chance.
>
> ka
> ---
> Kevin Altis
> al...@se...

[Pythoncard-users] textIndexer sample and ZODB

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

The textIndexer sample requires ZODB. I started to translate it to use the
shelve module and dumbdbm or something like that, but I haven't used those
modules before. I decided I have more important framework issues to work on,
so I'm just gonna leave the sample as-is.

If someone wants to go in convert textIndexer to use a storage mechanism
that more people will have installed I encourage you to do so. It will help
us when we start looking at transparent save issues for the framework. It
will also prevent people from emailing us that textIndexer doesn't run on
their system.

ka

[Pythoncard-users] Property Editor can set values now

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

The Property Editor can now set values as well as display them. The
following attributes are read-only:
'name', 'alignment', 'layout', 'style', 'border', 'font'

Those attributes are either settable only at initialization or in the case
of 'font' aren't supported yet. You must click the Update button in order
for a change to take place.

I'm not happy with either the layout of the Property Editor (PE) or the code
for doing the display and updates, so the PE will be rewritten, but not for
a while. It is easier to use than typing all the gets/sets into the shell.
If someone wants the revised PE as their own project I'll be happy to let
them have it. A variation of the run-time property editor could be used in
the GUI resource editor I started a few weeks ago, but never checked into
cvs. I'm going to look at that next.

Go ahead and play and let me know what breaks, which reminds me that there
is no validation before an Update, so Garbage In Garbage Out.

ka

RE: [Pythoncard-users] PythonCard or wxPython?

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

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Song
>
> Hi
> I'm starting to study the wxPython for GUI.
> Recently I've known the PythonCard.
> What is the differences with the PythonCard and wxPython?
> And is it possible to be replaced with the wxPython?
> I'm confusing what the GUI tool is better.

The PythonCard prototype sits on top of wxPython, so if you use PythonCard
you will be using wxPython, though you don't have to use wxPython directly.
Using wxPython directly without PythonCard will give you more flexibility,
but will require much more work on your part to do simple applications.

ka

[Pythoncard-users] command events in textIndexer

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

In order to increase the usefulness of the textIndexer as a testing ground
for the PythonCard prototype I used command events for all of the menu
items. Rowland added command events quite a while ago, but this is the first
time I have used them. Since we haven't really talked about the 'command'
attribute before I thought I would show what it looks like by comparing
equivalent functionality in searchexplorer and textIndexer.

searchexplorer.rsrc.py
    { 'type':'MenuItem',
      'name':'menuEditCopy',
      'label':'&Copy\tCtrl-C'},

searchexplorer.py
    def on_menuEditCopy_select(self, menu, event):
        widget = self.findFocus()
        if hasattr(widget, 'editable') and widget.canCopy():
            widget.copy()

textIndexer.rsrc.py
    { 'type':'MenuItem',
      'name':'menuEditCopy',
      'label':'&Copy\tCtrl-C',
      'command':'editCopy'},

textIndexer.py
    def on_editCopy_command(self, menu, event):
        widget = self.findFocus()
        if hasattr(widget, 'editable') and widget.canCopy():
            widget.copy()

As you can see there isn't much to it. Any widget can have an associated
command event, so a button could also be tied to 'editCopy'. Part of the
reason for doing command events is that you can disable a command and then
it will be disabled for all associated menus and widgets. Rowland will have
to go into more detail when he has a chance.

ka
---
Kevin Altis
al...@se...

[Pythoncard-users] textIndexer sample (conversion of Dan Winkler's PythonCard demo)

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

I've converted Dan Winkler's original PythonCard.py demo.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCard/

Dan's explanation of the code:
"It's about text searching and the hint bit algorithms hypercard uses, which
is more formally called "superimposed coding". It's really about indexing
and compressing text which is useful on stacks with thousands of cards of
text where you want fast search..."

I made the conversion from Neil's wxPython conversion of Dan's tk code;
how's that for a GUI journey? Of course, very little of the real guts had to
change. I checked the conversion in as a sample called 'textIndexer'

The version in cvs still uses ZODB to store the stack data, but I'm gonna
change that.

ka
---
Kevin Altis
al...@se...

[Pythoncard-users] fwd: RE: [Anygui-devel] Re: Automating UI tests (was Re: Art of Unit Testing)

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

> Alex Martelli wrote:

> I was imagining a scheme that would avoid the whole
> "move-one-button-and-break-stuff" thing. If widgets have
> names, which it seems they might based on recent list
> traffic, then I'd like to be able to write unit tests
> like this:
>
> # Open a customer window and load some data.
> win = TestWidgetCollection["CustDBWindow"]
> win.open()
> win["CustNameField"].typeKeys("Joe Smith")
> win["CustFetchButton"].click()
>
> # Confirm data loaded.
> if win["CustZipField"].getText() != "10001":
> 	... test failed ...

Having unit testing from day one should be a big win.

I think I would just use assert, but you have the general idea. We had
widgets sending events to each other (button2 sending a mouseClick to
button1 in the proof), but Rowland turned it off since it was "unclean". The
way our event dispatch works it will be trivial to add an event log, which
we're already doing via the Message Watcher, we're just not saving the
results or showing the details right now. It will also be relatively simple
to add a generic "macro" mechanism, which in turn can be used as part of the
testing framework. You'll also be able to post events to see if they are
actually handled such as click at position (45, 10).

Since I want PythonCard to support editing outside the environment (like
we're doing today) we will always need tools that make sure the code and
resources and data repository are in sync. The environment we eventually
create can do this transparently, but if we allow people to edit code in
Emacs or another IDE then it becomes possible to mismatch a handler name and
widget name and so there has to be an external validation process.

> This way, test cases would be independent
> of the exact layout of UI controls. Of course,
> if the overall structure of your UI changed,
> tests would break; but that's probably what
> you want. Also, I think test cases constructed
> this way will be easier to understand. (Hmm,
> maybe capture/playback could just generate
> code like this, to which one would only need
> to add commentary. That would rock.)
>
> This could also provide a general way of scripting
> Anygui apps, if anyone thought that would be useful.
>

Macros, yes. Note that via PyCrust we already have the ability run any
arbitrary Python code when an app is started. This is used in the turtle
sample and the base package to preload to short variable names (bg and
comp). In order to automate the edit, run, test, cycle you can actually
create a pycrustrc.py file in the app directory and then when you start the
app it will run the test. This should be formalized, but the capability is
already there. Anyway, I think this is pretty fundamental stuff.

Anyway, wxPython doesn't do this for us, but a higher-level pythonic
framework should probably support these kinds of things out of the gate.

ka

[Pythoncard-users] PythonCard or wxPython?

[Song <bag...@ho...>]

Hi
I'm starting to study the wxPython for GUI.
Recently I've known the PythonCard.
What is the differences with the PythonCard and wxPython?
And is it possible to be replaced with the wxPython?
I'm confusing what the GUI tool is better.

Thanks

[Pythoncard-users] HTML, again

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

All,

I've validated the HTML of the other pages on the project web site. The 
web site has been updated and the new files posted to cvs.

Of course, if anyone has any suggestions please feel free to shout out.

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

[Pythoncard-users] we're in the top 20 most active python projects list

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

http://sourceforge.net/softwaremap/trove_list.php?form_cat=178&page=1

ka

[Pythoncard-users] fwd: PythonCard gets exposure at O'Reilly

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

> -----Original Message-----
> From: Scott Widney [mailto:SW...@ci...]
> Sent: Friday, August 17, 2001 5:50 PM
> 
> 
> There is an article on the O'Reilly Network that is sure to increase
> PythonCard's visibility (you probably already know about this):
> http://www.onlamp.com/pub/a/python/2001/08/16/pythonnews.html
> 
> There are also a couple of background articles on HyperCard that are
> related:
> http://www.oreillynet.com/pub/a/mac/2001/03/29/mac_dev.html
> http://www.oreillynet.com/pub/a/mac/2001/08/17/goodman.html
> 
> I'm very excited about the possibilities. For instance there are many
> teachers who use HyperCard stacks on a daily basis. Sooner or 
> later, they're
> going to be faced with upgrading beyond Mac OS 9. If they don't have an
> upgrade path or another equally viable alternative, their stacks 
> are dead --
> their functionality gone, their data lost. Some good opportunities....
> 
> Keep it up!
> Scott

[Pythoncard-users] updated tutorial.txt

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

Patrick found some mistakes in tutorial.txt, left-over from an older version
of the framework. I'm including the revised tutorial.txt since the 0.4.1
release still has the old version. I cleaned up the .rsrc.py file slightly
and fixed the widget reference to match the new dot notation introduced in
release 0.4.

ka
---
Here's a brief guide to writing a PythonCard app using the current
prototype.

What I do when starting a new app is copy the minimal directory (one of the
samples), rename the directory, then rename minimal.py and minimal.rsrc.py.
Open up the renamed minimal.rsrc.py which I'm including in whole here to
simplify the discussion.

Change the 'stack' attributes 'name', 'title' and 'size' and add 'position'
if you want it.
Change the 'background' attributes 'file', 'classname', and 'name'. 'file'
should match the name used when you renamed 'minimal.py'. 'classname' should
match the class used in the renamed minimal.py. The if __name__ ==
'__main__': section of minimal.py is the same for all PythonCard samples, so
there is no need to change that. You need to add import statements depending
on what your app will do and whether you want to always use fully-qualified
names such as PythonCardPrototype.model.Background. See the other samples,
for examples of additional import statements.

If you don't want a menubar, then that block can be removed from the
.rsrc.py file. If you want additional menus and menu items such as an Edit
menu like the one used in searchexplorer you can copy from some of the other
samples, or just add your own.

It is a good idea to run the app as you make changes to the .rsrc.py file so
that you can see how the UI is progressing. If you're editing with a
Python-aware editor like IDLE or PythonWin, then you can do a syntax check
on the dictionary (the whole .rsrc.py file is one big dictionary) as you
make changes, to make sure you didn't miss a comma or quote character and
most editors will also match the blocks for you delimited by (), [], and {}.

Once you start adding components and replace the 'TextField' component with
your own, make sure to use meaningful names for each component; the
component names must be unique. If you add a 'Button' you might give it a
name like 'buttonRun' or 'btnRun' then in your code you can have a method
handler like (assuming 'field1' still exists):

    def on_buttonRun_mouseClick(self, target, event):
        self.components.field1.text = 'My first PythonCard application'

ka

--- fragment of minimal.py

class Minimal(PythonCardPrototype.model.Background):

    def on_menuFileExit_select(self, menu, event):
        self.Close()

--- minimal.rsrc.py

{ 'stack':{ 'type':'Stack',
            'name':'Minimal',
            'title':'Minimal PythonCard Application',
            'size':( 200, 100 ),

    'menubar':
    {
        'type':'MenuBar',
        'menus':
        [
            { 'type':'Menu',
              'name':'menuFile',
              'label':'File',
              'items': [
                { 'type':'MenuItem',
                  'name':'menuFileExit',
                  'label':'E&xit\tAlt-X' } ] }
        ]
    },

    'backgrounds':
 [
  { 'type':'Background',
    'file':'minimal.py',
    'classname':'Minimal',
    'name':'bgMin',
   'components':
   [
    { 'type':'TextField',
      'name':'field1',
      'position':(0, 0),
      'text':'Hello PythonCard' },
   ]
  }
 ]
 }
 }

[Pythoncard-users] pythoncard-users mailing list archives

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

This is just a test message to make sure the list is working correctly. ASPN
has notified me that they will be able to keep the old PythonCard archives.

Archives @ ASPN:
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/PythonCard

Archives @ SourceForge (new messages only)
http://www.geocrawler.com/lists/3/SourceForge/14884/0/

And finally the old Yahoo group, which is being discontinued:
http://groups.yahoo.com/group/pythoncard

ka