RE: [Pythoncard-users] Re: Where is the hypercard GUI interface?

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

> From: Francois Granger
>
> At 12:29 -0800 on 16/11/01, in message Pythoncard-users digest, Vol 1
> #81 - 1 msg, you wrote:
> >thought would be worth sharing with the whole list. This is
> another one of
> >those "what is PythonCard?" kind of threads, so you can add your
> two cents.
>
> Being a lurker on this list and on the naygui one, I don't feel I am
> in a position to say much... Anyway...

Feedback is always appreciated. The general lack of comments on the list is
actually more of a problem than the lack of developers since without
feedback I'm forced to just go with what I'm interested in pursuing for my
own programs which may not be of general interest. People are downloading
PythonCard, but except for a few list regulars, it doesn't appear many
people are really using it and without feedback it is difficult to know what
needs to be changed, so more people would use it.

Simon Kittle's textRouter sample which is one of the most complex PythonCard
apps created so far has been invaluable in pointing out deficiencies in the
framework, but we've mostly been carrying on our discussion off list. We'll
probably summarize some issues here as they are addressed.

> I strongly feel that:
> - There is a need pfor an hypercard replacement on the MacOS (preX)
> side. There are so many casual developpers orphaned of so many good
> scripting products (HyperCard, Frontier, FileMaker....)
> - There is a real need for a multiplateform gui for Python to gain
> real big momentum on the scripting language side.

Agreed. There are multiplatform GUIs for Python already. The problem is the
hurdle necessary to use of them is fairly high and/or you have to make do
with non-native widgets. PythonCard was originally conceived to lower the
barrier to entry. I've pretty much decided that wxPython is the only viable
cross-platform GUI solution (that uses native widgets) for Python. The
question is whether to have minimal helper classes for wxPython or to
attempt and hide as much of wxPython as possible and provide a separate API.
The correct answer is probably somewhere in between.

> I would strongly advocate for a mix (in one way or the other) of the
> two project. This will result on more developpers on the project and
> a lot more potential developper and user base.

There are a variety of people following both projects including Magnus who
is probably most qualified to comment on the anygui goals. So far, it
appears there is some overlap, but there is also a fundamental difference in
focus. Anygui is attempting to create a single API that works across a
variety of GUI toolkits including Jython. While that is an admirable goal,
anygui will not be usable for something like PythonCard until at least
version 0.2 of anygui and even then the capabilities will be less than what
we're doing today with the prototype.

If you draw a line and say I only care about these types of events and these
widgets then it would be very easy to say here's the framework capabilities
and be done rather quickly even with wrapping. The real problem comes in
trying to make something that is simple to get started with, yet can go
beyond the most simplistic of capabilities. What always ends up happening is
someone says that what we have today is great, I just need this one extra
little addition for my own program. One of the interesting aspects of
PythonCard right now, is that it is often easy to mix raw wxPython code in a
PythonCard program to get a solution. That isn't a clean solution, and while
it works, it isn't a good long-term solution.

Then of course, there is the separate issue of building an environment that
wraps up the whole program creation process.

Anyway, please keep the comments coming.

ka