pythoncard-users

[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

[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

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
> 

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?

[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

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
>