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

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

> From: David LeBlanc
>
> > > 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
> >
> > I've never seen that in HyperCard. Maybe the most recent
> > SuperCard does it,
> > but it has been a long time since I've used it.
>
> SuperCard offers something called "FlameThrower" (sheesh,
> marketing guys are
> clueless <g>) and latest at www.apple.com/hypercard also advertizes such a
> feature in the latest rev of HC.

I think you are misreading the "marketing speak", neither HyperCard or
SuperCard provide a runtime plugin for a webbrowser that lets you run stacks
the way you would run say an applet or Flash program. You can write stacks
that are called by a CGI program on the Mac via AppleScript or maybe direct
AppleEvents to produce results just like you would call a plain Python
script but that would be a horribly slow solution even on a local machine.

> I keep getting mislead by the "card" in PythonCard. HyperCard is
> primarily a
> means of creating (possibly interactive) documents imo. Stacks
> get read more
> then written or added to (depending on the application of course).

You can create interactive documents as well as what are basically full apps
in HyperCard/SuperCard/Revolution/etc.

> PythonCard keeps sounding like a generic GUI builder - and given antipathy
> towards automatic code generation, only that.

A framework, a GUI builder, runtime tools, an IDE/VDE eventually
(hopefully). As stated many times before on the list, the first goal is to
produce a framework since everything else has to sit on top of that. The
interim resourceEditor (layout editor) and runtime tools will change and
improve as the framework improves. We might be able to do the same with any
work on an IDE.

> I still never mentioned Javascript. An example of what I had in mind is
> creating an HTML form that gathers data and returns it to a
> python app that
> might be it's own webserver. NOT at the level of sophistication of Zope or
> whatever, merely a simple way to create a browser visible GUI.

I guess what confuses me is you were talking about running interactive apps
in the browser and that means using JavaScript. Or were you only talking
about generating plain HTML forms and PythonCard generates the backend logic
to manage data, state, etc.? This sounds like it gets into Zope/WebWare
territory again. A web page minus JavaScript, Flash, or some other embedded
plugin is just a non-interactive series of text and forms like a dynamic
slide show; user fills in data, presses return or hits submit gets back a
new page, repeat. Web browser as 3270 terminal.

Am I still missing what you're describing?

> I looked at the PC codebase, and can't find any place where handlers are
> parsed...
> I did notice that "OnEvent" (where Event could be any word(s)) and
> "on_event" where both used.

class Scriptable in model.py

There is no OnEvent parsing supported, only on_eventName and
on_componentName_eventName styles.

> layout. My definition was about layouts that dynamically adjust themselves
> depending on host constraints (640x480 vs. 1024x768 for example)
> or resizing
> done by the user. AKA "sizers" in WxWindows parlance. I think
> this should be
> a fundamental attribute of the foundation
> panel/canvass/window/whatever that
> users base their design on.

Nobody has been able to come up with an intuitive sizer interface yet. All
of my tries have failed and I probably won't try again for a while.
wxDesigner creates sizer layouts, but it isn't intuitive. I still have to
create a static layout first and then work inside out, testing along the way
until I happen to get something that works. The PythonCard samples using
sizers are all done manually with code. Hopefully, a sizer solution will be
found. We should be able to present constraints in the UI and possibly
FlexGridSizer for simple grids. We'll just continue to work on the layout
options. If you have any ideas about how to do a sizer builder UI start a
separate thread about it, it would be nice to have a solution.

> It's hard to know what PythonCard is absent any document describing it's
> overall design philosphy and vision. It's got widgets, events, attributes
> and resource files: so do WxPython, WxWindows (duh), MFC, and for all I
> know, Gnome and KDE.

Agreed. That is part of the reason for starting this thread. Obviously, any
GUI framework will have a lot in common with other frameworks. The framework
is only part of what we're doing.

> I wouldn't mind seeing PythonCard as a simpler way to use WxPython, but
> after looking at some PC code and some WxP code (in their demo),
> I don't see
> a significant difference in the complexity of the code.
> What am I missing?

Have you written any wxPython programs or PythonCard programs? You probably
need to look at some more complex wxPython examples to do a better
comparison or better yet just sit down and write a few programs and see
where the stumbling blocks are. There is nothing in PythonCard that you
couldn't code in wxPython though you would have to create some additional
classes and methods that wxPython doesn't have. PythonCard sits on top of
wxPython and right now wxPython Lite isn't a bad way to think of PythonCard,
sort of a kinder, gentler wxPython ;-)

> You might not see SOAP as a component model, but that doesn't stop it's
> being (at least usable as) one. Can you name one component model
> that isn't
> complex to some extent (possibly Java Beans)? What is your notion of a
> component model?

We're in the process of defining the component model now, Rowland did a post
a day or two ago. We've mostly been thinking about visual components, but
non-visual should work as well. The idea is to be able to ask a class or
instance its spec is so if you want to use the component in an IDE you don't
need prior knowledge of the component. The analogy would be use of COM
components in Visual Basic. We might be able to use the message format of
SOAP as our specification format, but that seems horribly inefficient when
we can just query the class directly. The visual components won't be usable
outside the context of Python/wxPython since they will rely on both.
Non-visual components could publish a SOAP interface if you wanted to access
them via a web service. Again, I would let Zope and WebWare solve the
problems first and copy them later.

> At this point you're talking about platform independence, yet earlier you
> said you wanted to be able to use COM on Windows if you wanted to.

Right. wxPython lets you write platform-specific code if you want, so
PythonCard can do the same thing. If you don't care about your code running
on Linux or the Mac, then use win32 modules, ActiveX, whatever. The vanilla
framework stuff will be geared towards cross-platform though or clearly
identify options, classes, methods that if used would be platform-specific.

> I agree that BOA is pretty opaque and i've yet to use it successfully -
> alas. You didn't point out what i've finally realized - that PythonCard
> isn't intended as a project to create a development tool, but rather a
> framework.

As mentioned before, the framework is just part of it and the part that has
to be done right for the other parts to be possible and make sense.

> Having realized that this is a project to create a framework and not a
> development tool, it seems to me to be, at this point, WxPython-Lite. What
> am I missing? That's not intended as a criticism or condemnation, only a
> comment.

If the explanations in the previous messages haven't made it any clearer
then somebody else will have to try. You can dive in and start using it
yourself or just wait and see.

ka