pythoncard-users — PythonCard Users and Developers

RE: [Pythoncard-users] six blind men describe the beast

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

> From: Rowland Smith
>
> > is not designed to run inside a web browser
>
>
> Definitely.  If someone wants to write a tool that generates a web app
> from PythonCard, that's great, but it's not something we want to take on

In case anyone is confused, this does not mean you can't generate HTML,
design a templating system, content management system, etc. from a
PythonCard app that you've written. It does mean that there wouldn't be an
automatic export/conversion from PythonCard layouts and Python code to HTML
and JavaScript for the client-side of a WebApp and generate all the
necessary back-end server code as well. That is just not possible. As far as
layouts, some form of conversion might be doable, the Pyker .hta files Neil
provided hint at what may or may not be possible.

> > support editing programs in standard editors (vi, vim, emacs,
> >    PythonWin, IDLE, etc.) and not be forced to edit in and IDE
>
>
> It's certainly nice to be able to edit code in your favorite editor, but
> for PythonCard to really be useful it's going to need a slick, powerful
> app builder/ide available as soon as possible.  This is something that I
> would like very much to work on.

Yes and no. Even with just a great framework, layout editor, and some
run-time tools, which would just be a better version of the prototype today
that would be a good thing for Python programmers. In fact, given the extra
work needed to do an IDE, VDE, whatever I would probably be happy to stop at
that point for my own programs. However, I also see the need to go beyond
that so I don't mind contributing to the IDE/VDE effort in parallel and as a
way of stressing the framework since I'm assuming most of the IDE/VDE will
be written itself in PythonCard. Certainly without an environment, we won't
be remotely close to "competing against" HyperCard or any commercial
language solution.

Baby steps,

ka

Re: [Pythoncard-users] six blind men describe the beast

[Cliff W. <log...@ea...>]

On Thu, 10 Jan 2002 14:11:07 -0800
Kevin Altis wrote:

> scripting but not programming, and who need things that rapidly prototype
> and turn into usable application-like things with minimal hassle." I
don't
> understand the programming part, since scripting is programming, but the
> rest sounds right for the less sophisticated programmer end of our
audience.

I wondered about that too, but I think "scripting" in this context probably
refers to accessing pre-existing features in a particular order (like a
macro) versus creating from-scratch features.

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308

RE: [Pythoncard-users] six blind men describe the beast

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

> From: Rowland Smith
>
> > I think the above 3 points constrains the likely user domain to
> programmers
> > more then John and Jane Q. Public. Not a criticism, just a
> point - but is
> > that the desired target audience? HyperCard (HC here after) gave the the
> > average "toaster" user the ability to drag objects into a
> pleasing (to them)
> > arrangement and viola! they had something usable...
>
>
> A sophisticated visual development environment is a must for non
> programmers.

We definitely need to be precise here. I don't particuarly care about the
non-programmers as far what you can do with PythonCard if non-programmers
means people that aren't going to do any scripting in Python. Dan's
"Inventive Users" are described as people "who are willing to learn
scripting but not programming, and who need things that rapidly prototype
and turn into usable application-like things with minimal hassle." I don't
understand the programming part, since scripting is programming, but the
rest sounds right for the less sophisticated programmer end of our audience.

Anyone can create something on top of wxPython, with or without PythonCard
extras that lets people design forms and create simplistic free-form
databases but doesn't support any scripting. It is basically just a
combination of what we're already doing with the resourceEditor, addresses,
and textIndexer samples. That is a specific type of application though, not
a framework for a larger class of applications.

I guess what I'm saying is that the intended audience I have in mind does
not include people looking for a dumbed down FileMaker or HyperCard that
only goes up to user level 4 (authoring). I'm aiming at people that want to
use Python to solve problems and need a GUI interface.

> >>the primary focus is on small and simple
> >>    GUI programs written by one person or at most a few people,
> >>    not a team working on a large six-month or multi-year project.
> >>
> >>if simple programs are not simple to create and maintain we've failed.
> >>
> >
> > I think that at a certain level, if anyone has to actually
> write code to get
> > the simplest application, that's a miss.
>
> This comes back to the Visual Development Environment ( VDE ) - We
> really need to start spec'ing it out from a requirements standpoint.

You'll have to describe what you have in mind, it sounds like something more
elaborate than what we've discussed in the past.

> >>uses wxPython as the cross-platform GUI toolkit
> >>    simplifies writing wxPython programs
> >>
>
>
> We're really only limited by the platforms that Python AND wxPython
> support, right?

Yes.

ka

RE: [Pythoncard-users] moving menubar and getting rid of stack?

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

> From: Rowland Smith
>
> Kevin Altis wrote:
>
> >>From: Andy Todd
> >>
> <snip>
> >>The separation of the window from the background is quite a powerful
> >>'feature'. One of the neat things you can do in Oracle forms is
> >>dynamically/programatically swap the canvases (backgrounds in our
> >>terminology) within a window. This allows some pretty fancy layout - but
> >>then again may be too complicated for our kind of applications. Its a
> >>feature that I have used in the past, but I don't have a sample
> >>application in mind which would need it - yet.
> >>
> >
> > Yes, this is a bit more like HyperCard. This still feels like
> an app that
> > should be built on top of the framework and not the framework
> itself. What
> > do other people think?
>
>
> Setting a Form on a Window ( myWindow.setForm( f ) ) is a reasonable
> responsibility for a Window to fullfill.  This would allow the user to
> build their own navigation system for viewing different Forms in the
> same window.
>
> A higher level class like MultiFormWindow could be constructed with a
> list of Forms, and provide navigation between the forms in the list.
> This is like HyperCard where each Card has a different background and
> allows the creation of multi-media style apps.

To be more precise, each Card in HyperCard has an associated Background.
Stacks contain Backgrounds. It was quite common to have a Stack with a
single Background that contained many cards. One of the things which made
HyperCard Cards different from say individual records in a table in a normal
database is that each Card could also have its own script, buttons, fields,
and graphics. In object terms, each Card (instance) could have its own
attributes in addition to the Background (class) attributes; Python's object
model certainly supports that, but it can be confusing. If a stack uses that
capability it makes it much more difficult to translate to a different
environment.

This gets back to the confusion between GUI widgets bound to an underlying
document model and those that aren't. PythonCard doesn't provide any
inherent binding yet, though some of the samples like addresses, textIndexer
hint at what we might do.

Of course, many times the additional backgrounds and cards in a stack took
the place of what would normally be placed in a separate window or dialog in
a "normal" application.

Anyway, the framework we have today requires a Background (wxFrame) to
always contain a Panel (wxPanel). It is simple to hide the current panel and
show another one or remove the panel and insert another one. The problem is
that we are putting the event handlers in the Background instead of the
Panel. A change to an application/window/form or panel organization means
that handlers should be bound to the panel or at least the event binding
should be more flexible.

ka

Re: [Pythoncard-users] six blind men describe the beast

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

David LeBlanc wrote:

> Well hmmmm... I just went and looked at the PythonCard homepage again and
> still couldn't find an exposition anything like this one. Comments and
> questions below.
> 
> 
>>For inspiration...
>>  http://www.wordfocus.com/word-act-blindmen.html
>>
>>It has been a while since we had the "what is it?" discussion. I
>>didn't list
>>everything and some people will/should object to some of the statements
>>below, so go ahead and throw in your two cents (or possibly a hong kong
>>dollars worth). Maybe we'll put the results up on the web site and keep it
>>up-to-date as the project progresses so our goals are clear.
>>
>>ka
>>---
>>
>>built with Python
>>
>>uses Python for the scripting language
>>
>>suitable for people just learning Python
>>
> 
> I think the above 3 points constrains the likely user domain to programmers
> more then John and Jane Q. Public. Not a criticism, just a point - but is
> that the desired target audience? HyperCard (HC here after) gave the the
> average "toaster" user the ability to drag objects into a pleasing (to them)
> arrangement and viola! they had something usable...


A sophisticated visual development environment is a must for non 
programmers.


> 
>>the primary focus is on small and simple
>>    GUI programs written by one person or at most a few people,
>>    not a team working on a large six-month or multi-year project.
>>
>>if simple programs are not simple to create and maintain we've failed.
>>
> 
> I think that at a certain level, if anyone has to actually write code to get
> the simplest application, that's a miss.
> 


This comes back to the Visual Development Environment ( VDE ) - We 
really need to start spec'ing it out from a requirements standpoint.


>>simple yet powerful enough for people familiar with HyperCard,
>>    Visual Basic, SuperCard, Revolution, and other assorted
>>    HyperCard "clones"
>>    PythonCard should be a viable alternative to proprietary
>>    languages and application builders.
>>
> 
> How does this conform to the idea of using Python as the scripting language?
> 
Leveraging Python as the scripting language is a must.  It's pretty easy to learn and is

much more powerful than anything we could create on our own with limited 
resources.

 
>>is cross-platform supporting at least the major OS platforms:
>>    Windows (95/98 and above), Linux (GTK), Mac (at least OS X)
>>
> 
> IMO, prefer NT/2000/XP over any of the Windows 9X/ME ilk.
> 
> 
>>uses wxPython as the cross-platform GUI toolkit
>>    simplifies writing wxPython programs
>>


We're really only limited by the platforms that Python AND wxPython 
support, right?


> Will PythonCard further simplify creating GUI's?
> 
> 
>>does not preclude the creation of OS-specific applications
>>
> 
> Sounds like an extension API would be desireable.
> 
> 
>>is not designed to run inside a web browser
>>
> 
> While not designed to _run_ inside a web browser, I think it ought to be
> able to produce content to be _viewed_ in a web browser. Both HyperCard and
> SuperCard offer this ability to my knowledge, not to mention MS Office that
> supports Word, XL and PowerPoint exports to HTML (better XML for us IMO). As
> I think about it, an ability to produce a form that would run both in an app
> window and a browser window wouldn't be a bad thing either - and XRCed might
> offer a foundation for that? Don't constrain tool abilities by this option -
> some designs can't be exported as "presentation XML".
> 


I don't think this should really be a goal of the PythonCard development 
team.  It's way too much work for the few people that are actively 
developing PythonCard itself.  However, this would be a great side 
project for others after PythonCard becomes stable.


> 
>>establishes naming and coding conventions to make programming
>>    GUI applications more pythonic, easier to read and write
>>    for example, the handler names such as on_btn1_mouseClick
>>
> 
> "OnButtonClick Button1" worketh too IMO :-). Since Python still adheres to
> parens for arguments (alas!), "OnButtonClick(Button1)" worketh ok enough.
> Contractions like Btn1 are nice for programmer or more experienced folk and
> should be provided, but I think they're confusing to newbies. Rather then
> creating naming and coding conventions (newbies aren't going to follow those
> anyway), Hide as many implementation details as possible behind more
> common-man idioms. Favor language independence to the extent possible.
> 


Hopefully we can produce a development environment that allows 
non-programmers to build simple apps without seeing actual code.  This 
is a big task but would go a long way to getting PythonCard accepted by 
a larger audience.


>>make it simple to change and reuse parts of PythonCard apps
>>
> 
> More API-ness. Packages.
> 
> 
>>separate resources/layouts from source, but also support
>>    defining layouts in code for dynamic layouts
>>
> 
> Hammer and Tongs. Any pressing reason why dynamic layouts couldn't be done
> via a GUI design tool? I think the efficacy of a 3-tiered design model is
> well established: Presentation, Logic, Storage. The more you mix them, the
> less flexible and (often) more convoluted your design becomes. OTOH, the
> development model could just as well be quite different: I sure don't want
> to have to go somewhere else in the design tool to enter attribute values or
> event handlers for a GUI object I just added to my presentation layer.
> 


We need to look at some sophisticated VDE's, HyperCard, etc, and get 
some ideas on what kind of VDE we would like to build for PythonCard.


>>provides built-in classes, methods, and functions for tasks
>>    common to GUI applications that is not provided in the
>>    Python Standard Libraries, wxPython, or a common Python
>>    library such as Python Imaging Library (PIL) or NumPy
>>
> 
> Examples?
> 
> 
>>should be a complete replacement of tkinter for those wanting
>>    to program GUIs with Python
>>
> 
> This is distinct from WxPython how?
> 
> 
>>open source
>>
>>uses the Python license or a rough equivalent, not GPL, so there
>>    is the possibility of commercial applications, components, etc.
>>
> 
> Good.
> 
> 
>>supports simple builds of standalone executables using py2exe
>>    and/or Gordon McMillan's installer
>>
> 
> I wonder if it's possible to reduce this to  a menu item: "Create Installer"
> with the option to "go manual" if needed for more complex apps?
> 
> 
>>component architecture to support more than just wxPython controls
>>    including compound components. PythonCard components are
>>    roughly analogous to COM and JavaBeans
>>
> 
> <Cough> I suggest putting this in the development context in the form of
> "leave room for this idea" - this is probably a fairly substantial task in
> it's own right, and probably has an impact on WxPython and possibly even
> WxWindows itself. Also, keep CORBA in mind as the component model - or
> SOAP!! (I'm in favor of SOAP myself).


I believe that we're heading toward a Python specific component model 
that leverages the power of the language/runtime as much as possible. 
Once that component model is in place, we can create adapters to other 
component models.


> 
>>does not force the use of Model View Controller (MVC) on user code
>>
> 
> Does WxWindows use that paradigm?
> 


Model-View-Controller is being used internally in the PythonCard 
framework, but we probably won't force it on users - although it would 
be good if we could facilitate the use of MVC by end users.


>>the cross-platform aspect means that it won't have the same
>>    capabilities as an OS-specific app/framework that can take
>>    advantage of platform-specific code. in particular, there
>>    is no support for QuickTime, Real, Windows Media Format, MPEG,
>>    MP3s, etc. in some cases, you can do platform-specific apps
>>    using these technologies. you are not going to be able to do
>>    all the things you could do say with Flash, at least not in the
>>    near future.
>>
> 
> Hmmm... here is how I can see merging the idea of Component Objects,
> platform independence and taking advantage of platform specific formats: I
> don't think anyone would argue that having a "Movie" objec would be nice;
> just let it have an attribute "media" specifying the format (from a list of
> available formats controlled by a project attribute "Platform" which would
> have as one choice "independent".
> 
> 
>>as wxWindows/wxPython improves, so will the capabilities of
>>   PythonCard
>>
> 
> Ditto for Python one would assume. Actually, I suggest using Python 2.2 as
> the initial target - the unification of the class hierarchy is just too good
> to pass up. (Frankly, I think this was a big enough change in the language
> to warrant a full bump to 3.0, but so far Guido hasn't sought my counsel ;).
> One wonders what's in store for Python 3.0.)
> 


I'm not familiar with this change  -Kevin?


>>support editing programs in standard editors (vi, vim, emacs,
>>   PythonWin, IDLE, etc.) and not be forced to edit in and IDE
>>
> 
> As a option for sure ("For Editing use: {Built-in, Vim, Vi, Emacs, Idle,
> Scite}"), but having a built-in editor based on Scintilla is pretty much a
> (WxWindows supported) no-brainer IMO.
> 
> **********************************************************
> A few thoughts of my own in no particular order...
> 
> Templates: basis for "standard" apps. Conceptually similar to the Visual C++
> Dev Studio project types, but possibly more sophisticated (how hard could
> that be? <g>). Creates the coceptual framework for reusable components.
> 
> SWIG: Relatively effortlessly slurp up "foreign" libraries.
> 
> The XML family of protocols - whereever and however they might be useful. A
> strongly influencing design bias should be: "can this be expressed in X*L?"
> (where X*L is XML, XSLT, XSchema, XPointer, XLink etc.)
> 
> How is this different from Boa?
> 
> Dave LeBlanc
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

---------------------------
Truth: Accept No Substitute
---------------------------

Re: [Pythoncard-users] six blind men describe the beast

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

Kevin Altis wrote:

> For inspiration...
>   http://www.wordfocus.com/word-act-blindmen.html
> 
> It has been a while since we had the "what is it?" discussion. I didn't list
> everything and some people will/should object to some of the statements
> below, so go ahead and throw in your two cents (or possibly a hong kong
> dollars worth). Maybe we'll put the results up on the web site and keep it
> up-to-date as the project progresses so our goals are clear.
> 
> ka
> ---

> is not designed to run inside a web browser


Definitely.  If someone wants to write a tool that generates a web app 
from PythonCard, that's great, but it's not something we want to take on


> 
> does not force the use of Model View Controller (MVC) on user code


It would be nice if the programming model facilitated use of MVC.


> the cross-platform aspect means that it won't have the same
>     capabilities as an OS-specific app/framework that can take
>     advantage of platform-specific code. in particular, there
>     is no support for QuickTime, Real, Windows Media Format, MPEG,
>     MP3s, etc. in some cases, you can do platform-specific apps
>     using these technologies. you are not going to be able to do
>     all the things you could do say with Flash, at least not in the
>     near future.


As long as we define interfaces like Movie and Sound, then others can 
extend them to support different formats/media.



> support editing programs in standard editors (vi, vim, emacs,
>    PythonWin, IDLE, etc.) and not be forced to edit in and IDE


It's certainly nice to be able to edit code in your favorite editor, but 
for PythonCard to really be useful it's going to need a slick, powerful 
app builder/ide available as soon as possible.  This is something that I 
would like very much to work on.


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



-- 
Talk to ya,
Rowland

---------------------------
Truth: Accept No Substitute
---------------------------

Re: [Pythoncard-users] moving menubar and getting rid of stack?

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

Kevin Altis wrote:

>>From: Andy Todd
>>
<snip>
>>The separation of the window from the background is quite a powerful
>>'feature'. One of the neat things you can do in Oracle forms is
>>dynamically/programatically swap the canvases (backgrounds in our
>>terminology) within a window. This allows some pretty fancy layout - but
>>then again may be too complicated for our kind of applications. Its a
>>feature that I have used in the past, but I don't have a sample
>>application in mind which would need it - yet.
>>
> 
> Yes, this is a bit more like HyperCard. This still feels like an app that
> should be built on top of the framework and not the framework itself. What
> do other people think?


Setting a Form on a Window ( myWindow.setForm( f ) ) is a reasonable 
responsibility for a Window to fullfill.  This would allow the user to 
build their own navigation system for viewing different Forms in the 
same window.

A higher level class like MultiFormWindow could be constructed with a 
list of Forms, and provide navigation between the forms in the list. 
This is like HyperCard where each Card has a different background and 
allows the creation of multi-media style apps.


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



-- 
Talk to ya,
Rowland

---------------------------
Truth: Accept No Substitute
---------------------------

Re: [Pythoncard-users] CSV importer

[Cliff W. <log...@ea...>]

On Wed, 9 Jan 2002 16:15:08 -0800
Cliff Wells <log...@ea...> wrote:

> www.sf.net/projects/python-dsv

BTW, no CVS, just download the 1.3 tarball.

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308

[Pythoncard-users] CSV importer

[Cliff W. <log...@ea...>]

Hi all,

I was talking to Kevin Altis the other night and he mentioned that there is
apparently some need for a CSV (comma separated values) file importer for
some part of PythonCard.  If you are working on this you might consider a
module I wrote some time ago:

www.sf.net/projects/python-dsv

DSV stands for "delimiter separated values" (since it's not limited to
commas).  I wrote it (entirely in Python) to be compatible with the files
used by MS Excel, however, it is also unique in that it provides some
additional features I've not seen in other CSV importers:

- Can guess the format of the file (what delimiter is used, what
text-qualifier 
   is used and whether the first row is a header row).
- Correctly parses embedded newlines and quotes
- Provides a wxPython dialog for previewing the data and changing the
guessed 
   parameters (similar to the one in MS Excel).
- Pluggable error handling functions (e.g. discard invalid rows, keep them,

   log them, etc)
- It's faster than you might expect ;-)

The heuristics are optional (you can provide explicit values) as is the GUI
portion.

Anyway, it's been a while since I actually used it, but I tested it prior
to posting it on SF (around 2 months ago) and it seemed to work fine.  This
code was used in a production environment for some time and worked without
fail on fairly large files (50k-300k lines, 20+ columns).

If you do decide to use it and encounter any problems, please contact me
and I'll be glad to help.

Regards,

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308

[Pythoncard-users] menubar moved to background in .rsrc.py

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

moved 'menubar' attribute from 'stack' to the background
  updated all sample .rsrc.py files
  updated Backround __init__ (model.py), menu.py, spec.py, and
    resourceEditor.py

ka

RE: [Pythoncard-users] six blind men describe the beast

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

Well hmmmm... I just went and looked at the PythonCard homepage again and
still couldn't find an exposition anything like this one. Comments and
questions below.

> For inspiration...
>   http://www.wordfocus.com/word-act-blindmen.html
>
> It has been a while since we had the "what is it?" discussion. I
> didn't list
> everything and some people will/should object to some of the statements
> below, so go ahead and throw in your two cents (or possibly a hong kong
> dollars worth). Maybe we'll put the results up on the web site and keep it
> up-to-date as the project progresses so our goals are clear.
>
> ka
> ---
>
> built with Python
>
> uses Python for the scripting language
>
> suitable for people just learning Python

I think the above 3 points constrains the likely user domain to programmers
more then John and Jane Q. Public. Not a criticism, just a point - but is
that the desired target audience? HyperCard (HC here after) gave the the
average "toaster" user the ability to drag objects into a pleasing (to them)
arrangement and viola! they had something usable...

> the primary focus is on small and simple
>     GUI programs written by one person or at most a few people,
>     not a team working on a large six-month or multi-year project.
>
> if simple programs are not simple to create and maintain we've failed.

I think that at a certain level, if anyone has to actually write code to get
the simplest application, that's a miss.

> simple yet powerful enough for people familiar with HyperCard,
>     Visual Basic, SuperCard, Revolution, and other assorted
>     HyperCard "clones"
>     PythonCard should be a viable alternative to proprietary
>     languages and application builders.

How does this conform to the idea of using Python as the scripting language?

> is cross-platform supporting at least the major OS platforms:
>     Windows (95/98 and above), Linux (GTK), Mac (at least OS X)

IMO, prefer NT/2000/XP over any of the Windows 9X/ME ilk.

> uses wxPython as the cross-platform GUI toolkit
>     simplifies writing wxPython programs

Will PythonCard further simplify creating GUI's?

> does not preclude the creation of OS-specific applications

Sounds like an extension API would be desireable.

> is not designed to run inside a web browser

While not designed to _run_ inside a web browser, I think it ought to be
able to produce content to be _viewed_ in a web browser. Both HyperCard and
SuperCard offer this ability to my knowledge, not to mention MS Office that
supports Word, XL and PowerPoint exports to HTML (better XML for us IMO). As
I think about it, an ability to produce a form that would run both in an app
window and a browser window wouldn't be a bad thing either - and XRCed might
offer a foundation for that? Don't constrain tool abilities by this option -
some designs can't be exported as "presentation XML".

> establishes naming and coding conventions to make programming
>     GUI applications more pythonic, easier to read and write
>     for example, the handler names such as on_btn1_mouseClick

"OnButtonClick Button1" worketh too IMO :-). Since Python still adheres to
parens for arguments (alas!), "OnButtonClick(Button1)" worketh ok enough.
Contractions like Btn1 are nice for programmer or more experienced folk and
should be provided, but I think they're confusing to newbies. Rather then
creating naming and coding conventions (newbies aren't going to follow those
anyway), Hide as many implementation details as possible behind more
common-man idioms. Favor language independence to the extent possible.

> make it simple to change and reuse parts of PythonCard apps

More API-ness. Packages.

> separate resources/layouts from source, but also support
>     defining layouts in code for dynamic layouts

Hammer and Tongs. Any pressing reason why dynamic layouts couldn't be done
via a GUI design tool? I think the efficacy of a 3-tiered design model is
well established: Presentation, Logic, Storage. The more you mix them, the
less flexible and (often) more convoluted your design becomes. OTOH, the
development model could just as well be quite different: I sure don't want
to have to go somewhere else in the design tool to enter attribute values or
event handlers for a GUI object I just added to my presentation layer.

> provides built-in classes, methods, and functions for tasks
>     common to GUI applications that is not provided in the
>     Python Standard Libraries, wxPython, or a common Python
>     library such as Python Imaging Library (PIL) or NumPy

Examples?

> should be a complete replacement of tkinter for those wanting
>     to program GUIs with Python

This is distinct from WxPython how?

> open source
>
> uses the Python license or a rough equivalent, not GPL, so there
>     is the possibility of commercial applications, components, etc.

Good.

> supports simple builds of standalone executables using py2exe
>     and/or Gordon McMillan's installer

I wonder if it's possible to reduce this to  a menu item: "Create Installer"
with the option to "go manual" if needed for more complex apps?

> component architecture to support more than just wxPython controls
>     including compound components. PythonCard components are
>     roughly analogous to COM and JavaBeans

<Cough> I suggest putting this in the development context in the form of
"leave room for this idea" - this is probably a fairly substantial task in
it's own right, and probably has an impact on WxPython and possibly even
WxWindows itself. Also, keep CORBA in mind as the component model - or
SOAP!! (I'm in favor of SOAP myself).

> does not force the use of Model View Controller (MVC) on user code

Does WxWindows use that paradigm?

> the cross-platform aspect means that it won't have the same
>     capabilities as an OS-specific app/framework that can take
>     advantage of platform-specific code. in particular, there
>     is no support for QuickTime, Real, Windows Media Format, MPEG,
>     MP3s, etc. in some cases, you can do platform-specific apps
>     using these technologies. you are not going to be able to do
>     all the things you could do say with Flash, at least not in the
>     near future.

Hmmm... here is how I can see merging the idea of Component Objects,
platform independence and taking advantage of platform specific formats: I
don't think anyone would argue that having a "Movie" objec would be nice;
just let it have an attribute "media" specifying the format (from a list of
available formats controlled by a project attribute "Platform" which would
have as one choice "independent".

> as wxWindows/wxPython improves, so will the capabilities of
>    PythonCard

Ditto for Python one would assume. Actually, I suggest using Python 2.2 as
the initial target - the unification of the class hierarchy is just too good
to pass up. (Frankly, I think this was a big enough change in the language
to warrant a full bump to 3.0, but so far Guido hasn't sought my counsel ;).
One wonders what's in store for Python 3.0.)

> support editing programs in standard editors (vi, vim, emacs,
>    PythonWin, IDLE, etc.) and not be forced to edit in and IDE

As a option for sure ("For Editing use: {Built-in, Vim, Vi, Emacs, Idle,
Scite}"), but having a built-in editor based on Scintilla is pretty much a
(WxWindows supported) no-brainer IMO.

**********************************************************
A few thoughts of my own in no particular order...

Templates: basis for "standard" apps. Conceptually similar to the Visual C++
Dev Studio project types, but possibly more sophisticated (how hard could
that be? <g>). Creates the coceptual framework for reusable components.

SWIG: Relatively effortlessly slurp up "foreign" libraries.

The XML family of protocols - whereever and however they might be useful. A
strongly influencing design bias should be: "can this be expressed in X*L?"
(where X*L is XML, XSLT, XSchema, XPointer, XLink etc.)

How is this different from Boa?

Dave LeBlanc

[Pythoncard-users] six blind men describe the beast

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

For inspiration...
  http://www.wordfocus.com/word-act-blindmen.html

It has been a while since we had the "what is it?" discussion. I didn't list
everything and some people will/should object to some of the statements
below, so go ahead and throw in your two cents (or possibly a hong kong
dollars worth). Maybe we'll put the results up on the web site and keep it
up-to-date as the project progresses so our goals are clear.

ka
---

built with Python

uses Python for the scripting language

suitable for people just learning Python

the primary focus is on small and simple
    GUI programs written by one person or at most a few people,
    not a team working on a large six-month or multi-year project.

if simple programs are not simple to create and maintain we've failed.

simple yet powerful enough for people familiar with HyperCard,
    Visual Basic, SuperCard, Revolution, and other assorted
    HyperCard "clones"
    PythonCard should be a viable alternative to proprietary
    languages and application builders.

is cross-platform supporting at least the major OS platforms:
    Windows (95/98 and above), Linux (GTK), Mac (at least OS X)

uses wxPython as the cross-platform GUI toolkit
    simplifies writing wxPython programs

does not preclude the creation of OS-specific applications

is not designed to run inside a web browser

establishes naming and coding conventions to make programming
    GUI applications more pythonic, easier to read and write
    for example, the handler names such as on_btn1_mouseClick

make it simple to change and reuse parts of PythonCard apps

separate resources/layouts from source, but also support
    defining layouts in code for dynamic layouts

provides built-in classes, methods, and functions for tasks
    common to GUI applications that is not provided in the
    Python Standard Libraries, wxPython, or a common Python
    library such as Python Imaging Library (PIL) or NumPy

should be a complete replacement of tkinter for those wanting
    to program GUIs with Python

open source

uses the Python license or a rough equivalent, not GPL, so there
    is the possibility of commercial applications, components, etc.

supports simple builds of standalone executables using py2exe
    and/or Gordon McMillan's installer

component architecture to support more than just wxPython controls
    including compound components. PythonCard components are
    roughly analogous to COM and JavaBeans

does not force the use of Model View Controller (MVC) on user code

the cross-platform aspect means that it won't have the same
    capabilities as an OS-specific app/framework that can take
    advantage of platform-specific code. in particular, there
    is no support for QuickTime, Real, Windows Media Format, MPEG,
    MP3s, etc. in some cases, you can do platform-specific apps
    using these technologies. you are not going to be able to do
    all the things you could do say with Flash, at least not in the
    near future.

as wxWindows/wxPython improves, so will the capabilities of
   PythonCard

support editing programs in standard editors (vi, vim, emacs,
   PythonWin, IDLE, etc.) and not be forced to edit in and IDE

RE: [Pythoncard-users] moving menubar and getting rid of stack?

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

> From: Andy Todd
>
> I fully agree with moving the menu, but should it be associated with the
> background, or with the window?

Background in the framework is basically a Window; in wxPython terms it is a
wxFrame that contains a wxPanel. The list of 'components' could be a
separate entity such as a Panel or Layout or Group or Box or something else
that can't have a menubar, statusbar, scrollbars, etc. Even if we decide on
a different organization, we may have to wait a few releases before the
change can be implemented given the state of the framework.

> A window is the major component of an application (but it can have more
> than one), and an application must have at least one. All of the GUI
> toolkits that I have used have associated menus with the window rather
> than the background, but we don't have to stick with that metaphor if we
> don't want to.

As mentioned earlier, we have been doing Single Document Interface (SDI) so
each window can have a menu or not. worldclock doesn't have a menu. I don't
know how this will translate to the Mac. The Mac only has one menubar for an
application. I expect that once we have a wxPython Mac port we're going to
have to work through a variety of design and GUI issues.

> The separation of the window from the background is quite a powerful
> 'feature'. One of the neat things you can do in Oracle forms is
> dynamically/programatically swap the canvases (backgrounds in our
> terminology) within a window. This allows some pretty fancy layout - but
> then again may be too complicated for our kind of applications. Its a
> feature that I have used in the past, but I don't have a sample
> application in mind which would need it - yet.

Yes, this is a bit more like HyperCard. This still feels like an app that
should be built on top of the framework and not the framework itself. What
do other people think?

ka

Re: [Pythoncard-users] moving menubar and getting rid of stack?

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

Kevin Altis wrote:

> It is a simple change to push the menubar down from the stack to the an
> attribute of the background which is where I think it should be. It does
> mean I have to move the menubar in all of the the .rsrc.py files and update
> the resourceEditor and a few other files, but I want to do that before I
> dive into any deeper changes. It shouldn't impact any user code.
> 
> The Stack class no longer has a purpose in the prototype model since there
> is really only one Background and that is likely to just become one of many
> Windows or Forms or Layouts... of the app. We already get the current
> background from the app, not the stack.
> 
> bg = pcapp.getCurrentBackground()
> 
> Removing stack will also shorten some of the existing sample code and
> framework elements that refer to application attributes and methods will be
> shortened:
> 
>   self.stack.app.applicationDirectory
> becomes
>   self.app.applicationDirectory
> 
> Removing Stack will actually require even more resource changes and
> framework fixes, so I won't start that until after menubar is moved and I
> have a chance to go through some of the details. We can continue to use the
> convention that the first background in the list of backgrounds is the
> "main" background until we think of a better organization.
> 
> Like everything in the framework and samples, this is open for discussion,
> but if there is none, I'll check in the changes sometime tomorrow.
> 
> I'm very eager to push the framework further ahead this month to help with
> these discussions about terminology and names. Everyone should continue to
> reply to the "What Do We Call These Things?" thread while I put my coding
> cap back on :)
> 
> ka
> 

I fully agree with moving the menu, but should it be associated with the 
background, or with the window?

A window is the major component of an application (but it can have more 
than one), and an application must have at least one. All of the GUI 
toolkits that I have used have associated menus with the window rather 
than the background, but we don't have to stick with that metaphor if we 
don't want to.

The separation of the window from the background is quite a powerful 
'feature'. One of the neat things you can do in Oracle forms is 
dynamically/programatically swap the canvases (backgrounds in our 
terminology) within a window. This allows some pretty fancy layout - but 
then again may be too complicated for our kind of applications. Its a 
feature that I have used in the past, but I don't have a sample 
application in mind which would need it - yet.

Just my stream of consciousness, please feel free to tell me I'm an idiot.

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

RE: [Pythoncard-users] Re: What Do We Call These Things?

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

> From: Dan Shafer
>
> I'm inclined to agree with the other old 'Card fart here (back at ya,
> Danny!) when he says that HyperCard probably carries around a tad too
> much baggage to be useful in this situation. And Kevin's point that
> an app built on top of PythonCard (or whatever we end up deciding to
> call it) that provides the lightweight data storage automation that
> HyperCard users know and love is probably a better direction anyway.

We (okay Rowland and I) have been carrying around a lot of design baggage
from HyperCard imposing arbitrary limitations of a stack/background/card
metaphor on the framework since July along with the notion of an actual
controlling PythonCard application like the HyperCard application was with
stack documents, even though we got rid of the loader many months ago. It is
much easier to free the framework now to be much more flexible and put the
HyperCard metaphor back on top of a more robust underlying design than to
try and squeeze many of these other ideas we have into an overly restrictive
model.

> I'm fine with calling these things we create applications rather than
> stacks. But the other terms for the components leave me cold and
> wondering if I'm working in Visual Basic again. (That's OK. It's a
> recurring nightmare.)

So, tell me about your childhood. Mr. VB beat you, didn't he? Yes, that's
it, share your feelings. ;-)

But seriously, we should be explicit about what is bad about VB. Being able
to put components together is good. Simple layout is good. We just need to
leave out the icky parts of VB and the same goes for HyperCard...

> So after spending some time noodling about this, here's a concrete
> proposal that we can at least start shooting at.
>
> A Monty application's visible interface consists of one or more
> Master Layouts which define sets of components that are common to all
> Windows that share a given Master Layout. Windows optionally have
> additional components that are not defined in their Master Layout.
> One type of component is a Pane, which is a container for other
> components. It is legal to nest Panes. The simplest case is a Window
> which is identical to its Master Layout in every respect.
>
> Just a straw person. Let's beat it up!

I don't have a concrete opinion yet, I want more elaborate and complex
samples to help us decide what to use and what to drop and what to name
things. And I would like to see more people that want to shape this thing
throw their hats in the ring as well and slap some programs together and
then make their opinions known on what they like and don't like and what
they want and don't want. If you don't vent now, you can't legitimately
complain later.

We are at the fluid stage where the magic happens.

ka

[Pythoncard-users] moving menubar and getting rid of stack?

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

It is a simple change to push the menubar down from the stack to the an
attribute of the background which is where I think it should be. It does
mean I have to move the menubar in all of the the .rsrc.py files and update
the resourceEditor and a few other files, but I want to do that before I
dive into any deeper changes. It shouldn't impact any user code.

The Stack class no longer has a purpose in the prototype model since there
is really only one Background and that is likely to just become one of many
Windows or Forms or Layouts... of the app. We already get the current
background from the app, not the stack.

bg = pcapp.getCurrentBackground()

Removing stack will also shorten some of the existing sample code and
framework elements that refer to application attributes and methods will be
shortened:

  self.stack.app.applicationDirectory
becomes
  self.app.applicationDirectory

Removing Stack will actually require even more resource changes and
framework fixes, so I won't start that until after menubar is moved and I
have a chance to go through some of the details. We can continue to use the
convention that the first background in the list of backgrounds is the
"main" background until we think of a better organization.

Like everything in the framework and samples, this is open for discussion,
but if there is none, I'll check in the changes sometime tomorrow.

I'm very eager to push the framework further ahead this month to help with
these discussions about terminology and names. Everyone should continue to
reply to the "What Do We Call These Things?" thread while I put my coding
cap back on :)

ka

RE: [Pythoncard-users] running python/wxpython on the Mac with emulation?

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

I only got two replies to my post, but if I get any more I'll email another
follow-up.

Dan Shafer confirmed that VirtualPC works fine (as one would expect), he
even used an old version, 3.0 on his Mac. This is a Windows Python/wxPython
emulation solution.

Pim Buurman responded with this GTK solution under OS X:

My "solution" for using wx on Mac OS X:
- I installed the XFree X-server and X-prog packages
- Then I compiled gtk
- Then I compiled wxGTK 2.3.2
- Then I compiled python (terminal version, i.e. plain UNIX version)
- Then I compiled wxPython with this python
I now have a command-line python, with which I can run any wxPython app

This is actually very interesting to me for testing purposes because it
looks like I could have an OS X box and test both wxPython Mac and wxPython
GTK on that machine once wxPython Mac is available.

I'm looking forward to hearing from other people using wxPython via
emulation on the Mac.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, January 07, 2002 12:55 PM
> To: Wxpython-Users; pyt...@py...; pythoncard-Users
> Subject: [Pythoncard-users] running python/wxpython on the Mac with
> emulation?
>
>
> Note, if you send me a reply directly, I can post a summary to the lists.
>
> I don't currently use a Mac (the old Performa I have with System 7.5 isn't
> really that usable), but there are quite a few people interested in the
> PythonCard project that only use Macs, so they are waiting for
> wxPython Mac
> to be finished.
>
> What I'm wondering is whether any of the free or commercial emulation
> solutions would be good substitutes until wxPython Mac is
> available for use
> with MacPython? Basically, they would just run a version of Python and
> wxPython (win32 or GTK) for either Windows or Linux depending on the
> emulation solution.
>
> Is anyone already doing this on their Macs? Either OS classic or OS X? If
> so, could you provide details of the configuration and installation or any
> tricky parts of getting it to work?
>
> Some possibilities:
>
> VirtualPC
> http://www.connectix.com/products/vpc5m.html
>
> Bochs
> http://bochs.sourceforge.net/
>
> VMWare
> http://www.vmware.com/
>
> plex86
> http://www.plex86.org/
>
> XFree86
> http://www.xfree86.org/
> I had one person suggest "Just use wxGTK under Xfree86 in
> rootless mode..."
> on OS X.
>
> Thanks,
>
> ka
> ---
> Kevin Altis
> al...@se...
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] GTK/Linux fixes

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

Cliff Wells and I worked through some more Linux/GTK issues today. I updated
findfiles.py, resourceEditor.py, and samples.py launcher code to put
launched scripts in the background:

os.system(python + ' ' + filename + args + ' &')

instead of

os.system(python + ' ' + filename + args)

Cliff has suggested wrapping up the launching functionality to hide platform
differences and this is probably a good candidate for the utils.py module
since we already have four samples that do some launching; Simon is updating
textRouter and will check that in later. Anyway, the change above should
mean that the launching script no longer stops updating while it waits for
the launched script to terminate. *nix folks are welcome to suggest better
solutions.

I updated the imagebutton.py component module to take care of a difference
between how Windows and GTK update the bitmap of a wxBitmapButton, which is
what ImageButton uses as a delegate.

    def _setBitmap( self, aValue ) :
        self._bitmap = aValue
        bmp = aValue.getBits()
        self._delegate.SetBitmapLabel(bmp)
        if wx.wxPlatform != "__WXMSW__":
            self._delegate.SetBitmapDisabled(bmp)
            self._delegate.SetBitmapFocus(bmp)
            self._delegate.SetBitmapSelected(bmp)
        self._delegate.Refresh()

I've posted a note on wx-dev asking whether I found a bug or this behavior
is expected. Note that when we move the components to an IS-A class
structure instead of the current HAS-A structure where the wxPython controls
are delegates of the PythonCard component classes, the wxPython methods
above will be exposed so that you can set the separate bitmaps if you want.

I just don't want to add methods for that functionality right now since it
is a waste of time. It is the same reason I haven't added a combobox, tree
control or some of the other wxPython controls. I expect to switch to direct
IS-A subclasses Real Soon Now.

I changed the worldclock sample to use an Image instead of an ImageButton. I
left the tictactoe sample using ImageButtons. That way we have tests that
switch bitmaps after initialization with both component types.

ka

Re: [Pythoncard-users] Re: What Do We Call These Things?

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

David LeBlanc wrote:

> On a more serious note...
> 
> Two or three (or four) questions spring to mind:
> 
> 1. What baggage does using the Hypercard metaphor bring along?


Plenty, but more about that later. I think the more important issue is 
whether or not we see this baggage as a good thing or a bad thing. I'm 
fairly ambivalent but recognise that the terminology can confuse the 
novice user who has no knowledge of Hypercard. As the model for 
PythonCard is only *like* Hypercard I think we can pick and choose at 
will. The consensus seems to be that the terms stack and card aren't 
necessarily super intuitive and should be replaced. So, here is my $0.02,

Use the terms application and window as previously discussed. They are 
nearly enough universal that a simple note in the documentation or FAQ 
will suffice to explain them to people who don't do development on a day 
to day basis.

I like Dan's proposal (see below) of 'Master Layouts' but I'm sure we 
can improve the terminology ;-)

One concrete proposal I have is that I've never really got on with the 
word 'pane'. I prefer the term 'block', which I think is more intuitive 
- e.g. this is a block of widgets and it lives in that window.


> 
> 2. Just exactly _who_ is the intended audience and application domain?


Whoever we want it to be. A superficial search of the mailing list 
archives and the web site doesn't shed any light on the subject. Now 
this isn't necessarily a bad thing, as we haven't restricted ourselves 
to a specific target audience. But in the interests of clarity, how 
about this for a first stab;

"""
PythonCard is designed to be an application development framework for 
use by everybody. Its purpose and goal is ease of use and increasing 
productivity. From the first time to developer to the veteran coder who 
knows a dozen languages, PythonCard is designed to allow you to quickly 
and easily design and build fully functioning applications with a 
graphical user interface.
"""

> 
> 3. Having just reviewed the PyCard website, I don't recall seeing any
> mention of what the scripting language for PyCard is to be - if it's going
> to be Python itself, that sets the bar at a certain level from the outset
> (answers part of the who in question 2 for example).


Err, to quote the 'Introduction' on http://pythoncard.sourceforge.net/ ;

"This is a project to build a HyperCard like tool in, and using, the 
Python language."

Which I would have thought was a give away. Perhaps we should be more 
specific, perhaps change the language in that sentence or write a whole 
new introduction. Do you want to give it a try?

> 
> 4. Is there a spec?


Certainly not, we are adhering to only the best principles of software 
development. Or at least the 'suck it and see' method of software 
development ;-)

The prototype (which is what we are still playing with) is intended to 
be a playground for trying out ideas and models. Once we have settled on 
a useable and acceptable set of functionality, and are bored with typing 
"C:\Python\PythonCardPrototype" (or equivalent) we can move on from the 
prototype stage, shorten the name of the package and even think about 
writing a specification. I've started to muck around with formats and 
style for functional specifications (see 
http://www.halfcooked.com/CityDesk) and, as usual, the feedback has been 
deafening. I was planning to adapt this style to the framework as a 
whole, but am waiting for it to settle down a bit first.

> 
> Ok, enoug seriousness - I like PyCard; mascot: Jean Luc PyCard of course :>


But he can't be our mascot, he's not a cartoon character. I vote for 
Eric the half a bee.

> 
> And, if you didn't like 3 Card Monty, how about the Full Monty? And for the
> older members of our television audience, how about Monty Hall? Monty
> Cristo, Count of?


All good, although I'm not familiar with the work of Monty Hall - has he 
ever appeared on the BBC?

> 
> And now for something completely different...
> 
> Dave LeBlanc
> 
> 
>>-----Original Message-----
>>From: pyt...@li...
>>[mailto:pyt...@li...]On Behalf Of Dan
>>Shafer
>>Sent: Monday, January 07, 2002 18:55
>>To: pyt...@li...
>>Subject: [Pythoncard-users] Re: What Do We Call These Things?
>>
>>
>>Good, lively discussion.
>>
>>I'm inclined to agree with the other old 'Card fart here (back at ya,
>>Danny!) when he says that HyperCard probably carries around a tad too
>>much baggage to be useful in this situation. And Kevin's point that
>>an app built on top of PythonCard (or whatever we end up deciding to
>>call it) that provides the lightweight data storage automation that
>>HyperCard users know and love is probably a better direction anyway.
>>
>>I'm fine with calling these things we create applications rather than
>>stacks. But the other terms for the components leave me cold and
>>wondering if I'm working in Visual Basic again. (That's OK. It's a
>>recurring nightmare.)
>>
>>So after spending some time noodling about this, here's a concrete
>>proposal that we can at least start shooting at.
>>
>>A Monty application's visible interface consists of one or more
>>Master Layouts which define sets of components that are common to all
>>Windows that share a given Master Layout. Windows optionally have
>>additional components that are not defined in their Master Layout.
>>One type of component is a Pane, which is a container for other
>>components. It is legal to nest Panes. The simplest case is a Window
>>which is identical to its Master Layout in every respect.
>>
>>Just a straw person. Let's beat it up!
>>--
>>Dan Shafer, Author-Consultant
>>http://www.danshafer.com
>>http://www.shafermedia.com
>>

Blimey, I only meant to write a quick two liner. Now back to actually mucking about with code rather than talking nonsense ...


Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Like any cost, size itself is not bad, but unnecessary size is." - 
Frederick P. Brooks, Jr., The Mythical Man-Month

[Pythoncard-users] Running PythonCard on Mac Under VPC

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

I have just run the most basic of tests, but it appears that it is 
entirely possible (albeit slow) to run PythonCard on a Macintosh 
using Virtual PC emulator.

I had some problems with it but Kevin figured out that I had probably 
bollixed the file format by unzipping the file on my Mac and then 
moving it to the VPC. Sure enough, unzipping again within the Windows 
emulator worked like a charm.

I'll let the list know if I run into any other glitches. I'll try 
running this way tomorrow since I'm just doing a little messing 
around anyway at the moment.
-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

[Pythoncard-users] Errrm...

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

For the moment - and for the record:

	PyCard<tm>

PyCard is claimed as a trademark of David LeBlanc. All rights reserved.

David LeBlanc
Seattle, WA USA

RE: [Pythoncard-users] Re: What Do We Call These Things?

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

On a more serious note...

Two or three (or four) questions spring to mind:

1. What baggage does using the Hypercard metaphor bring along?

2. Just exactly _who_ is the intended audience and application domain?

3. Having just reviewed the PyCard website, I don't recall seeing any
mention of what the scripting language for PyCard is to be - if it's going
to be Python itself, that sets the bar at a certain level from the outset
(answers part of the who in question 2 for example).

4. Is there a spec?

Ok, enoug seriousness - I like PyCard; mascot: Jean Luc PyCard of course :>

And, if you didn't like 3 Card Monty, how about the Full Monty? And for the
older members of our television audience, how about Monty Hall? Monty
Cristo, Count of?

And now for something completely different...

Dave LeBlanc

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Dan
> Shafer
> Sent: Monday, January 07, 2002 18:55
> To: pyt...@li...
> Subject: [Pythoncard-users] Re: What Do We Call These Things?
>
>
> Good, lively discussion.
>
> I'm inclined to agree with the other old 'Card fart here (back at ya,
> Danny!) when he says that HyperCard probably carries around a tad too
> much baggage to be useful in this situation. And Kevin's point that
> an app built on top of PythonCard (or whatever we end up deciding to
> call it) that provides the lightweight data storage automation that
> HyperCard users know and love is probably a better direction anyway.
>
> I'm fine with calling these things we create applications rather than
> stacks. But the other terms for the components leave me cold and
> wondering if I'm working in Visual Basic again. (That's OK. It's a
> recurring nightmare.)
>
> So after spending some time noodling about this, here's a concrete
> proposal that we can at least start shooting at.
>
> A Monty application's visible interface consists of one or more
> Master Layouts which define sets of components that are common to all
> Windows that share a given Master Layout. Windows optionally have
> additional components that are not defined in their Master Layout.
> One type of component is a Pane, which is a container for other
> components. It is legal to nest Panes. The simplest case is a Window
> which is identical to its Master Layout in every respect.
>
> Just a straw person. Let's beat it up!
> --
> Dan Shafer, Author-Consultant
> http://www.danshafer.com
> http://www.shafermedia.com
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

RE: [Pythoncard-users] Re: What Do We Call These Things?

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

This would be... (wait for it...) Three Card Monty? ;)

I recall a skit on Lupins though ... <g>

Dave LeBlanc

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Dan
> Shafer
> Sent: Monday, January 07, 2002 18:55
> To: pyt...@li...
> Subject: [Pythoncard-users] Re: What Do We Call These Things?
> 
> 
> Good, lively discussion.
> 
> I'm inclined to agree with the other old 'Card fart here (back at ya, 
> Danny!) when he says that HyperCard probably carries around a tad too 
> much baggage to be useful in this situation. And Kevin's point that 
> an app built on top of PythonCard (or whatever we end up deciding to 
> call it) that provides the lightweight data storage automation that 
> HyperCard users know and love is probably a better direction anyway.
> 
> I'm fine with calling these things we create applications rather than 
> stacks. But the other terms for the components leave me cold and 
> wondering if I'm working in Visual Basic again. (That's OK. It's a 
> recurring nightmare.)
> 
> So after spending some time noodling about this, here's a concrete 
> proposal that we can at least start shooting at.
> 
> A Monty application's visible interface consists of one or more 
> Master Layouts which define sets of components that are common to all 
> Windows that share a given Master Layout. Windows optionally have 
> additional components that are not defined in their Master Layout. 
> One type of component is a Pane, which is a container for other 
> components. It is legal to nest Panes. The simplest case is a Window 
> which is identical to its Master Layout in every respect.
> 
> Just a straw person. Let's beat it up!
> -- 
> Dan Shafer, Author-Consultant
> http://www.danshafer.com
> http://www.shafermedia.com
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 

[Pythoncard-users] Re: What Do We Call These Things?

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

Good, lively discussion.

I'm inclined to agree with the other old 'Card fart here (back at ya, 
Danny!) when he says that HyperCard probably carries around a tad too 
much baggage to be useful in this situation. And Kevin's point that 
an app built on top of PythonCard (or whatever we end up deciding to 
call it) that provides the lightweight data storage automation that 
HyperCard users know and love is probably a better direction anyway.

I'm fine with calling these things we create applications rather than 
stacks. But the other terms for the components leave me cold and 
wondering if I'm working in Visual Basic again. (That's OK. It's a 
recurring nightmare.)

So after spending some time noodling about this, here's a concrete 
proposal that we can at least start shooting at.

A Monty application's visible interface consists of one or more 
Master Layouts which define sets of components that are common to all 
Windows that share a given Master Layout. Windows optionally have 
additional components that are not defined in their Master Layout. 
One type of component is a Pane, which is a container for other 
components. It is legal to nest Panes. The simplest case is a Window 
which is identical to its Master Layout in every respect.

Just a straw person. Let's beat it up!
-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

[Pythoncard-users] RE: running python/wxpython on the Mac with emulation?

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

I have Virtual PC 3.0 installed running Win98 so I thought I would 
give this a shot.

No joy.

I downloaded and installed Python 2.1.1 from Python.org. It works 
fine at least as far as I can tell.

I downloaded wxPython 2.3.2.1 and installed it. It works fine. Its 
built-in demo launches and runs.

I got Kevin to send me the latest ZIP file of PythonCard because SF 
was flaky. I unzipped it, placed the PythonCardPrototype folder in 
the lib folder, and then tried launching minimal. I get no results at 
all. If I try to launch by double-clicking the minimal.py file, There 
is a short pause in the system while it apparently _tries_ to launch, 
but nothing ever shows up. From the DOS command prompt, I get a 
similar result. There is a brief pause while the disk activates, it 
appears something is trying to work, but I'm immediately returned to 
the DOS prompt with nothing else appearing on the screen.

I'm game to keep trying to make this work if someone has any ideas 
how to proceed. But I'm stymied.
-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com