Hi, most of you have probably seen PythonCard http://pythoncard.sourceforge.net/ posts to the edu-sig list or comp.lang.python. I would like to get a feel for how many users on the edu-sig list are even remotely interested in PythonCard? I realize that it is too late to incorporate it into lesson plans for this fall and wouldn't recommend that anyway given that it is in a prototype stage, but I'm hoping that it will be useful in education, so I want to get your feedback. I think that the runtime is a very good environment for learning Python as well as doing GUI programming. The simplicity of using the GUI components should be especially suited for enhancing the learning of Python concepts without forcing the use of command-line input and output. Just as importantly, I would like to know particular reasons for a lack of interest. This will help to focus how the prototype evolves and who the target audience is. If you're in the camp of "What the heck is PythonCard and why the heck should I care?" then I refer you to the home page above first and can then answer any specific questions you may have. The more criticism the better. You can reply to this thread or email me directly and I'll summarize for the list. Thanks for your time, ka --- Kevin Altis altis@semi-retired.com ps. If you *are* interested in PythonCard, you should join the mailing list to contribute feedback... http://lists.sourceforge.net/lists/listinfo/pythoncard-users
On Thu, Aug 30, 2001 at 08:17:04AM -0700, Kevin Altis wrote:
I would like to get a feel for how many users on the edu-sig list are even remotely interested in PythonCard?
I looked into PythonCard after your first announcement. Here's the impression I got: + Visit site on SourceForge. Look at "screenshots" page. Seems to be a GUI builder. Yawn. + Follow link to "Samples 2" page. Now these "turtle" applications look more interesting. But there's no hint as to how one develops such applications. + Follow link to "requirements" document. It seems to sketch GUI elements to appear in the user interface. But I get no feel for what PythonCard really _does_. So, I wait for the project to mature a bit and provide more useful information about its goals. -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
From: fcy@acm.org
I looked into PythonCard after your first announcement. Here's the impression I got:
+ Visit site on SourceForge. Look at "screenshots" page. Seems to be a GUI builder. Yawn.
The screenshots pages don't show all the samples and they don't show any of the runtime windows like the Shell, Message Watcher, Property Editor, or Namespace Viewer. Hopefully, those pages will be beefed up soon. PythonCard is more than a GUI builder, but even so, why would you 'Yawn'? I'm curious what you currently use with Python. Obviously, there are great GUI tools for commercial languages, but everything for Python is pretty limited either by the underlying toolkit (tk) or there are costs involved in the runtime or development tools. More importantly, most of the framework tools take a monolithic approach which is fine for large team projects, but is really hard on the beginner or infrequent user. None are geared towards RAD for simple projects which should be completed in fifteen minutes to an afternoon while still working for larger projects. The question becomes what would be exciting? I jumped on the PythonCard idea because Python is a magical language missing the framework and environment for doing normal desktop applications and utilities. I know this probably sounds defensive, but I really would like to hear your opinions.
+ Follow link to "Samples 2" page. Now these "turtle" applications look more interesting. But there's no hint as to how one develops such applications.
Yet another need for more documenation. There is actually quite a bit in the turtle directory, but it could use more.
+ Follow link to "requirements" document. It seems to sketch GUI elements to appear in the user interface. But I get no feel for what PythonCard really _does_.
Good point. The requirements document should go away. It filled its original purpose which was to get us to the first pass at a prototype, which we've done. We're still enhancing the prototype, but we're beyond the initial requirements, which we needed when we started coding about six weeks ago. PythonCard is many things, but right now it is an application framework and a set of runtime tools to enhance and aid programming in PythonCard. Eventually, there will be an environment, so that you can dynamically add and edit widgets, scripts, etc. much like HyperCard. In addition, like HyperCard the framework will support transparent data storage, so if you just want to use PythonCard for simple database-type apps, little to no coding will be required. Part of what makes the framework (which is still fairly limited) different now is that the widget usage is basically like using any other Python object. More importantly, resource files are supported, so you don't have to mix widget descriptions in with your code and all the event binding is dynamic, so if you have a Button widget named 'btnRun' and a field named 'field1' in your app and you want to do something in response to a mouseClick on that button, you simply add a method def on_btnRun_mouseClick(self, target, event): self.components.field1.text = 'hello' That's it! No event tables, no callback definitions, no window handles, no initialization, you can even create widgets dynamically and they'll bind to any appropriate handlers you already have.
So, I wait for the project to mature a bit and provide more useful information about its goals.
The project is still 'alpha'. The reason I'm actively promoting it is to make sure that it has an audience once it goes beyond alpha. It is still usable today and will continue to be, but the API changes as features are added, changed, or removed and we turn wxPython specific calls into wrapped PythonCard calls. Consequently, nobody should be building a big project today based on PythonCard and they should realize that small changes might be necessary in any code they write, though it might be a simple find/replace kind of change. All the samples are kept up to date with the current framework as changes to the API are made. Thanks for responding, ka
On Thu, Aug 30, 2001 at 11:45:10AM -0700, Kevin Altis wrote:
PythonCard is more than a GUI builder, but even so, why would you 'Yawn'? I'm curious what you currently use with Python.
I mostly use Python for command-line applications. Where I've wanted a GUI, tkInter has been OK (but not great). If PythonCard turns out to be an effective GUI builder platform, I'm interested. But not interested enough right now to play with alpha software that has no obvious order-of-magnitude improvement over the status quo. That said, my "yawn" was disrespectful. Sorry.
The question becomes what would be exciting?
I would be excited by a system similar to DiSessa's "Boxer" application. Boxer only works on the Apple Macintosh, completely blocking me from using it at home and from offering to teach using it at my sons' grade school. Maybe PythonCard is heading in Boxer's direction; I couldn't tell from the documentation I could find. I'll stay tuned. The description your latest message gave of PythonCard was helpful. The PythonCard website would benefit from content like that.
So, I wait for the project to mature a bit and provide more useful information about its goals.
The project is still 'alpha'. The reason I'm actively promoting it is to make sure that it has an audience once it goes beyond alpha.
You may have to bootstrap the project a bit more to where you can "sell" it more effectively. As it stands, it's hard for me to justify spending much time on it. SourceForge is full of projects that have withered in the "alpha" stage -- I've created several myself. The fact that you're spending the time to champion PythonCard in these messages is a good sign. There's too much interesting stuff out there to get by on "build it and they will come". -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
On 30 Aug 01, at 11:45, Kevin Altis wrote:
GUI builder. Yawn.
PythonCard is more than a GUI builder, but even so, why would you 'Yawn'?
Coz there are lots of GUI builders already? And GUI builders for a language like Python are not so productive. In a language like VB or Delphi (which I personally love to bits) they are near essential but Python operates at a higher level and used in conjunction with an interpreter session a GUI builder is pretty much redundant for anything but big complex GUIs.
I'm curious what you currently use with Python.
IDLE and Pythonwin sometimes. But mainly just a DOS box and a vim editor...
GUI tools for commercial languages, but everything for Python is pretty limited either by the underlying toolkit (tk)
Thats a common misconception but in fact Pythons dynamic nature means you can construct the GUI piece by piece from the Python prompt. Changing positions by just unpacking and repacking as you go. It does help to sketch out the general layout first but thats true of VB etc too. But python is far more dynamic that the layout tools in VB or Delphi etc.
the runtime or development tools. More importantly, most of the framework tools take a monolithic approach which is fine for large team projects,
Huh? Most take (or at least allow) a very OO approach that encourages separate developments - either of individual 'super widgets' or of discrete 'windows' or dialogs. In fact I'd say VBs approach is more monolithic than Pythons. Python does require you to work differently - more like a Smalltalk project than a VB/Delphi one.
is really hard on the beginner or infrequent user.
This is true - power has its own penalties. Same is true of vim and emacs as editors. Maybe PythonCard has the better approach for occasional users.
None are geared towards RAD for simple projects which should be completed in fifteen minutes
This is totally wrong. Python and its GUI toolkits (Tkinter and wxPython are the ones I've used) are very much more appropriate to real RAD than most GUI Buildr based tools. Python keeps the focus on the function of the program not the appearance. VB might be prettier initially but Python will work better, faster.
because Python is a magical language missing the framework and environment for doing normal desktop applications and utilities.
No, Python just has a different approach. Try playoing with the Smalltalk workspace for a while, or talk to some Smalltalk programmers and see why Smalltalk is considered one of the most productive RAD tools around. Then do the same things in Python...(but without the class browser :-( )
sounds defensive, but I really would like to hear your opinions.
Not at all. Its a common perception for those coming from "traditional", aka GUI based RAD tools. Once you get used to Pythons approach its not really that much slower and nearly always delivers better core functionality.
PythonCard is many things, but right now it is an application framework and a set of runtime tools to enhance and aid programming in PythonCard.
Which are laudable aims and to be encouraged.
Eventually, there will be an environment, so that you can dynamically add and edit widgets, scripts, etc.
But I can already do that with Tkinter etc now. Its called the Python prompt... much like HyperCard. In addition, like
just want to use PythonCard for simple database-type apps, little to no coding will be required.
Could you expand on this aspect please?
fairly limited) different now is that the widget usage is basically like using any other Python object.
How is this different to Tkinter?
More importantly, resource files are supported, so you don't have to mix widget descriptions in with your code and all the event binding is dynamic,
Resource files are one way of doing this and Parrot tries it for Tkinter... But Python supports this out of the box by simply defining the app code in a separate moduile and binding its functions/methods to the GUI elements. This is normal best practice. And its all dynamic binding in Tkinter - you can even change the bindings mid program if you really want to.
'btnRun' and a field named 'field1' in your app and you want to do something in response to a mouseClick on that button, you simply add a method
def on_btnRun_mouseClick(self, target, event): self.components.field1.text = 'hello'
That's it! No event tables, no callback definitions, no window handles, no initialization,
But how do you change the behaviour of that during program execution? Thats less dynamic not more... (Yes, you could create a new function and assign it to on_btnRun_mouseClick via a lambda or using nested scopes I guess)
you can even create widgets dynamically and they'll bind to any appropriate handlers you already have.
I'm not convinced having to write a single line of binding code is that big a deal... I think PythonCard sounds like an interesting developnment. Like HyperCard its probably a better approach for occasional users and, like HyperCard, probably will have less attraction for 'power users'. All just my opinion of course. Alan g.
On Fri, 31 Aug 2001 agauld@crosswinds.net wrote:
On 30 Aug 01, at 11:45, Kevin Altis wrote:
GUI builder. Yawn.
PythonCard is more than a GUI builder, but even so, why would you 'Yawn'?
Coz there are lots of GUI builders already?
This is true - power has its own penalties. Same is true of vim and emacs as editors. Maybe PythonCard has the better approach for occasional users.
Well, Alan, have you ever used HyperCard? PythonCard is not just "yet another GUI builder", it is environment. It is higher level than Tkinter, etc. Your opinion on "GUI builders" is probably due to the fact that most of them are lame. While we want PythonCard to be of higher value. And TRULY plus productivity, not minus. And "occasional users" are those who come to Python from successful encounter with superb GUI builder. So, please, do not underestimate PythonCard potential! Sincerely yours, Roman Suzi -- _/ Russia _/ Karelia _/ Petrozavodsk _/ rnd@onego.ru _/ _/ Saturday, September 01, 2001 _/ Powered by Linux RedHat 6.2 _/ _/ "Brain: The apparatus with which we think that we think." _/
On 1 Sep 01, at 10:24, Roman Suzi wrote:
Maybe PythonCard has the better approach for occasional users. Well, Alan, have you ever used HyperCard?
I confess never to have used it "hands on". BUt I have project managed a Mac project where Hypercard was used and it was great for getting somehthing out quickly. But within 3 releases all the Hypercard stuff had been rewritten... But then 2 releases later the Mac version itself had stopped being produced but that doesn't mean Macs are bad! :-) Most of my comments are based on general experiences with so called "higher level" GUI toolkits and a read thru' the stuff about PythonCard. They provide a powerful startup tool for straightforward apps but often run out of steam when we push the boundaries. But then there are a lot of straighforward apps out there. I wasn't meaning to be disparaging about either Hypercard or PythonCard, they are worthy products/ideals but I was simply expressing why a previous poster may have felt "yawn" at the thought of another GUI builder/environment. Also I guess pointing out that GUI RAD doesn't need to be visual. Python(and Tcl/Tk) has a very different approach to incremental GUI development. (IMHO Python is superior to Tcl in this respect but I'm sure Tcl fans would disagree). Native Python feels more like early Smalltalk than Hypercard to me, both are productive environments.
Your opinion on "GUI builders" is probably due to the fact that most of them are lame.
Thats possibly true!
And "occasional users" are those who come to Python from successful encounter with superb GUI builder.
I'm not sure what you mean by that. I think there are a lot of occasional users coming at Python from lots of directions - education, Sys admin, Web development and yes maybe GUI work too.
So, please, do not underestimate PythonCard potential!
I'll keep an open mind, and probably even have a play with it - I usually do when these things come up. Alan G
On Sat, 1 Sep 2001 agauld@crosswinds.net wrote:
On 1 Sep 01, at 10:24, Roman Suzi wrote:
Maybe PythonCard has the better approach for occasional users. Well, Alan, have you ever used HyperCard?
I confess never to have used it "hands on". BUt I have project managed a Mac project where Hypercard was used and it was great for getting somehthing out quickly. But within 3 releases all the Hypercard stuff had been rewritten... But then 2 releases later the Mac version itself had stopped being produced but that doesn't mean Macs are bad! :-)
PythonCard is not a clone of HyperCard. As I understand it, it will allow to draw what is drawable (visual GUI parts) and everything else will be in Python scripts. This allows people who do not like GUIs to easily wrap logic into visual shell, making things "easier" for those who is accustomed to GUI. And I see educational uses are best fit for PythonCard. Pure Tkinter is NOT up to the task, because in this case people simply choose different environment. PythonCard is planned to provide simple GUI environment for those who greet things by clothers first.
Most of my comments are based on general experiences with so called "higher level" GUI toolkits and a read thru' the stuff about PythonCard. They provide a powerful startup tool for straightforward apps but often run out of steam when we push the boundaries.
But then there are a lot of straighforward apps out there.
I wasn't meaning to be disparaging about either Hypercard or PythonCard, they are worthy products/ideals but I was simply expressing why a previous poster may have felt "yawn" at the thought of another GUI builder/environment.
Also I guess pointing out that GUI RAD doesn't need to be visual. Python(and Tcl/Tk) has a very different approach to incremental GUI development.
It is verbal approach. For me personally it is easier to write apps by language. But for those who learn it presents a great barrier.
(IMHO Python is superior to Tcl in this respect but I'm sure Tcl fans would disagree). Native Python feels more like early Smalltalk than Hypercard to me, both are productive environments.
He-he! Hypertalk is also very much like Smalltalk, IMHO. (I also think, that "talk" is there for that reason)
Your opinion on "GUI builders" is probably due to the fact that most of them are lame.
Thats possibly true!
And if we anderstand WHY exactly they are lame, we will see that they have wrong border between drawable and scriptable tasks + stupid object model.
And "occasional users" are those who come to Python from successful encounter with superb GUI builder.
I'm not sure what you mean by that. I think there are a lot of occasional users coming at Python from lots of directions - education, Sys admin, Web development and yes maybe GUI work too.
OK. Right now I can't show nice higher level GUI builder for Python. That means that Python is out of reach for those educational users who need to perform concrete tasks fast. THis is not good.
So, please, do not underestimate PythonCard potential!
I'll keep an open mind, and probably even have a play with it - I usually do when these things come up.
PythonCard is in prototype stage. It is planned to rewrite it completely at some future moment.
Alan G
Sincerely yours, Roman Suzi -- _/ Russia _/ Karelia _/ Petrozavodsk _/ rnd@onego.ru _/ _/ Sunday, September 02, 2001 _/ Powered by Linux RedHat 6.2 _/ _/ "Windows: XT emulator for an AT." _/
OK. Right now I can't show nice higher level GUI builder for Python. That means that Python is out of reach for those educational users who need to perform concrete tasks fast. THis is not good.
"Concrete tasks" is not the same thing as being able to build a GUI. As Alan pointed out earlier, the IDLE shell is itself a GUI, and within in you can import whatever modules, write your own, and get a lot done interactively. When it comes to educational uses for Python, I can easily envision courses which involve no Tk or Pmw/Tk or wxPython at all, or any other graphical widgets kits. Also, for very simple interfaces, it's possible to just do HTML forms and wire 'em to Python via cgi. So if the goal is to give users shared access to lookup tables or something, the solution is often to just use their browsers, which they're familiar with anyway. You can even have Python generate the forms on the fly, if you need the interface to adjust based on previous inputs (using XML to drive interfaces is starting to be a pretty standard technology, especially in the world of hand-helds). I'm not saying GUIs aren't useful -- of course they are. I just don't think introductory programming or the kind of math-through-programming I do necessitates diving into GUI stuff right away. Your saying "concrete tasks" aren't doable without widgets seems too broad. *Some* concrete tasks. But I resist the tendency to equate programming with GUI development. One of the books I use is "Concrete Mathematics" and I can do a lot of the stuff in that book with no GUI beyond IDLE itself. Even graphics can be done without writing a GUI interface, e.g. the VPython kit pops up real time graphical content in a Tk window, in a modified IDLE. Or for non-real-time graphics (e.g. geometry stuff), you can output a text file and render it in Povray. I do this all the time with no overhead invested in a Tk-style interface (beyond IDLE). Kirby
On Sun, 2 Sep 2001, Kirby Urner wrote:
OK. Right now I can't show nice higher level GUI builder for Python. That means that Python is out of reach for those educational users who need to perform concrete tasks fast. THis is not good.
Your saying "concrete tasks" aren't doable without widgets seems too broad. *Some* concrete tasks. But I resist the tendency to equate programming with GUI development.
By concrete tasks I had in mind creating programs for methodological support in different subjects by making multimedia-like things easily. Things, which teachers always have their own opinion about. I met many teachers, which were dissatisfied with whatever they saw "ready-maid" and wanted their own CAE courseware... I agree that browsers probably solve more than half of the problem, but more could be easier done with means of traditional applications.
One of the books I use is "Concrete Mathematics" and I can do a lot of the stuff in that book with no GUI beyond IDLE itself. Even graphics can be done without writing a GUI interface, e.g. the VPython kit pops up real time graphical content in a Tk window, in a modified IDLE. Or for non-real-time graphics (e.g. geometry stuff), you can output a text file and render it in Povray. I do this all the time with no overhead invested in a Tk-style interface (beyond IDLE).
There is usually no problem with programming teachers: they could find suitable tools. The problem is with those who can write, draw and link parts together with GUI, but which programming capability is nearly zero. And this is what PythonCard + Python are going to change. Sincerely yours, Roman Suzi -- _/ Russia _/ Karelia _/ Petrozavodsk _/ rnd@onego.ru _/ _/ Monday, September 03, 2001 _/ Powered by Linux RedHat 6.2 _/ _/ "...I'm sorry, Reality is not in service at this time." _/
Hi Kevin Your post prompted me to check out PythonCard. Downloaded it to Win89se syetem with Python 2.1 installed. Took a summer break from computers recently, so I'm probably being very dumb but cannot find any 'getting started' instructions anywhere. 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? I would love to recommend it to my 12 year-old nephew who is just starting on Python [His first language]. But I know a;raedy he has has major trouble understanding how to load Python programs " Python's really hard he says". At his age and experience especially getting started is what is is all about. He plays lots of games adn is very quick to uss them out, but installing langauge packages adn deciphering typical programmer's READMEs is an art he has yet to learn. An extended version of your HTML screenshoots formatted as a "Getting Started" Tutorial woould be the first help for anyone I think. What level of programming experience do you think PythonCard is good for? 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. Thanks in advance any help - Jason ----- Original Message ----- From: "Kevin Altis" <altis@semi-retired.com> To: <edu-sig@python.org> Sent: Thursday, August 30, 2001 8:17 AM Subject: [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
participants (7)
-
agauld＠crosswinds.net -
fcy＠acm.org -
fred＠ontosys.com -
Jason Cunliffe -
Kevin Altis -
Kirby Urner -
Roman Suzi