Re. PythonCard - was Re: Event-driven GUIs ...
Spicklemire, Jerry
Neil suggested:
"However, the market, which was given several HyperCard like products to
choose from, has decided against this form of development environment."
to which Roman replied:
"The market ways are unpredictable, because decisions are made not on the
basis of technical merits but with some strange reasoning behind."
Just my $.02 about "the market" where Open Source and FREE software
is concerned. There is actually something of a parallel universe
phenomenon at work, an inevitable side effect of the Web and it's
predecessors. Python is a great example of a tool that is virtually
invisible to "the market", but which has been thriving nonetheless.
Think Linux, prior to about 1997.
As many Java and C++ refugees frequenting these lists can attest,
"the market" no longer has the last word. We're witnessing the
birth of a "paramarket". Python has risen on its merit entirely
independent of "conventional wisdom", "market forces", "public
relations", "strategic imperative", and other counterproductive
distractions.
So, as for Python Card- Go For It! If HyperCard faded due to
"extenuating circumstances", perhaps a comeback is in order.
Later,
Jerry S.
Kevin Altis
time and built a variety of add-ons and stand-alone applications, including
Organizer + (a PIM), my first commercial app. Anyway, Python is the closest
I've come to the fun I had creating and exploring in HyperCard, but of
course, Python "out-of-the-box" is much more capable at doing real-world
tasks and interfacing to other components and applications. As others have
said, what is missing is the tight coupling of a GUI environment. All of the
current GUI solutions feel like work, compared to whipping up something in
Visual Basic, Delphi, etc. Given that many people think MS has basically
broken whatever simplicity VB had with the transition to VB .NET, there is
actually a huge opportunity to woo VB developers over to Python if a
commercial-quality Python GUI/IDE environment was available.
I'm guessing that at some point, O'Reilly will probably catch a clue and
write a "Python for VB programmers" book, but they haven't done a "Python
for Perl programmers" book yet, so I may be wrong.
Getting back to HyperCard. Remember that HC was closed and proprietary and
the HC team tooks its sweet time in adding features. Color support was
always a hack job and even though 2.0 added printing, menus and other UI
elements that looked like what users expected on the Mac, it was difficult
to impossible to actually create an HC app that had the Mac look and feel
and operated the way a Mac user would expect. In Python terms, it is like
trying to make a first-class app for Windows or the Mac using tk, you just
can't do it, your app will always look like a tk app. The good news is that
wxPython (and maybe other UI toolkits or DHTML/DOM) looks like it will fit
the bill. HC was also difficult and error-prone to extend, Python is easy to
extend.
So, I'm in favor of a PythonCard environment as well as a set of modules
that would ship with the standard distribution, to simplify running anything
built in PythonCard. If enough people are interested, we could even form a
SIG. It would probably benefit everyone to take a look at projects such as
Sash http://sash.alphaworks.ibm.com/ and Squeak http://www.squeak.org/ to
better define what people want and don't want. If you wanted to run
arbitrary PythonCard code from the net, then you probably want to run the
Python interpreter in some form of restricted mode, and/or require digital
signatures to be associated with projects to reduce the risk of running
viruses, trojans, etc. Right now, Python by default is wide open.
ka
"Spicklemire, Jerry" <Jerry.Sp...@IFLYATA.COM> wrote in message
news:mailman.992975010...@python.org...
Chris Barker
> what is missing is the tight coupling of a GUI environment.
I'm not sure if I mean the same thing as Kevin, but this is a big
problem. ALL the GUI options for Python (tkinter, wxPython, PyQT, PyGTK,
etc.) are wrappers around a GUI toolkit made for some other laguage, for
some other purpose. This is a major limitation. What Python needs is a
Native GUI toolkit. Guido talked about it in the past, saying that the
interface would likely be something like tkinter, but nothing is
happening on that front.
What I imagine is this:
A GUI library that is built for Python, that interacts well with the
Python library and all the native type. This library would, for
instance, expect to get a Python list whne is needed a list of items. It
would be written in C++ (or maybe C). It would be platform independent.
The strength in this approach is that the core library could just as
easily be extended in either Python or C/C++. This way, the community
could develop nice higher-level widgets and really expand the toolbox.
It could be used from either C/C++ or Python. This way, one could
develop a C/C++ app with an embedded python interpreter, and GUI code
could be run from either language, the transition would be easy.
Many of these features now exist in wxPython. That is why I am using it.
However, wxPython is a thin wrapper around a C++ class library. This is
a good thing because it allows common documentation and the wrappers can
be produced with SWIG. It is a bad thing because you end up writing
Python code that is not natural (pythonic), and a whole lot more verbose
and complex than it needs to be. It also suffers some from performance
issues do to translating from Python lists to wxLists, generating
wrappers around C++ objects, etc. I don't understand the details, but
the issues are there. wxWindows and Python also share a lot of duplicate
functionality: sockets, database access, process control, file system
manipulations, etc. etc.
This doesn't mean that we would have to start from scratch, I'm sure a
lot of the underlying code from wxWindows, or Fox, or FLTK, or GTK, or
whatever could be used, but it would be a substantial effort.
If such a toolkit existed, PythonCard would be a whole lot easier to
write, as would many other tools.
Unfortunatly, Python is suffering, in this respect, from an Free
Software problem: people build what they need, and putting a wrapper
around an existing toolkit gets them something that works, with a whole
lot less effort than writing something new. So we now have ten wrappers,
and no native toolkit. :-(
Well, I've proposed, and I've whined, and I have neither the time nor
the skills to do it, so I'm done for the moment.
-Chris
--
Christopher Barker,
Ph.D.
ChrisH...@home.net --- --- ---
http://members.home.net/barkerlohmann ---@@ -----@@ -----@@
------@@@ ------@@@ ------@@@
Oil Spill Modeling ------ @ ------ @ ------ @
Water Resources Engineering ------- --------- --------
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------
phil hunt
>
>So, as for Python Card- Go For It! If HyperCard faded due to
>"extenuating circumstances", perhaps a comeback is in order.
What would a PythonCard be like?
Would it be designed more or less as a clone of Hypercard?
Or would it keep the ideas, but be a reimplemenation from
the ground up, scriptable in python and drawing lessons from
the success of the WWW (and possibly having a web interface)?
Thoughts, anyone?
--
## Philip Hunt ##
## ph...@comuno.freeserve.co.uk ##
Ron Stephens
Well, if I can contribute anything, I certainly will. Although a rank
amateur, with enough work who knows? Anyway, I just got my 11 year old son
Michael up here to read this thread and comment. Believe it or not, he knows
and uses C extensively and is learning C++. (Hey, he'll be 12 in a month and
he's lot smarter than I am) ;-)))
Perhaps it would be interesting to ask members of this list to list features
and/or attributes of an "Ideal" event driven gui creation package for
Python.
My own simple contribution would be my desire to have a very simple, easy to
use, program to create HTML Forms and Table Objects, along with the ability
to attach properties, attributes and methods to the objects, and the ability
to recognize events and take the called for actions. Couldn't a
Hypercard-like system be used to achieve the above aims?
If a first-pass , simple form of this program existed that could be used to
create user inputs and outputs and web scripts with Python, although that
may seem trivial and worthless to advanced programmers, it might attract
hordes of Python newbies and webmasters.
Would creating such a simple prototype and seeking user feedback be useful
to further refinement of more strategic goals, tools and methods???
While my son might someday contribute in C or C++, might a simple Python
language prototype reveal interesting outcomes?
I am interested in this project.
Ron Stephens
P.S. I just checked SourceForge and a PythonCard project already exists! The
only information about it is, perhaps not surprisingly, not exactly what any
of us has in mind ;_))) See below::::
(from SourceForge)
"""A card file program (in the spirit of Apple's HyperCard) designed to
store and search thousands of cards
containing megabytes of
text. Uses gzip to compress text. Uses
superimposed coding
(signature file indexing) for fast
searching. Written in Python"""
Ron Stephens
HyperCard-like gui creator, since it was first mentioned yesterday by Roman
Suzi...
Roman Suzi
Heil Hodgson
Jerry Spicklemire
Kevin Altis
Chris Barker
Phil Hunt
and myself...
Ron Stephens
when he thinks of "PythonCard"..still, an intriguing amount of interest in 24
hours...
Kevin Altis
various ideas, goals, what people do and don't want, etc. If someone that is
already familiar with setting up a project on sourceforge or another space
could go ahead and do so that would be great. If that won't give us a mail
list or some other form of threaded discussion forum, then we could just
create a Yahoo groups list, set up a manilasite, etc.
Given what people have said so far I think we have at least two if not three
different goals in mind.
ka
"Ron Stephens" <rds...@earthlink.net> wrote in message
news:3B2EADB0...@earthlink.net...
Neil Hodgson
> (from SourceForge)
>
> """A card file program (in the spirit of Apple's HyperCard) designed to
> store and search thousands of cards
> containing megabytes of
> text. Uses gzip to compress text.
Uses
> superimposed coding
> (signature file indexing) for fast
> searching. Written in Python"""
One of the most hyped aspects of HyperCard initially was its text
searching feature which used content hints (I imagine a form of lossy/fuzzy
hashed index) to allow fast searching in many cases without the storage
overhead of complete indexing.
Neil
Neil Hodgson
I'd like, at least initially, a fairly straight clone of HyperCard but
with true colour graphics. While my other open-source activities don't leave
much time for contributing, I'd be able to do a script editor / debugger.
Is it time to have the toolkit war?
How suitable would ZODB be as the persistence back end?
Neil
Carl Fink
> Anyway, by my count 7 people have expressed some sort of interest in a
> HyperCard-like gui creator, since it was first mentioned yesterday by Roman
I'm a fairly experienced Asymetrix ToolBook developer. TB's
scripting language is OpenScript, which seems to be HyperCard on
steroids. I'm very interested. If I ever learn enough Python, I
would certainly contribute.
I see it as having a *development environment* similar to ToolBook --
that is, the running interpreter loads and dynamically runs the
components of the program being worked on. There's also an
"immediate window" in which code snippets can be directly typed and
executed. A really good help system would be a must (and might be
where I could make a direct contribution, if only *because* I'm a
Python tyro and can see it from a beginner's viewpoint).
The scripting language should definitely be Python.
Event handling should be HyperCard/ToolBook-like. Each object (in
the sense of something you draw in the GUI painter) should have its
own event handlers, scripted in a property of that object. For
instance, a button would have a script property "on buttonClick"
script defining what to do when a single-first-mouse-button-click
event is received.
The runtime should be Python itself, not some special library. There
should be the ability to package up any addons, though.
--
Carl Fink ca...@dm.net
I-Con's Science and Technology Programming
<http://www.iconsf.org>
Ron Stephens
would love to contribute. I would think the hardest part would be to find a
couple of truly competent leaders, who are expert programmers, sort of our own
mini-Linus's or Guido's. The leaders could then moderate the "toolkit wars" and
make final decisions.
My guess is it might be extraordinarily hard to find such leaders for an open
source project like this ;-(((((.
One could only suggest Roman Suzi and Neil Hodgson since they were the first two
to mention HyperCard. (and it sounds like they know what they're talking about)
Anyway, should anyone be foolish enough to reluctantly volunteer as fearless
leaders, it looks like they could expect lot of eager followers...
Of course one would hope that some of the followers could actually produce good
code...;-)))))
rs
Kevin Altis
http://groups.yahoo.com/group/pythoncard
Joining the list is a relatively small hurdle, so hopefully a reasonable
number of people will join and start discussing. I'll act as fearless leader
until someone else wants the job or sets up a better area for discussion. I
think this idea is at least worth taking through the early idea and design
phases. If it still looks good and there is consensus on the direction then
we can get started on coding.
ka
"Ron Stephens" <rds...@earthlink.net> wrote in message
news:3B2EC98E...@earthlink.net...
Robin Dunn
> What I imagine is this:
>
> A GUI library that is built for Python, that interacts well with the
> Python library and all the native type. This library would, for
> instance, expect to get a Python list whne is needed a list of items. It
> would be written in C++ (or maybe C). It would be platform independent.
> The strength in this approach is that the core library could just as
> easily be extended in either Python or C/C++. This way, the community
> could develop nice higher-level widgets and really expand the toolbox.
> It could be used from either C/C++ or Python. This way, one could
> develop a C/C++ app with an embedded python interpreter, and GUI code
> could be run from either language, the transition would be easy.
>
> Many of these features now exist in wxPython.
I'd say nearly all, but that's just my slightly biased opinion... <wink>
> That is why I am using it.
> However, wxPython is a thin wrapper around a C++ class library. This is
> a good thing because it allows common documentation and the wrappers can
> be produced with SWIG.
But arguably not a *Good Thing*. Mainly it just reduces complexity enough
that one single ordinary human can develop, enahance, maintain, and find/fix
bugs in the package and still have time for a real job and a bit of a life.
SWIG doesn't generate the best code, but it means that there is around a
quarter of a million lines of code that I don't have to maintain and debug
by hand!
> It is a bad thing because you end up writing
> Python code that is not natural (pythonic), and a whole lot more verbose
> and complex than it needs to be.
Since I have a strong C++ background I look at the world with an intermixed
C++/Python view, so I often have a hard time seeing the "non-pythonic"
issues with wxPython but I know they are there. I've addressed many of them
at the SWIG layer and there have been a few contributions for the
wxPython.lib package for some more pythonic things at the Python layer.
I'll accept all contributed code that makes things easier.
> It also suffers some from performance
> issues do to translating from Python lists to wxLists, generating
> wrappers around C++ objects, etc.
I've recently had some ideas and added items to my todo list that will
probably help out in this area, so I think this will become less of an issue
over time. On the other hand, for a large majority of things wxPython is
used for it is fast enough already.
> I don't understand the details, but
> the issues are there. wxWindows and Python also share a lot of duplicate
> functionality: sockets, database access, process control, file system
> manipulations, etc. etc.
Much of which can be turned off when compiling wxWindows, but there probably
will always be some overlap with the current architecture.
--
Robin Dunn
Software Craftsman
ro...@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
Roman Suzi
> One could only suggest Roman Suzi and Neil Hodgson since they were the
> first two to mention HyperCard. (and it sounds like they know what
> they're talking about)
>
> Of course one would hope that some of the followers could actually
> produce good code...;-)))))
Wow! I sleeped alittle and the idea of PythonCard growed to
the extent separate maillist were created and I am almost appointed leader
;-)
Well, if you want to look at my failed project, please do:
http://cvs.seul.org/~rnd/index.html
It's a tool for quizzes, stalled at design stage... :-(
Of course, I have some design ideas for the PythonCard,
but I can't lead at this time.
BTW, about leading in Open Source projects,
please, read a thoughtful article at:
http://www.seul.org/edu/oss.project.leadership.html
Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:r...@onego.ru -
Michael Hudson
> Sigh, sounds like we got a lot of folks, of whom I am by far the
> worst, who would love to contribute. I would think the hardest part
> would be to find a couple of truly competent leaders, who are expert
> programmers, sort of our own mini-Linus's or Guido's. The leaders
> could then moderate the "toolkit wars" and make final decisions.
But bear in mind that both Guido and Linus became Benevolent Dictators
by springing their open source project onto the world, not exactly
fully formed, but at least in a usable state. All it takes is for
someone to sit down and bang out somethign that people can play with
and then improve. You do need someone with a strong architectural
sense to avoid it getting unbearably crufty though.
Hmm, I don't really have any plans for July...
Cheers,
M.
--
This is an off-the-top-of-the-head-and-not-quite-sober suggestion,
so is probably technically laughable. I'll see how embarassed I
feel tomorrow morning. -- Patrick Gosling, ucam.comp.misc
Andrew Kuchling
> How suitable would ZODB be as the persistence back end?
I know nothing about HyperCard, but the ZODB is quite nice for making
a set of objects persistent. The only problem is that getting the
ZODB without Zope is a pain (which is the reason why I started
packaging it), and it needs some polishing to make it a bit more
convenient to use.
--amk
Michael Hudson
> Well, I started a separate mailing list.
> http://groups.yahoo.com/group/pythoncard
Could you rig it so the archives are publically readable? I can't
think of any reason why it shouldn't be (& I've never successfully
logged into YahooGroups's website).
Cheers,
M.
--
Programming languages should be designed not by piling feature on
top of feature, but by removing the weaknesses and restrictions
that make the additional features appear necessary.
-- Revised(5) Report on the Algorithmic Language Scheme
Kevin Altis
messages yet. I'm open to suggestions for another place to run a mailing
list that doesn't require registration.
ka
"Michael Hudson" <m...@python.net> wrote in message
news:m3r8wf4...@atrus.jesus.cam.ac.uk...
Michael Hudson
> Argh, yes you do need to register, sorry.
It says in the heading under "group settings" "Archives for members
only" which suggests that there's some other option (& in fact I know
there's some other option -
qv. http://groups.yahoo.com/group/python-list )
> Well, there aren't that many messages yet. I'm open to suggestions
> for another place to run a mailing list that doesn't require
> registration.
You can subscribe without registering (I have!), just not log into the
website. Set the archives to public (I don't know how to do this, I'm
afraid, but I'm certain it can be done), and *I'll* be happy enough.
Cheers,
M.
--
This makes it possible to pass complex object hierarchies to
a C coder who thinks computer science has made no worthwhile
advancements since the invention of the pointer.
-- Gordon McMillan, 30 Jul 1998
Will Ware
> ALL the GUI options for Python (tkinter, wxPython, PyQT, PyGTK,
I don't know much about HyperCard (tho back when it was in vogue, I
heard various stuff about how cool it was) but it certainly seems that
the essential core of its coolness ought to be transferable to Python.
Couldn't the kind of system agnosticism you've described here be
achieved by using the Glade XML format? It describes a GUI's appearance
and design but leaves its implementation largely unspecified.
Maybe a good idea for PythonCard would be "Glade for Chimps". Offer a
somewhat limited range of functionality (maybe most GUIs can scrape by
with menus, text areas, and radio buttons, or something like that) and
where you can get something together without firing more than a couple
hundred neurons.
--
-----------------------------------+---------------------
22nd century: Esperanto, geodesic | Will Ware
domes, hovercrafts, metric system | ww...@world.std.com
Chris Barker
> But arguably not a *Good Thing*. Mainly it just reduces complexity enough
> that one single ordinary human can develop, enahance, maintain, and find/fix
> bugs in the package and still have time for a real job and a bit of a life.
> SWIG doesn't generate the best code, but it means that there is around a
> quarter of a million lines of code that I don't have to maintain and debug
> by hand!
>
> > It is a bad thing because you end up writing
> > Python code that is not natural (pythonic), and a whole lot more verbose
> > and complex than it needs to be.
>
> Since I have a strong C++ background I look at the world with an intermixed
> C++/Python view, so I often have a hard time seeing the "non-pythonic"
> issues with wxPython but I know they are there. I've addressed many of them
> at the SWIG layer and there have been a few contributions for the
> wxPython.lib package for some more pythonic things at the Python layer.
> I'll accept all contributed code that makes things easier.
Well, I'm one of the folks that have complained, and even suggested
improvements, but not yet contributed anything...
> I've recently had some ideas and added items to my todo list that will
> probably help out in this area, so I think this will become less of an issue
> over time. On the other hand, for a large majority of things wxPython is
> used for it is fast enough already.
That's quite true. The one place we have problems is with drawing code:
passing LOTS of stuff to a DC within a Python loop is just too slow.
Klass' wxCanvas may help that out lot, I've been talking to him about it
quite a bit, and I'm looking forward to using it. For those interested,
check out:
http://www.xs4all.nl/~kholwerd/wxstuff/canvas/
It is a high level vector drawing canvas... it has a lot of promise.
> > wxWindows and Python also share a lot of duplicate
> > functionality: sockets, database access, process control, file system
> > manipulations, etc. etc.
>
> Much of which can be turned off when compiling wxWindows, but there probably
> will always be some overlap with the current architecture.
Well, sure, it just seems redundant, and I think it would be hard to
decide which to use, particularly in a mixed C++/Python App. The current
architecture is really pretty darn good. It works. It works better than
any of the other alternatives that I know of (QT looks pretty procicing,
but the not quite open source issue is a problem, and they don'thave any
intention of supporting MacOS Classic)
I just think a truly integrated toolkit would be so much better, but
there is no way Robin (or any one person) could do it all himself, so
the current solution is a good one.
Mark 'Kamikaze' Hughes
Ron Stephens <rds...@earthlink.net> spake:
I'm quite interested, too. Even simple as it is, Tkinter still
requires a lot of "manual wiring". It should be possible to design
something simpler.
Even just dropping GUI bits into place, binding some primitives like
"switch to card X" and "call Python method Y" to each, would be nifty.
I have some notes and a bit of prototyping for a web-based
hypercardish project, with a "GUI builder" that makes spec-compliant
HTML, a server-side application to respond to events, and a database to
store information persistently. Unfortunately, it's in Java, I do that
enough at work that I don't want to do it for fun, and there's already
Zope and a few others sort of covering that space.
A Pythoncard would be a nice substitute project.
--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"I will tell you things that will make you laugh and uncomfortable and really
fucking angry and that no one else is telling you. What I won't do is bullshit
you. I'm here for the same thing you are. The Truth." -Transmetropolitan #39
Ron Stephens
on a potential PythonCard project. Just click join and follow the steps.
phaw...@connact.com
I'd be careful about public archives on Yahoo, the Yahoo TOS says
Yahoo owns anything posted to public spaces.
>>>>> "MH" == Michael Hudson <m...@python.net> writes:
MH> "Kevin Altis" <al...@semi-retired.com> writes:
>> Argh, yes you do need to register, sorry.
MH> It says in the heading under "group settings" "Archives for members
MH> only" which suggests that there's some other option (& in fact I know
MH> there's some other option -
MH> qv. http://groups.yahoo.com/group/python-list )
--
Patricia J. Hawkins
Hawkins Internet Applications, LLC
phaw...@connact.com
But Berkeley db3 plus bsddb3 is very nice, and very convenient.