pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] design proposal

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

Here's a design proposal for the next iteration of PythonCard.

I've been working on a design for PythonCard that is a refinement of the
current design with the following changes:

HyperCard specific classes/methods have been renamed or removed.  Most 
of the HyperCard-like functionality was never implemented, and I think 
that the names Stack/Background/Card bring a lot of baggage to the table 
that is distracting at this stage in the game.  We have to build a core 
for PythonCard that allows us to build interesting applications, and 
lets us extend the core to include the things we like about HyperCard: 
automatic persistence, cards, backgrounds, etc.

This design makes practically everything a scriptable component: 
Application, Window, View, Widget - they are all components - I think 
this will pay off in the future, even though I don't have good examples 
for why an Application should be a Component, etc.

Meta-Model

With slight changes to spec.py, which is basically a meta-model for
PythonCard components, we can fully document the interfaces that a 
Script can support for a particular component.

The script for a component is totally dynamic, so you could change any
component's script at runtime.

We can build a complex component, and distribute it with it's spec 
entry, and anyone can just drop it in to their PythonCard environment 
and use it, including visual programming tools that support the 
meta-model, like the visual environment we want to build for PythonCard.

So, basically, an IDE can look at a component's meta-model entry, and 
build a script editor for that component that shows the events and the 
methods that scripts for the component can support.

Custom event classes can be defined and added to the environment in 
support of future components.

There are two user programming models - Scripts and Handlers.

Script Objects

Users familiar with OO can program directly with Script objects.  By 
looking at the events a component supports, you can define a subclass of 
script, implement the appropriate methods, and set an instance of the 
script on the desired component.  In addition, a resource file can 
contain an entry for a component that specifies the name of the Script 
class that should be instantiated and bound to the component at runtime.

Handler Objects

The handler based model will look pretty much like it does now.  There 
might be some slight changes, but it basically looks like it does now. 
Handlers  are implemented on top of Scripts.  Handlers hide Scripts from 
the user.  Handlers may be specified in a resource file and bound just 
as they are today.

Component Extensibility

Here's an over-simplified example:

Someone could build a Calendar component that uses our Button widgets,
TextFields, BitMaps, etc.  The Calendar could support custom Events like
CalendarEntryCreatedEvent, CalendarEntryDeletedEvent, etc.  These events
would map to the method names calendarEntryCreated( aEvent ) and
calendarEntryDeleted( aEvent ).

Anyone could drop the Calendar component into their environment, 
construct an instance, set the Script of the Calendar component to a 
user-defined script that handles calendarEntryCreated() and 
calendarEntryDeleted().

The script will be called when ever someone uses the Calendar 
component's gui to add an entry to a day or delete an entry from a day. 
  The script could manage the persistence of the entries, or pass them 
to some scheduling system, etc.

-

A design document that contains descriptions of the classes discussed 
above as well as several UML diagrams can be found at:

http://pythoncard.sourceforge.net/newdesign/design.0.0.3/design.html


As soon as I design the event dispatch mechanism i can prototype both
models programming models.  We'll simulate sending gui events to a 
component and see how Script objects and Handler objects work.

-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

[Pythoncard-users] wxPython issues

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

Unless someone posts a compelling reason to use a different toolkit
underneath PythonCard, wxPython is what we'll commit to for the future of
PythonCard.

The question then becomes how thin of a layer should we have over wxPython?
What is the framework doing that wxPython doesn't do? What are the pros and
cons of exposing more of wxPython? Since I'm naturally a critical guy, most
of the stuff below is probably going to emphasize the negative aspects of
wxPython, but I like wxPython, I'm just not very good in the praise
department :)

Critical mass
One obvious problem that the PythonCard project has is critical mass. In
order to be successful it really needs more developers and more users to
make it into the best framework/environment for building cross-platform GUI
apps in Python.

mailing list         people on list
------------------------------------
pythoncard-users     ~45
wxpython-users       ~600
wx-users             ~670

As one would expect, the newer project (PythonCard) has a fraction of the
users of wxPython on the mailing list. This doesn't reflect the total number
of users, but it does give an idea of the number of active participants
interested in a project that can provide answers and opinions. The number of
downloads of the latest release of PythonCard 0.4.5 is ~340 while there have
been over 20,000 downloads of wxPython 2.3.1 in various forms.

This is probably the single most important reason I see for minimizing the
differences between PythonCard and wxPython and making most if not all of
wxPython available in PythonCard apps. PythonCard will end up being the
simple to use application framework that wxPython doesn't have and hopefully
the environment will be equally simple to use, yet still powerful enough to
get most jobs done. If PythonCard doesn't stray too far from wxPython it
will also be appropriate to bundle it as part of wxPython in the future.

The best chance we have of increasing the number of users and developers is
to make PythonCard very close to wxPython and leverage the installed base of
users, developer expertise, etc. A helper class for PythonCard can be
beneficial to other wxPython projects.

PythonCard problems are often wxPython problems which are often wxWindows
problems
Since PythonCard sits on top of wxPython, it is not surprising that in many
ways it is limited by the capabilities of wxPython. If you've spent much
time on the wxPython-users list you will also know that wxPython problems
and issues are often wxWindows issues and some investigation on the wx-users
list or worst-case going into the wxWindows C++ sources is required to find
a problem. The good news is that it is open source so you can look at the
sources.

Documentation
The good is that there is some. The bad is that the wxPython docs are really
wxWindows (C++) docs with wxPython notes stuck in here and there. The docs
can also be misleading because wxPython only implements a portion of the
wxWindows framework. The docs are almost always out of sync with the
sources. I have found out the hard way that when you have a question, one of
the first things you should do is grep the sources and demo for the class or
function you are interested in. The next thing you should do is search the
ASPN wxPython-users archives
http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/wxPython-users

Robin knows documentation is one of the warts of wxPython and has stated
that he will be providing better documentation. Unlike, tkinter, there is
very little book material on wxPython.

wxPython does have a small online wiki (currently down)
http://wxpython.org/cgi-bin/wiki
for FAQs and cookbook entries and the wxPython Pit
http://wxpython-pit.sourceforge.net/
which is the best place to find other projects using wxPython that may also
have solutions to the problem you're trying to solve.

wxPython has a lot of functionality, the trick is learning how to harness
that power. I feel that of all the GUI toolkits for Python, you have to
compromise the least with wxPython. You also get native widgets on each OS
platform and that is important to me.

Boa and wxDesigner
There are two IDEs that are wxPython-aware that you can use to build
wxPython apps. I haven't used either that much, so those of you that have
should chime in here with the pluses and minuses of each.

A good question with regards to the environment that PythonCard needs is why
not just use Boa? What aspects/features of Boa, if any, makes it unsuitable?
Could we just add-on or modify Boa to make it acceptable? I'm not a fan of
code generators myself and the resource files are a fundamental requirement
for PythonCard for me, so I need to be able to build/code with resources and
that will require some Boa modifications, AFAIK. Note that if you haven't
already looked at Boa, you need to get the version out of cvs, do not use
the 0.0.5 release in the files area. Boa is at:
http://sourceforge.net/projects/boa-constructor

Class complexity
If you look at any window or control in wxPython like wxTextCtrl, you will
see that it uses multiple-inheritance and derives from a lot of classes.
Here's wxTextCtrl:
  streambuf
  wxControl
  wxWindow
  wxEvtHandler
  wxObject

The number of methods available in the wxWindow class alone is huge. You
need to use a number of classes for even the most basic app. GUI programming
is event driven and with wxPython you have to bind all the event handlers
yourself. Furthermore, most of the options available with wxPython classes
are set via CONSTANTS and there are a lot of constants. That means that new
users to wxPython can find it a quite daunting task to figure out how to get
even the simplest app done. I pretty much have to keep the wxWindows help
document open just to look up the various constants when I'm programming
wxPython. Some of the ugliness in the current PythonCard framework is from
just renaming wxPython constants or methods, but still following the same
procedural paradigm.

More procedural than object-oriented
This boils down to wxPython only being sort of object-oriented. Robin has
done a good job of making portions of wxWindows more pythonic, but there is
more work to be done. OOP folks will have to provide further comment, I'm no
OOP design expert.

wxPython does not provide an application framework, that is partly the point
of PythonCard.

That's probably enough for now. I'll post some ideas later about providing a
thin layer over wxPython that gives us some of the benefits the current
PythonCard model... while exposing most if not all of wxPython.

ka

[Pythoncard-users] Re: hoping for more input

[Rodney S. <ro...@io...>]

I am fairly new to this list and have just been lurking so far, but here 
are my thoughts.

I used to be an active HyperCard user. In fact, at one time I lead a 
fee-based support group at Apple which among other things, supported 
HyperCard. I would love a tool that was as easy to use but offered more 
power. PythonCard seems to have the potential for this.

In order to get there, it definitely needs a GUI development environment. 
Current state of the art in a HyperCard-like environment seems to be 
Revolution (www.runrev.com). Revolution is expensive, though. It is also 
xTalk based, rather than Python.

Cross-platform is also very important. While native look and feel is 
important, taking advantage of all the capabilities of a particular 
platform takes second place. I would gladly sacrifice some capabilities of 
any OS for good cross-platform development.

Definitely avoid MVC for users. Yes, Model-View-Controller is a powerful 
concept, but PythonCard needs to make it easier to create applications, not 
harder. Python is hard enough for a new user to become productive in 
already. Don't add difficult concepts on top of that. I know the language 
itself is relatively simple, but try teaching a new user how to create a 
standalone application from the ground up and you'll see what I mean.

I also don't really like the idea of following DOM. It works for browsers, 
but isn't necessarily intuitive for other environments. The HyperCard idea 
of stack-card-background-foreground, etc. seems to make more sense to new 
users.

Message watcher functionality is definitely useful. I think that in 
general, the command line should be hidden as much as possible from the 
user in PythonCard. Being able to bring one up only as needed is definitely 
useful, though.

I actually think that dependence on the command line is one of Python's 
weaknesses. It makes things easier when launching from Unix. But, it is 
much harder for users to follow if they are used to Windows or Mac OS. 
Given this, PythonCard should be a double-clickable application that can be 
launched easily by a user and then let them create applications easily 
using PythonCard as the scripting language. If someone has to start the 
whole Python environment to run their applications, you will lose many 
potential new users.

Similar to the above, PythonCard needs to provide a way to deliver easily 
launchable and distributable applications. If it doesn't compile to Java or 
some other language, then there needs to be really good documentation 
describing how to create a standalone application on each supported 
platform. It isn't sufficient to expect the user to figure out how to do it 
on their own.

As for the name, it seems fine to me,  but you can certainly see my bias 
from what I have written above. If you are trying to create a tool like you 
have described, the name makes sense. If it is going to be more Visual 
Basic-like, then you might want to change it.

Of course, all the above is just my opinion. It states what I would like to 
see. If PythonCard takes some other form and still makes Python development 
easier, I would likely consider using it. So far, it seems to add yet more 
to learn on top of my learning Python itself so I haven't really played 
with it.

-Rodney

[Pythoncard-users] short term plans

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

Rowland is back in the saddle and looking at the whole object model for
PythonCard and possible revisions. He should be posting his initial thoughts
this weekend. I think I'm going to investigate in the opposite direction and
see what a really thin layer over wxPython would look like and then post
about the pros and cons of that approach. That should give us a fairly broad
set of options. Based on the conversation Rowland and I had today I don't
think there will be any drastic revisions to how we're doing user code today
with either approach, so either the initial ideas from this summer were good
or we're still in a delusional state ;-) Either way, multiple windows,
dialogs, etc. are on their way. Stay tuned.

ka

Re: [Pythoncard-users] Kevin's PythonCard goals

[Robin D. <ro...@al...>]

> Richedit control
> Like multimedia this is another toughie due to cross-platform issues. It
> turns out that under Windows, wxWindows/wxPython uses a control limited to
> 32K of text for wxTextCtrl. In order to get a 2GB text limit and styled
text
> in the same control you have to specify the wxTE_RICH and wxTE_MULTILINE
> styles. However, under Linux the richedit control was coded specifically
for
> wxGTK and does not use a native control or have all the features of the
> richedit DLL under Windows, so the wxWindows rich text API is extremely
> limited. Typically, people are directed towards Neil's Scintilla in its
> wrapped form if they want more control, but Scintilla, while nice for
doing
> a text editor is not nice for simply mixing styled text in the same
control.
> I have no idea what the wxMac situation will be. What I do know is that an
> additional layer of logic is going to be needed to make styled text simple
> and easy to use in wxPython. For speed reasons, whatever Python logic is
> added to make the rich text control more useful will probably have to be
> moved back to C++ at some point. Neil or Robin, please correct me on any
> mistakes above.

AFAIK, the widget used for wxGTK's wxTextCtrl is a standard gtk+ widget, but
it is true that it is relativly limited in functionality.  There is a new
gtk+ widget coming in gtk+ 2.0 that will probably be used in wxGTK when it
is ported to the new gtk+, but I don't know anything else about it.

> Direct manipulation instead of Model View Controller?!
> This is a separate thread. I don't mind MVC in the framework, but I am
wary
> of exposing it such that user code has to do MVC. While powerful and quite
> standard these days, I still think that it is conceptually difficult to
> grasp and can make simple projects difficult because of extra planning
> required to do MVC right, but I'm an MVC newbie so what do I know? This
> really deserves its own thread. I'll get back to this later today or
> tomorrow.

My experience is that MVC is very difficult for newbies to grok, but very
powerful for those who do understand it.  If PC is to be a tool to help give
newbies and part-timers a leg up with Python and GUIs then I don't think it
should be MVC.  That's not to say that it shouldn't be there behind the
scenes for those that can handle it, but it shouldn't get in the way of
those who can't or don't want to.

--
Robin Dunn
Software Craftsman
ro...@Al...       Java give you jitters?
http://wxPython.org      Relax with wxPython!

Re: [Pythoncard-users] Kevin's PythonCard goals

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

Kevin Altis wrote:

> In no particular order and with as much rambling as I can muster ;-), here
> are some of my goals for what we're currently calling PythonCard. I'll
> expand on some of these issues in other emails. Comment please.
> 
> A GUI application framework written in Python and using Python as the
> scripting language for building apps.
> Among other things this means that in HyperCard terms we aren't creating a
> HyperTalk (xTalk) language clone. For a Python user it means that to
> effectively use PythonCard they will need some familiarity with object
> oriented programming. They will need to understand classes, objects,
> methods, functions and the differences between them, at least in terms of
> Python. The good news is that object oriented programming doesn't get much
> easier than it does in Python. It lacks the discipline of strongly typed
> languages so you can really create a mess if you want or accidentally, but
> the power is there, so you just have to be pythonic and go with the flow.
> 
> Ability to leverage existing Python libraries with a minimal of fuss
> This includes being able to put simple GUI front-ends on command-line tools
> and interfacing to well understood Python libraries like NumPy and PIL, etc.
> 
> Simple apps should be simple and easy to build
> I'm willing to give up some flexibility and power if it makes smaller apps
> dramatically easier to build and maintain. I've stated this before, but
> almost every sample application was done in anywhere from less than an hour
> to an afternoon of work and a lot of that time was often spent on layout.
> Later modifications were simple incremental additions, not rewrites. The
> current framework is not a traditional Rapid Application Development (RAD)
> tool, but because of the power and simplicity of Python it has enabled me to
> make some useful stuff with very little planning. When I look at books that
> spend hundreds of pages doing nothing but toy apps in tkinter it makes me
> sad.
> 
> Cross-platform
> I still think a cross-platform solution is the right thing to do, though it
> puts some pretty severe limitations on exploiting the richness of the
> underlying OS. I'm specifically talking about the major desktop OS
> platforms: Windows (98/ME/NT/2K/XP), Windows 3.1 and 95 are not worth
> supporting IMHO, Mac (Classic/OS X), and Linux. I'll add Solaris in there
> since wxPython already supports it. I'm also going on the assumption that
> there will be a Mac wxPython port soon and that we won't have to wait until
> next year. The wxMac port of wxWindows is getting a lot of attention right
> now on wx-dev.


> 
> wxPython
> More on this in another message. The short story is that I still don't know
> of any other cross-platform solution for Python that is as capable. If you
> want to make the argument for supporting tkinter, do so now. If I'm missing
> a different solution, please speak up as well. I'm not including Jython
> since I consider that a completely different type of solution space.
> 

Being a Java guy, and having seen how rich Swing is, I'm not so sure 
that wouldn't be a good solution for cross platform gui.  The standard 
Swing class library is pretty rich, and there are tons of Swing 
components out there.  Of course this would require knowing both Swing 
and Java to develop, and would require both Python and a Java Runtime 
Environment, so installation would be freakin' HUGE.

Doesn't it seem strange that people regularly install 50MB of runtime 
for a 20K app ;)


> Its the apps stupid
> I'm not really that interested in building a better mousetrap, aka the
> framework. My interest is really in having a great way of building apps in
> Python. Consequently, I would like to have something usable yesterday, not a
> year or two from now. When we started I promised that what we built along
> the way would be usable on its own even though it was just a prototype and I
> think that goal has been met. Any future work should be focused on results
> with incremental improvements. I'm probably not willing to spend a month or
> two designing a framework spec before starting to implement it, I'm just not
> a good designer, I like to take too many shortcuts.


I agree.  I'm backing off on the whole 'grand illusion/delusion' idea 
and want to work on someting more pragmatic.  We still need a well 
defined object model, but that's mostly just clarifying what we already 
have and making some refinements.


> Multimedia support
> This is a tough one because of the cross-platform issue. We can't use COM,
> do QuickTime, or play back MPEG and MP3s in a standard way. We can play WAV
> sounds files. The SDL library, which PyGame uses can play back some MPEGs
> and MP3s and I have had some discussions and done a few tests with Pete
> Shinners, the PyGame author, about how we might add those capabilities, but
> there is still a lot of work to do.


Man, I'm so tired of having to boot up my iMac to watch porn!  Just 
kidding ( really ;), why in the hell isn't QuickTime available on Linux 
yet?  Maybe with OSX being based on BSD there will be some movement in 
that area.


> Richedit control
> Like multimedia this is another toughie due to cross-platform issues. It
> turns out that under Windows, wxWindows/wxPython uses a control limited to
> 32K of text for wxTextCtrl. In order to get a 2GB text limit and styled text
> in the same control you have to specify the wxTE_RICH and wxTE_MULTILINE
> styles. However, under Linux the richedit control was coded specifically for
> wxGTK and does not use a native control or have all the features of the
> richedit DLL under Windows, so the wxWindows rich text API is extremely
> limited. Typically, people are directed towards Neil's Scintilla in its
> wrapped form if they want more control, but Scintilla, while nice for doing
> a text editor is not nice for simply mixing styled text in the same control.
> I have no idea what the wxMac situation will be. What I do know is that an
> additional layer of logic is going to be needed to make styled text simple
> and easy to use in wxPython. For speed reasons, whatever Python logic is
> added to make the rich text control more useful will probably have to be
> moved back to C++ at some point. Neil or Robin, please correct me on any
> mistakes above.
> 
> Separate GUI descriptions and layout from source code
> Mixing code and layout is not good. "Bad monkey, no banana!"


Righty ho :)


> Graphical layout tools for widgets, menus, etc.
> 
> Runtime shell for interactive programming and output
> 
> Interactive editing while the app is running with reloads if possible,
> otherwise a simple edit/run cycle.
> 
> Message Watcher
> For those of you that never used HyperCard this may seem dumb. I also know
> people that used HyperCard that never saw the point in the Message Watcher.
> Think of it as just another debugging tool. As soon as I had the first
> message watcher working in PythonCard I identified two event bugs in
> wxWindows/wxPython. Who knows how long those have been around? It is also a
> nice learning tool to see what is going on with events.
> 
> Native controls/widgets, so that apps look like native apps under each OS.


I would totally give this up for a rich gui toolkit like Swing.


> Helper classes in the framework
> Find, transparent storage of data and metadata. These classes should
> complement what is available in the underlying GUI toolkit, but not reinvent
> something that is available via the Python Standard Libraries or a common
> library such as NumPy.


Leveraging existing libraries is definitely a good thing, like Andy and 
Patrick are doing with Zope.


> 
> Direct manipulation instead of Model View Controller?!
> This is a separate thread. I don't mind MVC in the framework, but I am wary
> of exposing it such that user code has to do MVC. While powerful and quite
> standard these days, I still think that it is conceptually difficult to
> grasp and can make simple projects difficult because of extra planning
> required to do MVC right, but I'm an MVC newbie so what do I know? This
> really deserves its own thread. I'll get back to this later today or
> tomorrow.


There should be some kind of compromise here that will promote good 
software design without requiring a user to be some kind of OO god just 
to get a simple app up and running.  Thinking...


> Desktop apps are my focus
> However, if we can do something that will allow more integration with web
> solutions then that would be nice, but not at the expense of turning the
> framework/environment into yet another web applications template tool, etc.
> Python is not a full citizen in the browsers of today, so there is no point
> in pursuing that area. The one thing we should seriously consider, which
> Neil has brought up before is modeling our framework on the DOM, so that it
> would be simpler to share layouts and program flow. Who knows, maybe someone
> would even get inspired to write a Python to/from JavaScript translator if
> the document/application models were compatible.


As for me, I'm not interested in supporting browsers either.


> A component architecture
> At one point I thought we might be able to do this with XPCOM. Unless I'm
> missing something, XPCOM and PyXPCOM are comatose. I posted recently on the
> XML-RPC list about XML-RPC for local app to app communication and got a very
> disappointing response. The Mac has AppleEvents and Windows has COM and COM
> works extremely well and has been very successful. However, it is too hard
> of a problem for even a small developer group to tackle, so I'm not gonna
> waste much more time worrying about a cross-platform solution.


Something simple and elegant should do the trick.  We sure as hell can't 
reinvent COM/CORBA/XPCOM,etc.


> HyperCard as inspiration, not gospel
> I've used a lot of IDEs and just about every major OS available since 1979
> or so. For me, HyperCard was the environment that was the most pleasurable
> to program in and use to build stuff. Ultimately, its limitations killed it,
> but it was fun and if "you got it" then you could be extremely productive
> with it. I think that the combination of a scripting language and a simple
> environment were the reasons it worked well. If you wanted to build
> something beyond its capabilities then it could be trying, for one you can
> to resort to external commands and functions. I still like the name
> PythonCard, but another name might be more appropriate.


Losing the HyperCard aggage without losing the spirit might be good. 
Maybe we could leverage the concepts but not the metaphors ( Stack, 
Card, Background ).


> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

RE: [Pythoncard-users] hoping for more input - HyperCard references

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

> > I am one of those people knowing nothing about a Mac or HyperCard.
> > I tried to follow the link on the homepage to find out more about
> > HyperCard, but I gave up quickly. IIRC, there was more or less marketing
> rant.
> > Seems (if I am typical), that the name 'PythonCard' really scares people
> > away from this project?

FYI, I posted a message leading to useful HyperCard resources back in July
http://aspn.activestate.com/ASPN/Mail/Message/636299

Those links cover a lot of the major details, minus the marketing. Danny
Goodman, Dan Winkler and some other HyperCard pros are watching this list,
so it would be helpful if they chimed in on the "what was HyperCard and what
made it great" topic, but don't hold your breath. ;-)

ka

[Pythoncard-users] Kevin's PythonCard goals

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

In no particular order and with as much rambling as I can muster ;-), here
are some of my goals for what we're currently calling PythonCard. I'll
expand on some of these issues in other emails. Comment please.

A GUI application framework written in Python and using Python as the
scripting language for building apps.
Among other things this means that in HyperCard terms we aren't creating a
HyperTalk (xTalk) language clone. For a Python user it means that to
effectively use PythonCard they will need some familiarity with object
oriented programming. They will need to understand classes, objects,
methods, functions and the differences between them, at least in terms of
Python. The good news is that object oriented programming doesn't get much
easier than it does in Python. It lacks the discipline of strongly typed
languages so you can really create a mess if you want or accidentally, but
the power is there, so you just have to be pythonic and go with the flow.

Ability to leverage existing Python libraries with a minimal of fuss
This includes being able to put simple GUI front-ends on command-line tools
and interfacing to well understood Python libraries like NumPy and PIL, etc.

Simple apps should be simple and easy to build
I'm willing to give up some flexibility and power if it makes smaller apps
dramatically easier to build and maintain. I've stated this before, but
almost every sample application was done in anywhere from less than an hour
to an afternoon of work and a lot of that time was often spent on layout.
Later modifications were simple incremental additions, not rewrites. The
current framework is not a traditional Rapid Application Development (RAD)
tool, but because of the power and simplicity of Python it has enabled me to
make some useful stuff with very little planning. When I look at books that
spend hundreds of pages doing nothing but toy apps in tkinter it makes me
sad.

Cross-platform
I still think a cross-platform solution is the right thing to do, though it
puts some pretty severe limitations on exploiting the richness of the
underlying OS. I'm specifically talking about the major desktop OS
platforms: Windows (98/ME/NT/2K/XP), Windows 3.1 and 95 are not worth
supporting IMHO, Mac (Classic/OS X), and Linux. I'll add Solaris in there
since wxPython already supports it. I'm also going on the assumption that
there will be a Mac wxPython port soon and that we won't have to wait until
next year. The wxMac port of wxWindows is getting a lot of attention right
now on wx-dev.

wxPython
More on this in another message. The short story is that I still don't know
of any other cross-platform solution for Python that is as capable. If you
want to make the argument for supporting tkinter, do so now. If I'm missing
a different solution, please speak up as well. I'm not including Jython
since I consider that a completely different type of solution space.

Its the apps stupid
I'm not really that interested in building a better mousetrap, aka the
framework. My interest is really in having a great way of building apps in
Python. Consequently, I would like to have something usable yesterday, not a
year or two from now. When we started I promised that what we built along
the way would be usable on its own even though it was just a prototype and I
think that goal has been met. Any future work should be focused on results
with incremental improvements. I'm probably not willing to spend a month or
two designing a framework spec before starting to implement it, I'm just not
a good designer, I like to take too many shortcuts.

Multimedia support
This is a tough one because of the cross-platform issue. We can't use COM,
do QuickTime, or play back MPEG and MP3s in a standard way. We can play WAV
sounds files. The SDL library, which PyGame uses can play back some MPEGs
and MP3s and I have had some discussions and done a few tests with Pete
Shinners, the PyGame author, about how we might add those capabilities, but
there is still a lot of work to do.

Richedit control
Like multimedia this is another toughie due to cross-platform issues. It
turns out that under Windows, wxWindows/wxPython uses a control limited to
32K of text for wxTextCtrl. In order to get a 2GB text limit and styled text
in the same control you have to specify the wxTE_RICH and wxTE_MULTILINE
styles. However, under Linux the richedit control was coded specifically for
wxGTK and does not use a native control or have all the features of the
richedit DLL under Windows, so the wxWindows rich text API is extremely
limited. Typically, people are directed towards Neil's Scintilla in its
wrapped form if they want more control, but Scintilla, while nice for doing
a text editor is not nice for simply mixing styled text in the same control.
I have no idea what the wxMac situation will be. What I do know is that an
additional layer of logic is going to be needed to make styled text simple
and easy to use in wxPython. For speed reasons, whatever Python logic is
added to make the rich text control more useful will probably have to be
moved back to C++ at some point. Neil or Robin, please correct me on any
mistakes above.

Separate GUI descriptions and layout from source code
Mixing code and layout is not good. "Bad monkey, no banana!"

Graphical layout tools for widgets, menus, etc.

Runtime shell for interactive programming and output

Interactive editing while the app is running with reloads if possible,
otherwise a simple edit/run cycle.

Message Watcher
For those of you that never used HyperCard this may seem dumb. I also know
people that used HyperCard that never saw the point in the Message Watcher.
Think of it as just another debugging tool. As soon as I had the first
message watcher working in PythonCard I identified two event bugs in
wxWindows/wxPython. Who knows how long those have been around? It is also a
nice learning tool to see what is going on with events.

Native controls/widgets, so that apps look like native apps under each OS.

Helper classes in the framework
Find, transparent storage of data and metadata. These classes should
complement what is available in the underlying GUI toolkit, but not reinvent
something that is available via the Python Standard Libraries or a common
library such as NumPy.

Direct manipulation instead of Model View Controller?!
This is a separate thread. I don't mind MVC in the framework, but I am wary
of exposing it such that user code has to do MVC. While powerful and quite
standard these days, I still think that it is conceptually difficult to
grasp and can make simple projects difficult because of extra planning
required to do MVC right, but I'm an MVC newbie so what do I know? This
really deserves its own thread. I'll get back to this later today or
tomorrow.

Desktop apps are my focus
However, if we can do something that will allow more integration with web
solutions then that would be nice, but not at the expense of turning the
framework/environment into yet another web applications template tool, etc.
Python is not a full citizen in the browsers of today, so there is no point
in pursuing that area. The one thing we should seriously consider, which
Neil has brought up before is modeling our framework on the DOM, so that it
would be simpler to share layouts and program flow. Who knows, maybe someone
would even get inspired to write a Python to/from JavaScript translator if
the document/application models were compatible.

A component architecture
At one point I thought we might be able to do this with XPCOM. Unless I'm
missing something, XPCOM and PyXPCOM are comatose. I posted recently on the
XML-RPC list about XML-RPC for local app to app communication and got a very
disappointing response. The Mac has AppleEvents and Windows has COM and COM
works extremely well and has been very successful. However, it is too hard
of a problem for even a small developer group to tackle, so I'm not gonna
waste much more time worrying about a cross-platform solution.

HyperCard as inspiration, not gospel
I've used a lot of IDEs and just about every major OS available since 1979
or so. For me, HyperCard was the environment that was the most pleasurable
to program in and use to build stuff. Ultimately, its limitations killed it,
but it was fun and if "you got it" then you could be extremely productive
with it. I think that the combination of a scripting language and a simple
environment were the reasons it worked well. If you wanted to build
something beyond its capabilities then it could be trying, for one you can
to resort to external commands and functions. I still like the name
PythonCard, but another name might be more appropriate.

ka

FW: [Pythoncard-users] hoping for more input

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

-----Original Message-----
From: Thomas Heller [mailto:tho...@io...]
Sent: Friday, October 19, 2001 11:26 AM
To: Kevin Altis
Subject: Fw: [Pythoncard-users] hoping for more input



----- Original Message -----
From: "Thomas Heller" <tho...@io...>
To: "pythoncard-Users" <pyt...@li...>
Sent: Friday, October 19, 2001 8:11 PM
Subject: Re: [Pythoncard-users] hoping for more input


> I am one of those people knowing nothing about a Mac or HyperCard.
> I tried to follow the link on the homepage to find out more about
> HyperCard, but I gave up quickly. IIRC, there was more or less marketing
rant.
> Seems (if I am typical), that the name 'PythonCard' really scares people
> away from this project?
>
> Kevin has written up a lot of docs about the state of this project, which
> I have only skimmed...
> -----
> Since I'm a developer of anygui, I _have_ been interested in this project
> as far as my time allowed. I have several times looked at the screenshots,
> and always had the impression that PythonCard progresses pretty fast -
much
> faster than anygui.
>
> I've been playing with PythonCard some ten minutes yesterday
> (running the samples, reading the source).
>
> [Rowland Smith]
> > Renamed Stack to Application, ripped out all Stack-ish code which was
> > mostly unused ( getBackgrounds() etc. )
> >
> > Renamed Background to Window.  ripped out all Bacground-ish code which
> > was mostly unused ( getFirstCard(), getNextCard(), etc. )
>
> I should have known this before trying to understand PythonCard, it would
> have made much more sense to me. I wondered all the time about this stack
> and background stuff.
>
> Thomas
>

Re: [Pythoncard-users] hoping for more input

[Thomas H. <tho...@io...>]

I am one of those people knowing nothing about a Mac or HyperCard.
I tried to follow the link on the homepage to find out more about
HyperCard, but I gave up quickly. IIRC, there was more or less marketing rant.
Seems (if I am typical), that the name 'PythonCard' really scares people
away from this project?

Kevin has written up a lot of docs about the state of this project, which
I have only skimmed...
-----
Since I'm a developer of anygui, I _have_ been interested in this project
as far as my time allowed. I have several times looked at the screenshots,
and always had the impression that PythonCard progresses pretty fast - much
faster than anygui.

I've been playing with PythonCard some ten minutes yesterday
(running the samples, reading the source).

[Rowland Smith]
> Renamed Stack to Application, ripped out all Stack-ish code which was 
> mostly unused ( getBackgrounds() etc. )
> 
> Renamed Background to Window.  ripped out all Bacground-ish code which 
> was mostly unused ( getFirstCard(), getNextCard(), etc. )

I should have known this before trying to understand PythonCard, it would
have made much more sense to me. I wondered all the time about this stack
and background stuff.

Thomas

Re: [Pythoncard-users] hoping for more input

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

As an experiment, I downloaded the latest code from CVS and made the 
following changes:

Renamed Stack to Application, ripped out all Stack-ish code which was 
mostly unused ( getBackgrounds() etc. )

Renamed Background to Window.  ripped out all Bacground-ish code which 
was mostly unused ( getFirstCard(), getNextCard(), etc. )

Deleted navigation.py - this module was all about navigating stacks and 
backgrounds and was almost entirely unused.

Modified Application to load and show all Windows discovered in the 
application resource file.  I used samples/proof.py to test the changes 
and it works fine.  I know this isn't the desired behavior, we should 
load all defined windows, and only show those that are 'visible', and we 
need a window management module that the Application can use.

The motivation for trying this was reading all of the state of 
PythonCard docs that Kevin so kindly cranked out yesterday.  I realized, 
that by damn, we have a lot of good stuff there, and I decided to at 
least devote a few days to helping take it to the next level.

Talk to ya,
Rowland

[Pythoncard-users] hoping for more input

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

Writing all the "state of the framework" messages today wore me out, so I'll
post my thoughts on where we should be heading tomorrow. I really would like
to get more input from people other than "the usual suspects". If there
really isn't enough interest in the project to warrant some posts on this
topic then we need to take that in consideration as well. I was hoping that
more people would be interested.

Oh, I'm not giving up either Andy ;-)

ka

Re: [Pythoncard-users] the future direction of PythonCard

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

I am not qualified technically to have an opinion, so please disregard evrything I say if it does not apply or if it annoys. Still I
admire what you all are doing, especially Kevin, and I wish you the best. I'd lvoe to see PythonCard do great things, but I know I
probably can't contibute anything to it. With those caveats, here goes:

My interest has always been to see a very easy to learn and easy to use event driven GUI builder. When I was trying to choose
between wxPython and Tkinter, someone brought up the idea of HyperCard. Although I never owned a Mac and therefore never used
HyperCard, I was generally aware of it and had a good impression of it. PythonCard seemed like a great idea.

I have used the PythonCard prototype, primarily to try to create a GUI version of a simple program I wrote in Python called Decision
Analysis, which can be found at http://www.awaretek.com/Decision_Analysis_Beta27.py but which I have updated and cleaned up a lot
but not posted yet to my webswite, so I will attach that code at the end of this message.

Well, in playing around with PythonCard in order to create a GUI version of Decison Analysis, I began to study wxPython and then
Tkinter a little more, to the point where I think I could now do a gui version of Decision Analysis in Tkinter easier than I could
in PythonCard (at this stage of PythonCard).

The reason being that, to me, at its current stage, PythonCard seems more complicated than wxPython or Tkinter. And with Tkinter
being so well documented, it would be the easiest for me. And I wouldn't have to use resource files at all, which to me only
complicate things. I assume that when PythonCard is finished, including documentation of some sort and an "environment" it will be
easier and better for me.

On top of that for now, I am all of a sudden consumed in my hobby-dom more by writing an "major " ;-))) extension of Decision
Analysis that answers questions of fact by making web queries using Pythons url libraries and the re module for regular expressions.

Which brings up a point: The reason I love programming in Python is becauase I can remember the syntax more or less completely, even
as a weekend duffer, and just code things that are interesting to me. I think there are potentially millions (OK , at least hundreds
of thousands) of folks like me, in that they will program for the love of it, but not if the programming tools require more "drudge"
work than they are worth. So what the world needs, I think, is a "python" for gui event driven programs. I hope PythonCard can be
that.

I have never really used VB, although I did buy version 1.0 years ago; but it was not all that inviting at that time. I have never
used Delphi/Kylix. So I guess you can say that I have almost no gui programming experience at all. I have played around with Boa and
I like it; but it does not yet meet my desire for a "python" like gui programming expereince.

Can PythonCard be a "python" like easy to learn and use gui programming tool? I can't resist showing my ignorance by speculating:

1. Visual Basic and Delphi and even Boa Constructor are one class of very visual gui programming tools, let's say. But Boa is
already attempting this for Python, so why should anyone duplicate it? Besides, Kevin, your stated dislike for code generators tends
to work against this sort of approach. Besides, Boa seems over complicated anyway.

2. HyperCard, as I imagine, in my ignorance, it must be, seems to be another kind of visual programming tool. An awful lot of folks
who used it loved it, so it had something going for it. While I never used it, I find the general idea of a card like metaphor
appealing. (As an aside, I still use an old M$ windows 3.0 applet called cardfile as a roll o dex type database of business
contacts, phone numbers etc. Everybody knows how to use a rolodex)

How would a HyperCard like PythonCard work?

a. Could it use a metaphor in which each card was an object? That seems simple and appealing to me, but I have no idea if it make
sense; and would it require mixing data with code? Not necessarily, because each card could contain its own widgets, including their
associated event-handlers; but the whole stack of cards comprising a program could be scripted by one master Python program.

b. Alternately, could each card be a Class?

I guess I like (a.) better, but anyway using a HyperCard like metaphor would sure be nice.

3. Or,  one could avoid the visual metaphor entirely. After all, Python itself is not Visual and it certainly meets my criteria for
ease of learning/use. Who says a command-line gui programming tool could not be the easiest and best of all? Truthfully, in my
ignorance, I don't see why this could not be done. Just give me simple widget names, event names and definitons, etc.

Ideally, I could envison a PythonCard that used both (2) and (3) of my above options in combination; that is, a hyperCard like
visual metaphor combined with a truly good command line python-like tool.

Most of all, it should be consistent and make sense intuitively.

But, if there is no HyperCard like metaphor at all, maybe the name should be change. I do think names are important, by the way. But
if a card like metaphor of any kind is used, I would suggest keeping the PythonCard name, which I really like.

Finally, I am sure you are going to create somethng great, Kevin. If the great thing you create happens to be an easier to learn/use
gui creator than wxPython, I am pretty sure I'll be using it and enjoying it.

Oh, one other thing; I think wxPython is the right base for PythonCard. It was the best choice. Why ry to support more than one gui
foundation, it will only create alot of extra work?

Finally, and most importanly to me, if there is any one idea I would like to contribute or endorse or back up, it is this. I hope
that Kevin can get a lot of help. And I think one best way, I am hoping anyway, is for some one or few coders can join in to focus
on the highest level programming environment or IDE aspect of PythonCard. cp...@em... (Chris Ryland) spoke up recently and
expressed an interest in possibly coding a Real Basic like Python tool. If he could be coaxed into joining up with PythonCard and
focus almost exclusively on the high end environment, wouldn't that be great? Why do another visual tool like Boa. Maybe Cris Barker
could also join in.

Most of all, it should be consistent and make sense intuitively.

A Tall order, no doubt!!! ;-)))))

Ron Stephens

P.S. What one thing would I most like to see done next? ...a High End easy to use programming environment of some sort.


Decision Analysis:

print "A General Decision Analysis Program."
print
print "Have You Ever Had to Make Up Your Mind?"
print

import sys

def get_number(prompt, lower=sys.maxint * -1, upper=sys.maxint):
        """ get_number(prompt) -> float

This function prompts for a number.  If the user enters bad input, such as
'cat' or '3l', it will prompt again.
Now checks for upper and lower bounds.
"""
        res = None
        while res is None:
                try:
                        res = float(raw_input(prompt))
try:
assert lower <= res <= upper
except AssertionError:
print "Value must be between", lower, \
      "and", upper
res = None
                except ValueError: pass


        return res


def get_list(heading, prompt):

        print heading
        print
        print "(enter a blank line to end the list)"
        ret = []
        i = 1
        while 1:
                line = raw_input(prompt % i)
                if not line:
                        break
                ret.append(line)
                i=i+1
        print
        return ret

def get_user_rankings(criteria):
    # Next, get the user to rank his criteria.  I use a system where higher
    # is better, so that an undesirable characteristic can be given a negative
    # weight.
    #
    # {} is a dictionary, it can be indexed by (nearly) any expression,
    # and we will index it with the names of the criteria.

    rankings = {}
    print
    print "Enter relative importance of criteria (higher is more important)"
    print
    for c in criteria:
        rankings[c] = get_number("Criterion %s: " % c)
    return rankings

def get_user_scores(options, criteria):
    # Next, get the user to score each option on all the criteria.
    # Scores are stored as a two-dimensional dictionary, like so:
    # {'option1': {'criteria1': 100, 'criteria2': 10},
    #  'option2': {'criteria1': 50, 'criteria2': 10}
    # }
    scores = {}
    print
    print "Enter score for each option on each criterion"
    print
    for o in options:
        scores[o] = {}
        print
        print "Scores for option %s" % o
        print
        for c in criteria:
            scores[o][c] = get_number("Criterion %s: " % c)
    return scores

def calculate_results(options, scores, rankings):
    # Calculate the resulting score for each option.  This equation
    # is different from Rod Stephen's original program, because I
    # make more important criteria have higher rankings, and even let
    # bad criteria have negative rankings.

    # The "result" dictionary is indexed with the names of the options.
    result = {}
    # Criteria can be found automatically, doesn't need to be
    # passed as an argument.
    criteria = scores[options[0]].keys()
    for o in options:
        value = 0
        for c in criteria:
            # print o, c, rankings[c], scores[o][c]
            value = value + rankings[c] * scores[o][c]
            result[o] = value
    return result

def ranked_list(results):
    # Now, I want to take the dictionary result, and turn it into a ranked list

    results = results.items()        # A list of tuples (key, value)
    results.sort(lambda x, y: -cmp(x[1], y[1]))
                                # Sort the list using the reverse of the
                                # "value" of the entry, so that higher
                                # values come first
    return results


def generic_decision_analyzer(options, criteria):
    pass

def decisionanalysis():
    # This code is placed in the public domain
    print
    print "This is a general decision program, and you can define your choices and criteria."
    print
    print "When prompted, please enter the options or choices that you need to decide amongst."
    print
    print "Then, when prompted, enter the criteria for making this decision."


    # First, ask the user to enter the lists
    options = get_list("Enter your options:", "Option %d: ")
    criteria = get_list("Now, enter your criteria:", "Criterion %d: ")

    print "A program to help you make decisions."
    rankings = get_user_rankings(criteria)
    scores = get_user_scores(options, criteria)
    results = ranked_list(calculate_results(options, scores, rankings))
    print
    print "Results, in order from highest to lowest score"
    print
    print "%5s\t%s" % ("Score", "Option")

    # Take the pairs out of results in order, and print them out
    for option, result in results:
            print "%5s\t%s" % (result, option)



# Here's the scores used by the language-choice functions.
language_scores = {"Python": {"ease of learning":100,
                              "ease of use":100,
                              "speed of program execution":10,
                              "quality of available tools":70,
                              "popularity":50,
                              "power & expressiveness":100,
                              "cross platform?":100,
                              "cost":100},
                   "Perl": {"ease of learning":50,
                            "ease of use":60,
                            "speed of program execution":20,
                            "quality of available tools":50,
                            "popularity":85,
                            "power & expressiveness":70,
                            "cross platform?":100,
                            "cost":100},
                   "Ruby": { "ease of learning":50,
                             "ease of use":100,
                             "speed of program execution":20,
                             "quality of available tools":20,
                             "popularity":10,
                             "power & expressiveness":100,
                             "cross platform?":80,
                             "cost":100},
                   "Tcl": {"ease of learning":100,
                           "ease of use":100,
                           "speed of program execution":10,
                           "quality of available tools":50,
                           "popularity":40,
                           "power & expressiveness":10,
                           "cross platform?":100,
                           "cost":100},
                   "JavaScript": {"ease of learning":70,
                                  "ease of use":75,
                                  "speed of program execution":10,
                                  "quality of available tools":50,
                                  "popularity":100,
                                  "power & expressiveness":40,
                                  "cross platform?":50,
                                  "cost":100},
                   "Visual Basic": {"ease of learning":50,
                                    "ease of use":100,
                                    "speed of program execution":20,
                                    "quality of available tools":100,
                                    "popularity":100,
                                    "power & expressiveness":50,
                                    "cross platform?":1,
                                    "cost":1},
                   "Java": {"ease of learning":15,
                            "ease of use":50,
                            "speed of program execution":50,
                            "quality of available tools":100,
                            "popularity":90,
                            "power & expressiveness":100,
                            "cross platform?":100,
                            "cost":100},
                   "C++": {"ease of learning":10,
                           "ease of use":25,
                           "speed of program execution":90,
                           "quality of available tools":90,
                           "popularity":80,
                           "power & expressiveness":100,
                           "cross platform?":90,
                           "cost":100},
                   "C": {"ease of learning":15,
                         "ease of use":20,
                         "speed of program execution":100,
                         "quality of available tools":80,
                         "popularity":80,
                         "power & expressiveness":80,
                         "cross platform?":110,
                         "cost":100},
                   "Lisp": {"ease of learning":40,
                            "ease of use":50,
                            "speed of program execution":80,
                            "quality of available tools":60,
                            "popularity":25,
                            "power & expressiveness":110,
                            "cross platform?":80,
                            "cost":90},
                   "Delphi": {"ease of learning":50,
                              "ease of use":110,
                              "speed of program execution":85,
                              "quality of available tools":100,
                              "popularity":30,
                              "power & expressiveness":100,
                              "cross platform?":80,
                              "cost":10}
                   }



def ProgramLanguageFinal():
    print "This is a program to help give you an idea which programming languages you should consider learning."
    print "While there are any number of languages you might consider, this program considers only 11 of the most popluar ones."
    print
    print "The program will ask you to input a ranking or weighting for a number of criteria that may be of importance"
    print "in choosing your next programming language."

    # First look up the criteria listed in the scores.
    # To do that, we need a language name, which can also
    # be looked up from the scores.
    languages = language_scores.keys()
    some_language = languages[0]
    criteria = language_scores[some_language].keys()
    rankings = get_user_rankings(criteria)
    results = ranked_list(calculate_results(languages, language_scores, rankings))
    # Take the pairs out of results in order, and print them out
    for option, result in results:
            print "%5s\t%s" % (result, option)


def ProgramLanguageScript():
    print
    print "This is a program to help you choose a scripting language."
    print
    print "You will be asked to rank some important criteria as to their relative importance to you."
    print "These criteria are 'ease of learning', 'ease of use', 'speed of program execution'"
    "'quality of available tools', 'popularity', and 'power & expressiveness'"
    print
    print "Please rank each of the criteria with a number from 1 to 100 when prompted."
    print
    print "100 means of highest relative importance, 1 means of least importance."

    # This time we want a subset of languages, so I'm going to specify them.
    options = ["Python", "Perl", "Ruby", "Tcl", "JavaScript", "Visual Basic"]
    criteria = language_scores[options[0]].keys()
    rankings = get_user_rankings(criteria)
    results = ranked_list(calculate_results(options, language_scores, rankings))
    # Take the pairs out of results in order, and print them out
    for option, result in results:
            print "%5s %s" % (result, option)


def Basketball():
    print "This is a program to help you decide which team will win a basketball game"
    print
    print "When prompted, enter a number ranking each team on the prompted team skill"
    print "on a scale from 1 to 100, with 1 being terrible and 100 being the best imaginable"
    print
    team_one = raw_input ("What is the name of team one: ")
    team_two = raw_input ("What is the name of team two: ")
    teams = (team_one, team_two)

    rankings = {"speed":100, "size":66, "jumping_ability":50, "defense":60, "shooting":75, "ballhandling":50, "rebounding":50}
    criteria = rankings.keys()
    scores = {team_one: {},
              team_two: {}}
    for c in criteria:
        for team in (team_one, team_two):
            scores[team][c] = get_number("rank the team %s of %s on a scale of 1 to 100: " % (c, team), 1, 100)

    results = calculate_results(teams, scores, rankings)
    for team in teams:
        print "%s has a power ranking of %d" % (team, results[team])
    # Now, who won?
    ranked_results = ranked_list(results)
    # Compare the scores.
    if ranked_results[0][1] == ranked_results[1][1]:
        print "the two teams are a toss-up!!!"
    else:
        print "%s wins!!" % ranked_results[0][0]


def YesNo():
    print "Program to help you make a Yes or No decision."
    options = ["Yes", "No"]
    criteria = get_list("Enter your criteria ...", "Criterion %d: ")

    rankings = get_user_rankings(criteria)
    scores = get_user_scores(options, criteria )
    print `scores`
    results = ranked_list(calculate_results(options, scores, rankings))
    print
    print "The results are"
    print
    print "%5s %s" % ("Score", "Option")

    for option, result in results:
            print "%5s %s" % (result, option)

    if results[0] > results[1]:
            print "You should decide Yes!!!"

    else:
            print
            print "You should decide No!!!"
            print


###### MAIN LOOP ############

while 1:    # loop forever

    print "Please enter the number for the type of decision you wish to analayze:"
    print "1. General Decision Analysis, you choose the options, criteria, etc."
    print "2. Help in Choosing Programming Language amongst 11 popular languages"
    print  "3. Help in choosing scripting programming language amongst 6 scripting languages"
    print  "4. Which Basketball Team will win the Game???"
    print  "5. Questions with Yes or No type answers"
    choice = get_number("Please type in the number of the type of decision-program you wish to run from above and hit enter:", 1, 5)

    if choice ==1:
        decisionanalysis()
    elif choice ==2:
        ProgramLanguageFinal()
    elif choice ==3:
        ProgramLanguageScript()
    elif choice ==4:
        Basketball()
    elif choice ==5:
        YesNo()
    elif choice =="quit":
        break    # exit from infinite loop
    else:
        print "Invalid operation"

[Pythoncard-users] state of the framework - events and handlers

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

Rowland should probably be the one describing the prototype event model, but
I'll cover the main points from a user point of view.

I listed most of the events supported by PythonCard widgets in an earlier
message, but here they are again:
  gainFocus
  loseFocus
  mouseContextDoubleClick
  mouseContextDown
  mouseContextUp
  mouseDoubleClick
  mouseDown
  mouseDrag
  mouseEnter
  mouseLeave
  mouseMiddleDoubleClick
  mouseMiddleDown
  mouseMiddleUp
  mouseMove
  mouseUp

The most common events you see in the samples are not the ones above, but
these:
  command
  mouseClick
  openBackground
  select

Every widget and menu can have an associated command event. As an example,
here's a menu item definition from addresses.rsrc.py that uses 'command' and
the associated handler.

    { 'type':"MenuItem",
      'name':"menuEditNewCard",
      'label':"&New Card\tCtrl+N",
      'command':'editNewCard'},

    def on_editNewCard_command(self, target, event):
        self.newRecord()

All widget and menu event handlers take the form

  on_commandName_command
or
  on_widgetName_eventName

more examples...

    def on_menuFileExit_select(self, menu, event):

    def on_btnColor_mouseClick(self, target, event):

    def on_bufOff_mouseDrag(self, target, event):

The underscores are used by the framework to identify a handler method and
they have the added benefit of making the handlers stick out from other
methods in the user code. All events go first to the target of the event and
if they aren't handled, then the framework searches for a match at the
background or stack level. We aren't doing stack events yet, but the
tictactoe sample shows an example of using a background handler for
mouseClick events. It is also common to have an openBackground event such as

  def on_openBackground(self, target, event):

which can be used to perform app initialization (in the prototype framework
it is more like the HyperCard openStack system message).

The handler method arguments (self, target, event) are just names, so like
any other Python program you can use what names you want, but for
readability it is better to use self and event and something description
like menu and target depending on the handler type. The 'target' is the
actual widget target, which simplifies manipulating the widget. For example:

    def on_bufOff_mouseDrag(self, target, event):
        x, y = event.getNativeEvent().GetPosition()
        target.line(self.x, self.y, x, y)
        self.x = x
        self.y = y

bufOff is a BitmapCanvas and line is one of its methods. Another thing to
notice about the example above is that it was necessary to use the method
getNativeEvent to get the coordinates of the event. This is because while
wxPython events are wrapped by PythonCard, virtually none of the information
available in the raw/native event is wrapped at this point. In some cases
there is not a corresponding wxPython event class. The wrapping is
non-trivial and will take a fair amount of time to get right.

There was a method for posting events not generated internally by wxPython,
but it is not currently used and probably needs to be refactored.

There are no events in the prototype for window positioning and resizing,
activating or exiting the app, idle or timer events.

ka

[Pythoncard-users] state of the framework - general concepts and limitations

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

Environment
There is not an Integrated Development Environment (IDE) for PythonCard. The
stated intent all along was to build a framework and then later build an
environment on top of the framework that represents the best aspects of
other environments like HyperCard, Visual Basic, Delphi, etc.

I digress...
I will reiterate what Andy stated earlier that KISS should be of primary
importance. That goes beyond the current state of the framework topic of
this message, but the KISS motto got us to where we are now. Dan Winkler has
told me in the past that one of Bill Atkinson's (QuickDraw, MacPaint,
HyperCard, etc.) strengths was knowing when to NOT add a feature. If you
think keeping things simple is easy, look at the vast majority of complaints
normal users have about using Windows or Unix or even the Mac these days.
Look at the bloat that has ruined almost every application I can think of.

My own bias is that shorter programs are simpler to write and maintain, the
exception being code written in Perl which is unreadable at any length. I
much prefer multiple highly focused apps with short learning curves to one
big multi-purpose app.
...end of digression

I would also like to support building apps with the framework without using
the environment since that will appeal to a large number of Python users.
The complication of working outside an environment is that the
user/programmer is responsible for keeping resources, source code, and
application data synchronized and there is more room for user/programmer
mistakes with names/ids.

Ids
All objects in PythonCard have a name that is unique at a given level of the
component hierarchy. The name is used as the unique id by the framework
internally and almost all references are done via a dictionary lookup, so
they are both fast and simple to use. Numerical object ids are not exposed
to the user code.

The widgets themselves are kept in a dictionary called 'components' that has
some dot notation capabilities. See the earlier message about widgets or any
of the sample apps for examples of using the background components
dictionary.

Widget tab traversal and order
The widget tab traversal order is determined by the order the widget
components are defined in the resource file. The first widget defined in the
list is the first widget tabbed to and it will always be front of the
second, third, etc. widgets if the widgets overlap. Look at any resource
file and then observe the behavior when you run the app. The resourceEditor
is a good way to experiment with how overlapping widgets look and behave.

Printing
There is no support for printing in the prototype.

Windows
There is currently support for only one app window (other than modal dialogs
that sit on the app window). In addition, the app window has only one style
and does not support scrolling. Internally, the Background class is the main
app window. In wxPython terms it is a wxFrame that contains a wxPanel. The
wxPanel provides the automatic tab traversal for widgets inside the window.

PythonCard prototype apps are rough equivalents of single card, single
background, HyperCard stacks. There is no transparent persistent storage
mechanism in the framework. Some of the samples do provide their own storage
mechanisms and the intent of the samples is to explore a way to generalize
at least a class or set of classes with get/set record and get/set field
that can be used by any PythonCard app. By making the access fairly generic
we're hoping that a variety of backend solutions could be plugged in rather
than requiring one particular solution such as ZODB.

Given that we are at the prototype stage there are more limitations than
there are features. Andy has already pointed out the lack of multiple
windows. If you simply look over the "classes by category" in the
wxWindows/wxPython documentation, you'll see that there is a huge amount of
functionality we haven't even begun to leverage.

wxPython
In some cases, limitations in PythonCard are caused by limitations in
wxWindows/wxPython. It is also true that PythonCard issues are often really
wxWindows issues and it is necessary to stay abreast of wxWindows and
wxPython if you want to do more than the simplest PythonCard apps. I have
been frustrated lately enough to consider doing something that only worked
on Windows, so that I could make use of the MFC and COM directly. However,
after a breather I come back to the desire to have something that works
across platforms and so I'm willing to put up with the limitations and extra
work imposed by that requirement.

The prototype framework attempts to hide wxPython from user code. The only
time wxPython is exposed is where a feature is not currently available in
the PythonCard framework. If a sample has "from wxPython.wx import *" then
direct access was necessary. This is typically how new features are tested
prior to being added to the framework. One interesting aspect of how
PythonCard works now is that it in many cases it is easy to intermingle
wxPython and PythonCard code, so from that standpoint PythonCard can be seen
as a way of simplifying the use of wxPython.

tkinter
I'm not a tkinter expert, but I think we are already providing a large
portion of the functionality available with tkinter. Please feel free to
list the tkinter items we're missing that seem the most important to you.

ka

[Pythoncard-users] state of the framework - menus and dialogs

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

The Menu classes are defined in menu.py. Menus for an app are defined in the
resource file, but they are optional. The worldclock sample shows an app
without a menubar. It may be possible to add and remove menus and menu items
at runtime, but I have never tried this. The last time I worked on menu.py
to add enable/disable and check/uncheck I decided it needed a rewrite was in
order ;-)

There is no support for hierarchical menus, graphics or multiple fonts in a
menu. You can enable/disable and check/uncheck menu items. In addition, menu
items can have an associated command which can then be bound to any number
of other menu items or widgets. See the textIndexer and addresses samples.
The simplest way to understand the use of the menus is to look at all the
samples resource files and code. When a menu item is selected it generates a
'select' event.

A bug in wxPython 2.3.1 prevents accelerator keys (Ctrl-C, Ctrl-X, Ctrl-V,
etc.) from working, but the bug is fixed in the wxPython 2.3.2 beta.


Dialogs are defined in dialog.py. They are all modal and map directly to a
wxPython class, which map to an underlying OS dialog where available. The
one exception is the FindDialog which I coded from scratch.

AlertDialog           (variation of MessageDialog)
ColorDialog           (wxColourDialog)
DirectoryDialog       (wxDirDialog)
FileDialog            (wxFileDialog)
FindDialog
FontDialog            (wxFontDialog)
MessageDialog         (wxMessageDialog)
ScrolledMessageDialog (wxScrolledMessageDialog)
TextEntryDialog       (wxTextEntryDialog)

Some options are specified via constants, see dialog.py for a full list as
well as the dialog sample which shows the various dialogs in use.

The GenericDialog class which I did this last week has not been checked into
cvs yet. If we decide to use it or a slight variation, then we will be able
to do modal dialogs using the same widgets and layout mechanisms and event
handlers as we use for backgrounds.

There are no modeless dialogs and discussions I've had with Rowland about
this topic concluded that there is not much point to the term 'modeless
dialog' since in PythonCard there wouldn't be much difference from a regular
background. More on that topic later.

ka

[Pythoncard-users] Possible Project Idea

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

Here is an idea that might help us focus and determine the direction for
further PythonCard development. The key to the idea is to start with the end
in mind. By that I mean, let's start with a description of what we want to
end up with and work backwards to see what we have to accomplish to achieve
that end.

As I see it, the end that most people seem to want is a tool that lets them
easily create simple GUI applications that manage information without having
to know much about GUIs or databases or even programming. What does this
imply?

* Some kind of visual screen builder.

* Some kind of persistent data storage.

This also implies that some things are less important. For example, support
for multiple GUI toolkits would be nice, but users would be happy with just
wxPython as long as it was made easy. Storing widget definitions in a
resource file is nice, but users would rather not even see that, let alone
care about how the resource file is formatted or whether it is XML or not.

With this in mind, I think we need to keep ourselves focused on the goal,
and not get too sidetracked by things like the format of the resource file.
Especially since we have no easy persistent data storage mechanisms that
allow an app to have multiple windows/screens/records, and we have only the
beginning of a visual screen builder.

So if the goal is simple visual construction of screens that access
transparently persistent data, I'd like to suggest that we embark on a joint
effort to create such an application from scratch, using the tools that we
have so far in PythonCard, as a way to flesh out further requirements. The
development of this sample application could even be documented as a
tutorial for others.

If there is interest in this idea, here is what I think needs to happen:

1. Decide on a sample application that reflects the kind of app people would
have done in HyperCard.

2. Decide how we are going to store the data - CSV, ZODB, XML, MySQL, etc.

3. Develop the app in a collaborative fashion to get feedback from more than
one person.

4. Document as much as possible so that this serves as a tutorial of sorts.

5. Repeat for the next app until PythonCard is perfect.

How does this idea grab everyone else? Good, bad, indifferent?

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

[Pythoncard-users] state of the framework - runtime tools

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

PythonCard supports the following runtime tools (command-line switch in
parens).
  Log              (-l)
  Message Watcher  (-m)
  Namespace Viewer (-n)
  Property Editor  (-p)
  Shell            (-s)

The Log facility is defined in log.py. The other runtime tools or their
wrappers are in debug.py. All of the runtime tool windows are children of
the parent app window, so they don't show up on the taskbar. In addition, if
one of the windows is created at startup, then all of the tools are
initialized and available via the Debug menu, otherwise they are not
initialized or available and apps don't incur any startup or memory overhead
from the runtime tools.

All of the runtime windows are done in raw wxPython and their events will
not interfere or show up in the main app event loop. It would be preferable
for the windows to be defined just like other PythonCard
backgrounds/windows, to simplify controlling them from a PythonCard app and
to help with their longer-term maintenance.

The runtime tool window positions, sizes, and whether they are shown by
default is defined in the pythoncard.config.py file or the
pythoncard.user.config.py file if you've saved the settings from the Debug
menu.

You can redirect stdout (print statements) to the shell and back to the
console at any time while an app is running.

The Namespace Viewer and Shell are provided by PyCrust and not part of the
PythonCard framework. The Namespace Viewer shows the local application
namespace. I'll let Patrick go into more detail if he has the time.

The Message Watcher shows all of the events generated and handled by widgets
in PythonCard. Unused events are shown in parens (). Idle events are not
currently generated by the framework, so they are not shown.

The Property Editor allows editing of widget attributes (properties). Only
those attributes that are read-only can't be changed and usually that is
because the attribute can only be set during initialization. The Property
Editor is the key part of the resourceEditor sample.

The Shell is an application in itself, so again I think I'll let Patrick
chime in here if he wants. With a basic application defined, you can then do
just about anything you want from the shell. The shell automatically load a
series of commands such as:

>>> bg = pcapp.getCurrentBackground()
>>> comp = bg.components

by placing the commands in a pycrustrc.py file in the app directory (see the
turtle sample). There have been numerous messages on the list showing how to
add and interact with widgets at runtime. You can also define methods at
runtime, which is shown here:
http://aspn.activestate.com/ASPN/Mail/Message/770015

The Shell supports command-completion and tool tips, so it is very nice for
interactive programming, learning and testing PythonCard. Again, the turtle
sample is a good example of using the shell. Since the shell is provided via
PyCrust, most of these features aren't limited to just PythonCard, but
PythonCard probably makes the most and best use of PyCrust right now.

ka

Re: [Pythoncard-users] the future direction of PythonCard

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

Patrick K. O'Brien wrote:

> I'm confused. These goals sound more like what anygui is attempting than
> what I thought PythonCard was all about. At the very least they sound like a
> back-to-the-drawing-board approach. I don't think I have the energy for
> that.



Good point.  I know Kevin is in need of scaling things back so he can 
make more  progress producing something that will allow him to write the 
kind of apps he's interested in.

I'm definetely looking for something that's going to take a lot more 
time than anyone has right now.  And I can't say exactly what I'd like 
to see as an end product.


I still think we should treat the prototype as just that, and at least 
come up with some minimal model that will let just a few people make 
some good progress without burning too much time.

Kevin, what's the biggest problem with the wrappers slowing you down?


> 
> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
> 
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Rowland
> Smith
> Sent: Thursday, October 18, 2001 12:59 PM
> To: po...@or...
> Cc: pythoncard-Users
> Subject: Re: [Pythoncard-users] the future direction of PythonCard
> 
> <snip>
> 
> So, what would I want in an application development environment?
> 
> 1. A well defined component model that allows for flexible extension of
> the overall framework.
> 
> 2.  A high-level, well defined gui component model that can be
> implemented using one or more underlying gui toolkits - wxPython, GTK,
> Aqua, etc.  The gui wrappers take a lot of time, but they make us think
> about how we really want to interact with gui components and give us the
> freedom to expose those behaviors and attributes that we feel are
> valuable in our own way.
> 
> 3.  A component communication model.  The prototype uses events to
> communicate between components ( Widget objects ) and user scripts.  But
> we really don't have a way for components to communicate with components
> - I'm not sure how to do that, but it seems important.
> 
> 4.  A flexible scripting framework that allows us to plug in different
> scripting models for different classes of application.  We currently use
> a scripting model similar to VB ala method naming conventions.  It's
> possible we could have multiple scripting models - one could be more
> Model-view-controller based.  One could be based on action objects, etc.
> 
> Oh yea, and Multiple Windows ( seriously ).
> 
> --
> Talk to ya,
> Rowland
> 
> "The whole problem with the world is
> that fools and fanatics are always so
> certain of themselves, and wiser people
> so full of doubts."
> 
> -- Bertrand Russell,
>     quoted in the book
>     A Word a Day
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 
> 



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

RE: [Pythoncard-users] the future direction of PythonCard

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

I'm confused. These goals sound more like what anygui is attempting than
what I thought PythonCard was all about. At the very least they sound like a
back-to-the-drawing-board approach. I don't think I have the energy for
that.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Rowland
Smith
Sent: Thursday, October 18, 2001 12:59 PM
To: po...@or...
Cc: pythoncard-Users
Subject: Re: [Pythoncard-users] the future direction of PythonCard

<snip>

So, what would I want in an application development environment?

1. A well defined component model that allows for flexible extension of
the overall framework.

2.  A high-level, well defined gui component model that can be
implemented using one or more underlying gui toolkits - wxPython, GTK,
Aqua, etc.  The gui wrappers take a lot of time, but they make us think
about how we really want to interact with gui components and give us the
freedom to expose those behaviors and attributes that we feel are
valuable in our own way.

3.  A component communication model.  The prototype uses events to
communicate between components ( Widget objects ) and user scripts.  But
we really don't have a way for components to communicate with components
- I'm not sure how to do that, but it seems important.

4.  A flexible scripting framework that allows us to plug in different
scripting models for different classes of application.  We currently use
a scripting model similar to VB ala method naming conventions.  It's
possible we could have multiple scripting models - one could be more
Model-view-controller based.  One could be based on action objects, etc.

Oh yea, and Multiple Windows ( seriously ).

--
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day


_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] state of the framework - resource files

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

Resource files are an old idea, but they are not widely used in the Python
community. My own experience with resources is based largely on how Mac
applications used the resource fork. PythonCard attempts to isolate the
window, widget layout, and menu descriptions from the source code by putting
them in a separate .rsrc.py file. This allows the layout to be modified
independently of the source code and logic of the application. It also
simplifies supporting multiple layouts for different OS platforms or doing
international versions of an application. Finally, it means that a
non-programmer can handle the layout since they do not need to write any
Python code.

The resource file typically shares the same base name as the main
application, so the minimal sample has two files:
  minimal.py
  minimal.rsrc.py

The resource file has a .py extension because the resource file is actually
a valid Python dictionary and so it is often easiest to edit and validate
the resource file using a Python-aware editor. The files are plain text.
They are not in XML format since a separate program would be necessary to
validate the XML and I feel that XML is less human-readable than the
equivelant nested dictionary/list done using Python syntax. Binary data
necessary for an application such as images and sound files are stored
separately. Images necessary for the application widgets are referenced via
'image' or 'file' attributes in the resource file.

There is currently a circular type of reference between the main source app
and the resource file. When an application like 'minimal.py' starts,
'.rsrc.py' is appended to the name of the application and passed to the
PythonCardApp class to load and start the real application launch. This is
shown by the code below, which is common to all the samples.

if __name__ == '__main__':
    base, ext = os.path.splitext(sys.argv[0])
    filename = base + ".rsrc.py"

    configOptions()

    app = PythonCardPrototype.model.PythonCardApp(filename)
    app.MainLoop()

The resource file such as minimal.rsrc.py has a reference back to the source
file as shown below
  ...
  { 'type':'Background',
    'file':'minimal.py',
    'classname':'Minimal',
  ...

Only the base part of the name (e.g. 'minimal') is actually used since the
framework will match both a .py and .pyw file. The circular reference is
actually bad design and should probably be changed. One obvious change would
be to simply remove the 'file' attribute, since like the code above, it
could be determined at runtime as long as we follow the convention of a
common base name for a resource file and the main source that goes with it.

The full organization of the resource file is defined in spec.py. When a
resource is read in (see res.py) it is validated with spec.py, default
arguments are initialized and any undefined component types in the resource
will cause a runtime error. The resource dictionary is converted to an
object that supports dot notation automatically and most places in the
framework where a resource argument is used, it is valid to pass in a
dictionary instead.

The resourceEditor sample is a simplistic editor for the .rsrc.py files. It
is not a full-featured layout editor and you still need to edit the .rsrc.py
file by hand to change anything other than the widget layout and attributes.
However, it is possible to have a fairly short edit/run cycle by keeping the
layout of your app open in the resourceEditor sample and the source code
open in your favorite editor/IDE and then launching the app from the
command-line or a directory browser (Explorer) as you make changes.

There is currently no support for doing a PythonCard application without a
resource file. You can define all of the Background components (widgets) in
source code, but the resource is required to define the basic app and
background window attributes and menus. I'll describe dynamic widget
creation in another message.

ka

Re: [Pythoncard-users] the future direction of PythonCard

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

Oh yeah, failed to mention that I was initially one of the major 
proponents of building something that does all that HyperCard can do and 
more :)


-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

Re: [Pythoncard-users] the future direction of PythonCard

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

As Kevin indicated, I haven't been able to participate in the actual 
development of PythonCard since our code-fest way back in July.  I'm 
very intrigued with the concept of building an extremly high level 
programming environment with a set of seamlessly integrated visual 
development tools.

I liked HyperCard back in the day, at least up to a point.  It was very 
easy to build simple to somewhat complex apps with HC.  But I really 
believe that HC dropped the ball in re providing a truly OO programming 
environment ( you couldn't define classes with attributes and methods ) 
and also in not providing a component object model that allowed HC to be 
extensible with both visual and non-visual components.  I'm no component 
expert, but for me that's definitely one of the requirements of an 
application development environment like PythonCard.

Personally, I think the idea of saying we want to build something that 
is all that HyperCard was and more was too ambitious.  Stepping back, 
maybe we should be saying something like:  Let's build a framework that 
is powerful and flexible, yet doable by a small number of people, that 
we can then build upon to produce even more powerful and flexible apps 
like HyperCard, or a skinnable app builder, or an IDE, etc.

My feeling is that the way to proceed is to step back and define less 
ambitious but more focused requirements, with an eye toward the future. 
  Since this is an object-oriented software project, we're going to have 
to take those requirements and build a robust object model.  The model 
needs to be very well defined before we even write a line of code to 
implement it.  We know we can build whatever we can design - the 
protoytpe is proof of that.  The next phase needs to be about stating 
exactly what we want to do, and then using the requirements to define 
very independent subsystems.

So, what would I want in an application development environment?

1. A well defined component model that allows for flexible extension of 
the overall framework.

2.  A high-level, well defined gui component model that can be 
implemented using one or more underlying gui toolkits - wxPython, GTK, 
Aqua, etc.  The gui wrappers take a lot of time, but they make us think 
about how we really want to interact with gui components and give us the 
freedom to expose those behaviors and attributes that we feel are 
valuable in our own way.

3.  A component communication model.  The prototype uses events to 
communicate between components ( Widget objects ) and user scripts.  But 
we really don't have a way for components to communicate with components 
- I'm not sure how to do that, but it seems important.

4.  A flexible scripting framework that allows us to plug in different 
scripting models for different classes of application.  We currently use 
a scripting model similar to VB ala method naming conventions.  It's 
possible we could have multiple scripting models - one could be more 
Model-view-controller based.  One could be based on action objects, etc.

Oh yea, and Multiple Windows ( seriously ).

Andy Todd wrote:

> Kevin,
> 
> A stimulating post, my thoughts and suggestions are interspersed below 
> but, in summary, I'm not giving up and I would hope the other 
> subscribers to this list can spare enough time and/or brain cells to 
> keep this project going. I think we have built something pretty great 
> and would like to keep it going.
> 
> Kevin Altis wrote:
> 
>> We're approaching the four month mark since the start of the PythonCard
>> mailing list. This seems like a good time to evaluate where the project
>> currently stands, whether we're on track, and what direction we should 
>> head
>> in the future. Even the lurkers out there should respond in some 
>> fashion to
>> this message if they're interested in the future direction of PythonCard.
>>
>> Issues in no particular order:
>>
>> Is anyone using the current prototype? We've had a reasonable number of
>> downloads, but the list is very quiet. The apps I know about are the 
>> samples
>> included with each release, some experiments of my own and Simon's 
>> blogger
>> app. I'm probably forgetting something. Ron posted some source to the 
>> list
>> and I'm assuming he is still experimenting with PythonCard. Is anyone 
>> else
>> playing with PythonCard?
> 
> 
> 
> I'm using it. I'm trying to test and stress it but am very happy to 
> report that I haven't found any problems yet. Maybe I'm not looking in 
> the right places, or maybe I'm just lucky. Whatever the reason I shall 
> keep trying.
> 
>>
>> Based on the current samples, is the current framework too complex or too
>> limiting or just right?
> 
> 
> 
> It is a little complex to understand at first but once it all slots 
> together I think we have a great operating model. My initial problems 
> are probably due to my inexperience and no doubt some documentation 
> would help. See my to do list at the end of this message.
> 
>>
>> What elements need to be added to the current framework before you 
>> would use
> 
> 
>> PythonCard for your own work?
> 
> 
> 
> 1. Multiple windows
> 2. Multiple windows
> 3. Multiple windows
> 4. Timers
> 5. There is no item number 5
> 6. Multiple windows
> 
>>
>> Is the most important thing having an environment like HyperCard?
> 
> 
> 
> I would say it is multiple windows ;-)
> 
>>
>> Project Roles
>> The last update to the roles list was on July 12th, so it is out-of-date
>> http://aspn.activestate.com/ASPN/Mail/Message/676720
>> At this point, I'm doing most of the work on the framework and samples.
>> Patrick is working on PyCrust, which we use for our shell and namespace
>> viewer. Andy is still active, but not on the framework. Both Neil and 
>> Robin
>> answer questions, but otherwise are not currently involved in PythonCard
>> code. Rowland is not active either, though we owe a debt to him for the
>> original framework, ideas, etc. Rowland and I mostly chat about 
>> PythonCard
>> outside the list. Roman helped start the distutils work, but Andy took 
>> that
>> over. There have been a few people offering to get involved, but real 
>> life,
>> work, etc. has overridden most of the good intentions. There is a limited
>> amount we can accomplish without more developers. This will have an 
>> impact
>> on the scope of the project, so if you're interested in a particular area
>> please speak up.
>>
>> Documentation
>> Suggestions for getting some docs done? Anything in particular you 
>> want in
>> terms of documentation?
> 
> 
> 
> A users guide would be good I think, also a reference guide. I have 
> started on the first steps towards a reference guide. Specifically I'm 
> trying to generate the widget types and their valid attributes from 
> spec.py into some form of HTML (first, then XML perhaps) but it isn't 
> ready for public consumption yet.
> 
> I'm really interested in generating large parts of documentation 
> automatically but I'm not a huge fan of the complex solutions they are 
> talking about over on the Doc-Sig (http://www.python.org/sigs/doc-sig), 
> yet.
> 
>>
>> The project name
>> Is everyone happy with the name PythonCard? I wouldn't bring this up 
>> except
>> that recently I learned a number of people had never even bothered to 
>> look
>> at PythonCard because of the implied similarity to HyperCard. There are a
>> lot of people out there that have never used a Mac and even if they 
>> have, a
>> lot of people never liked HyperCard and considered it a toy for building
>> apps. On the other hand, a lot of HyperCard users expect PythonCard to
>> provide a complete environment, so the name doesn't reflect so much 
>> what we
>> have today, but what we hope to achieve. It doesn't help that wxPython
>> doesn't run on the Mac yet.
> 
> 
> 
> I'm happy with the name. As for the link with HyperCard turning people 
> off, we do say on the project web page (http://pythoncard.sf.net) "This 
> is a project to build a HyperCard like tool in, and using, the Python 
> language"
> 
> Maybe we could stress it more but the second sentence on our home page 
> should be enough shouldn't it? My only suggestion would be to emphasise 
> as often as possible that HyperCard is an inspiration, not a specification.
> 
> Failing that, I believe the name 'Monty' was suggested back when this 
> list was on Yahoo! and checking on sourceforge that project name isn't 
> taken yet ;-)
> 
>>
>> Should we move beyond the prototype and make the next major release an 
>> alpha
>> version of the real framework?
> 
> 
> 
> That depends on what we decide the alpha release should include. I know 
> thats a circular argument but what I think we need to do before anything 
> else is state what we are trying to achieve. I know Kevin has an idea, 
> as do I, of what we want from PythonCard (see below) and so probably 
> does everyone else reading this list. What we haven't done recently is 
> check whether we are all on the same page. Lack of posts to this list 
> don't help of course, so shout out please everyone.
> 
>>
>> How thin should the framework layer be over wxPython? That's a loaded
>> question. The implication is that we will only be able to achieve our 
>> goals
>> with wxPython instead of alternative GUI toolkits for Python. That may or
>> may not be true. What do we want to achieve with our framework sitting on
>> top of wxPython that wxPython doesn't provide?
> 
> 
> 
> Simplicity. I looked briefly at wxPython (and tkinter, etc.) when I 
> started to learn Python and ran away - very quickly. Necessarily these 
> toolkits are very close to the os/hardware, which is great if you are 
> writing Word or Mozilla but not if you are writing an order entry 
> application (like I want to do).
> 
> The decision to use wxPython was a pragmatic (and I think correct) one 
> when we started out on the prototype and still holds true for me. Once 
> we have a working framework with a consistent API we could look at the 
> applicability of different backends but let us build the horse first 
> before selecting a different cart.
> 
>>
>> What parts of the framework are most important to you? Some 
>> possibilities:
>>   Layout descriptions in resource files
>>   Automatic widget creation and event binding
>>   Dot notation for widgets and other framework items
>>   on_widget_event style handlers
>>   runtime tools such as the shell, message watcher, property editor
> 
> 
> 
> In order; resource files, runtime tools, dot notation, modular 
> architecture. Oh, and multiple windows.
> 
>>
>> Are the samples useful?
> 
> 
> 
> They are, but then I would say that wouldn't I.
> 
>>
>> What do you want PythonCard to be?
> 
> 
> 
> I want to be able to easily build small to medium sized GUI applications 
>  with as little (or as much as necessary) coding as possible. I only 
> briefly used HyperCard but I've also used VB, Delphi, Oracle Forms, 
> Powerbuilder, etc. and an easy to use version of those kind of app 
> builders is what I am after. I'm mindful of the other tools under 
> development as well though (specifically Boa and wxDesigner) and suggest 
> we try and complement them rather than compete.
> 
> I am also a fan of CP4E and think that PythonCard could address this 
> requirement as well. Is it in line with my first requirement? Possibly, 
> if you consider the shell and the resource editor. Ease of use should be 
> our aim, 'kiss' (keep it simple stupid) our motto.
> 
>>
>> I definitely pushed PythonCard in the direction I thought it should go 
>> back
>> in July and I'm going to continue to pursue PythonCard in some form, 
>> but it
>> may be time to revise some of the original goals. I'll give other 
>> people a
>> chance to respond before stating some of my own preferences.
> 
> 
> 
> I hope I've added some fuel to the fire. I'd like to take this 
> opportunity to thank Kevin, Patrick, Rowland, Neil, Robin, Roman (and 
> anyone else I've forgotten) who have built something pretty wonderful in 
> a few short months. I for one am not giving up on it. Even if we stopped 
> work on the framework tomorrow we still have a valuable body of code to 
> work with and on. As I've said to Kevin privately I don't feel qualified 
> to play with the framework code but one of my aims whilst participating 
> in this project is to acquire the knowledge to be able to do so. It 
> would be easier if the folks who wrote the code are around to help me 
> understand it though ;-)
> 
>>
>> This is an open-ended post, so feel free to bring up any topic you think
>> relates to the current state of PythonCard or its future even if I didn't
>> touch on the topic above.
>>
>> ka
>> ---
>> Kevin Altis
>> al...@se...
>>
> 
> As I promised at the top of this mail, here are the tasks I'm currently 
> working on (or thinking about);
> 
> 
> Documentation. I'm trying to write some routines to automatically 
> generate components of a reference guide. I think we also need to revise 
>  and expand the getting started guide that Kevin wrote and perhaps add a 
> guide to how the framework is structured for people who wish to examine 
> it (like me).
> 
> Data store support. I'm trying to add support for CSV files and more 
> varieties of relational databases (Gadfly, PostrgeSQL, Oracle) to the 
> dbBrowser sample. My next step would be to try and fit one of these 
> (probably Gadfly) into some kind of persistent storage layer for the 
> framework as a whole. This slightly overlaps Patrick's investigations 
> with ZODB but I think they don't overlap. I got a bit side tracked here 
> as Gadfly doesn't operate 'out of the box' with Python 2.0+ and have 
> started a thread on the DB-SIG mailing list about upgrading it. That has 
> distracted me a bit but should benefit the wider Python community as 
> well as, eventually, PythonCard.
> 
> Improve the dbBrowser application. My target is to produce a useful 
> general purpose RDMBS tool like TOAD (http://www.quest.com/toad). That's 
> probably a little ambitous but I am shooting high. If I continue this 
> application I may have to move it to wxPython but PythonCard is giving 
> me a valuable head start. If I didn't have PythonCard I wouldn't have 
> started on this path, reason enough for me to be thankful for PythonCard.
> 
> Statement of requirements. We need one. If we know what we want, we know 
> how far we have to go to get there. We started with a broad idea of 
> which widgets and events we wanted to support when the prototype kicked 
> off but now is a good time to more properly define our requirements. 
> I've put my broad thoughts in this mail and am happy to discuss them 
> with you all.
> 
> Packaging. We have used distutils to create the packages which can be 
> downloaded from SourceForge. Most of the good work was Roman's, most of 
> the head scratching was mine. The documentation for distutils is bad, it 
>  provides a very limited example but never explains how it works or what 
> its limitations are. I think we need to dig a little deeper into the 
> structure of the standard utilities to make them more usable for 
> PythonCard (subclassing is apparently the way to go but I haven't tried 
> that yet). I also think some new documentation is required and I've 
> started on that too. The activity level on the distutils-sig mail list 
> makes this one look quite lively so I don't think we will step on any 
> toes if we start to produce some more understandable documentation for a 
> part of the standard library ;-)
> 
> Regards,
> Andy



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

[Pythoncard-users] state of the framework - widgets

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

I'll try and outline the current state of the framework in order to foster
discussion. I'm going to break up the description into several emails. I'm
not going to describe every method and attribute since I would just end up
repeating what is in the source code. These descriptions can also serve as
documentation.

The following widget types are currently supported. The are defined in
widget.py and the wxPython control they are based on is in parenthesis ():
  BitmapCanvas
    Provides a buffered bitmap. There is no direct equivelant in wxPython.
  Button         (wxButton)
  CheckBox       (wxCheckBox)
  Choice         (wxChoice)
  Image          (wxStaticBitmap)
  ImageButton    (wxBitmapButton)
  List           (wxListBox)
  PasswordField  (wxTextCtrl)
  RadioGroup     (wxRadioBox)
  Slider         (wxSlider)
  StaticLine     (wxStaticLine)
  StaticText     (wxStaticText)
  TextArea       (wxTextCtrl)
  TextField      (wxTextCtrl)

The following events are automatically bound and available for each widget:
  gainFocus
  loseFocus
  mouseContextDoubleClick
  mouseContextDown
  mouseContextUp
  mouseDoubleClick
  mouseDown
  mouseDrag
  mouseEnter
  mouseLeave
  mouseMiddleDoubleClick
  mouseMiddleDown
  mouseMiddleUp
  mouseMove
  mouseUp

There are additional events such as 'mouseClick', 'keyPress', etc. that are
specific to particular widgets. The complete list is available in spec.py.

The following attributes are available for each widget.
    backgroundColor
        color: tuple (r, g, b), "named color", or hex color string "#FF00FF"
        color is always returned as an rgb tuple
    command
        string
    enabled
        boolean
    font
        Font
    foregroundColor
        color: tuple (r, g, b), "named color", or hex color string "#FF00FF"
        color is always returned as an rgb tuple
    name    (mandatory, read-only)
        string
    position
        tuple (x, y)
           specifying -1 for either x or y will use the default x or y
position
    size
        tuple (width, height)
           specifying -1 for either width or height will use the default
           width or height
    toolTip
        string
    visible
        boolean

Additional attributes such as 'label' are defined for some widgets. The
attributes can be defined in the resource file as well as in user code.
PythonCard uses dot notation for widgets, rather than get/set methods. Here
is an example:
  self.components.field1.text = 'bob'
  txt = self.components.field1.text

Helper classes for widgets:
  Bitmap         (wxBitmap) - defined in graphic.py
    supported formats:
    BMP, GIF, JPG/JPEG, PCX, PNG, PNM, TIF/TIFF, XBM, and XPM
    also supports translation to/from Python Imaging Library (PIL) format
  Font           (wxFont)   - defined in font.py

In some case, the helper classes and widgets provide extra functionality
over their wxPython counterparts. Automatic binding of events and simplifed
initialization are the most obvious.

ka

RE: [Pythoncard-users] the future direction of PythonCard

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

Having never used HyperCard, I don't feel particularly qualified to point in
any particular direction and say "go that way." But I do think the current
direction, however vague or grand, has produced some very nice results. It
certainly motivated me to create PyCrust at a time when I was itching to
prove that it was quite possible to create a wxPython-based shell using
Scintilla in a reasonable timeframe and with competitive features[1].

Now my interest is in creating applications using ZODB as the persistence
mechanism. Between Andy working on relational storage and me working on
object storage we should be able to meet the PythonCard requirement of
multiple windows and transparent saves. The work on ZODB has been slow,
because not many people are using it outside of Zope. Therefore, I'm having
to build up a toolkit as I go[2]. Whatever I come up with should be usable
within PythonCard in some fashion.

Personally, I think it might be easier to get momentum going if we defined
the minimum set of features required to release a version of PythonCard that
people could commit to and start using. Then we can add features and rework
things as we go. For me, my pet project right now is creating one or two
simple sample applications using ZODB for storage. The first one I'm working
on is called NoteKeeper, and will probably be a simple
outliner/PIM/organizer. It will likely have just two classes at first,
Folder and Note. A folder can contain other folders in your basic hierarchy.
A folder can also contain any number of notes, which are just text blobs.
With this foundation, it should be possible to store todo lists, calendars,
projects, outlines of any sort, etc. We'll see where it goes beyond that.

So for me, the focus will be on getting this app created. Anything
PythonCard has that makes this easier will make me happy. Anything that
PythonCard is missing will make me mad. If I get mad enough, I end up
writing code that makes me happy. Lather, rinse, repeat. <wink> That's my
two bits. I'm in this for the long haul.

Pat

[1] The CVS version of PyCrust now has full support for multi-line commands.
You can scroll back to any line of a multi and the whole command is copied
down where it can be modified, including adding and deleting lines. The
command history retrieval functions (Ctrl-Up or Alt-P, Ctrl-Down or Alt-N,
F8) all retrieve entire multi-line commands as well. The retrieval method
has been modified as well so that retrieved commands are inserted into the
existing command (and highlighted), making it easier to build new commands
that make use of old commands. Give it a try and let me know if anything
breaks.

[2] My ZODB toolkit and sample applications are available at
http://sourceforge.net/projects/orbtech/. At this time they are only
available in CVS, and are in a state of constant modification as I figure
out what I'm doing with ZODB.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."