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

David didn't think I answered him before, so prepare for a more exhaustive
attempt ;-)

Some of the comments below are definitely in the realm of how things get
done in open source. If somebody provides an implementation for an idea and
everyone likes both the idea and implementation or are interested in working
on "fixing" the implementation it gets used, otherwise ideas can fall by the
wayside. Ideas and wish lists without code to back them up are still good
for the list, but ultimately somebody has to code them to make them real, so
you sometimes have to build consensus to get your idea in.

My own philosophy is that I'm not interested in good ideas that can't
actually be built. Since most of the development effort right now falls on
my shoulders, I've been scaling back from what we said we wanted to do back
in July. I'm lazy and pragmatic and take shortcuts whenever possible to get
to a solution. I would rather refactor than get the design right the first
time because later on I know why I'm refactoring and that isn't generally
possible when you try and do good design up front.

Apparently I have an attitude today (a verbose attitude to boot), so
beware...

> From: David LeBlanc
>
> > 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?

If someone is already familiar with one of the above solutions and is
willing to learn Python to take advantage of all the great things it has to
offer, then PythonCard should help fill the void they would find in the area
of building GUI apps.

> > 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.

I was just talking about supported platforms. wxWindows supports all the
different Windows OSes, so as long as we use wxPython we get a free ride.

> > uses wxPython as the cross-platform GUI toolkit
> >     simplifies writing wxPython programs
>
> Will PythonCard further simplify creating GUI's?

Yes. It already does, or at least it seems that way to me compared to the
alternatives available for Python. Vigorous debate on this topic would be
good if someone thinks using wxPython, PyQT, tkinter, etc. is actually
simpler either with or without one of the free/commercial IDE solutions for
each GUI toolkit. In particular I would like to hear about where tkinter is
a superior solution given the current prototype; other than the old argument
"tkinter ships with Python" that is.

My own tkinter sucks bias started with the non-native widget issue and TCL
reliance. The native widget problem is apparently solved with version 8 and
above. But now it comes down to tkinter just feels wrong and I haven't seen
many tkinter/Python apps out there. Most of the book material on tkinter
I've looked at falls into the "toy" apps category. You spend a lot of time
learning how to get even something simple up on the screen and then when you
want to leverage your hard won knowledge to do something useful a solution
like tkinter runs out of steam.

But I would love to hear pro tkinter opinions, what's good about it, good
for beginners and pros, etc. If PythonCard isn't a better solution than
tkinter then we've probably failed.

> > does not preclude the creation of OS-specific applications
>
> Sounds like an extension API would be desirable.

It would be nice to have obvious naming conventions for platform-specific
constants, classes, and methods in wxWindows/wxPython, but those don't exist
in wxPython so you just have to pay attention to where the docs say "Win32
only" or "GTK only" and do appropriate checks in your code. I have checks in
the addresses sample to have it do the right thing depending on what
platform it is running on and whether Outlook is installed on the users
machine. The graphic.py module has similar checks for whether Python Imaging
Library (PIL) is available.

A long time ago I suggested we might want to have an automatic check for
common components which would go into a dictionary or class so that all
PythonCard apps would check for OS platform, availability of PIL, etc. in a
standard way. However, we won't be able to cover everything and people will
always end up having to use their own try/except blocks and asserts to check
for features that might not always be available.

If I wanted to write a really slick Windows app and don't care about it
running on Linux and the Mac I definitely am going to use COM components, so
I just need some appropriate startup checks specific to my app.

> > 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

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.

> Office that
> supports Word, XL and PowerPoint exports to HTML (better XML for
> us IMO). As

These are document exports, not apps. Neil already has the .hta examples in
the PythonCardPrototype directory as an example layout reuse. I can't
imagine anyone doing real web layout wanting to design something in
PythonCard and then export to HTML using our standard tools. The HTML in a
web browser paradigm is generally quite different from a normal desktop app
layout. I'm not ruling it out, I just don't see an obvious path to pursue.

Exporting the document format as HTML/XML... that a particular PythonCard
app uses obviously makes sense, but that is a design decision for the person
building the app. Cliff made a post about his CSV module which seems like a
useful addition and isn't available as part of the Python Standard
Libraries.

Regardless, there is a very low chance of us producing something that would
generate the HTML and JavaScript for an active web page.

> 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".

See JavaScript comment above. Dumb HTML/XML data export, maybe. Smart forms
with script, highly unlikely. If somebody wants to pursue this as an app and
is successful we can roll it into our design. I think this goes back to the
Dave Winer posts which hinted at the Radio Userland 8 approach to layout,
but I haven't looked at Radio 8 yet, so I can't comment further. This topic
should get its own discussion thread.

I will say that I do not want to intrude directly into the domain of
solutions provided by WebWare, Zope, and other web-centric Python projects.
There are more than enough projects and people working in that space
already. What would we add?

> > 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.

Actually, they have to follow the convention or they can't program with
PythonCard. All components in PythonCard have a unique name within its scope
which acts as its id. Numeric ids are only used internally and hidden from
user code. So, btn1 was just a name, it could have been "aReallyCoolFeature'
to give us
  on_aReallyCoolFeature_mouseClick

I have been using the abbreviations like 'btn' and 'fld' in most of my code
to make the type of a component obvious. This follows the recommended VB
naming conventions. In some cases I used 'button' and 'field'.

The enforced convention is that of using 'on' to start an event handler name
and underscores to separate the component name. The naming can still be
changed, but I want to hear a good reason for doing so. The current way
makes the handlers easy to parse, easy for coders to read and write, and
doesn't seem clumsy, at least to me.

> > make it simple to change and reuse parts of PythonCard apps
>
> More API-ness. Packages.

I was thinking of plain modules and resource files or pieces of both. What
are you suggesting?

> > 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.

I don't know what you mean by dynamic layout? A full IDE could certainly do
what you're talking about, I'm assuming that what you object to is that a
layout editor doesn't know about the source code. I am not in favor of code
generators myself, but method stubs are okay.

> > 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?

The automatic event bindings, resource files, a buffered bitmap canvas, dot
notation attributes to name a few. Coming up with a decent list was part of
the reason for the "marketing caps" post I made earlier. In some ways I'm
too close to the framework to describe it well.

> > should be a complete replacement of tkinter for those wanting
> >     to program GUIs with Python
>
> This is distinct from WxPython how?

You can think of PythonCard as a simpler way to use wxPython if you like.
Whether it is or not is debatable. I have yet to meet anyone though that
could use wxPython and be productive quickly after first being introduced to
it. We are reaching a decent usability level with PythonCard, but we have a
long ways to go.

> > 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?

No idea, maybe. Good task for someone to work on other that me. Someone also
needs to make an equivalent installer script for Gordon McMillan's installer
that works on Linux, Windows, and possibly other platforms. We only have
py2exe installer scripts now and they just generate an EXE for Windows.

> > 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).

SOAP doesn't cut it and neither does XML-RPC. They aren't component models.
CORBA is but it is too complex. Anyway, components are the direction we've
started to head and they will be a clear benefit over other Python GUI
solutions if we manage to make them real. If we stumble we'll back off, but
otherwise they are going to happen.

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

No.

> > 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".

I made the comment above because the low-level stuff to make it happen
simply doesn't exist cross-platform and we aren't going to be able to
provide it. We can wrap it when it is available. I just don't want people
thinking this is a full multimedia tool or the equivalent of Flash. Yes we
can do good stuff using ActiveX under Windows but Linux would be out of
luck.

> > 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.

Neil can comment on the time, effort, and difficulty of writing a good
editor. It won't be a walk in the park, but yet that is what we'll most
likely use when the editor in the IDE effort starts or if we do some
experiments with runtime editing of scripts which is possible within limits.

As a notepad clone, the textEditor sample (not in the same league as a
source code editor) took me less than 45 minutes to write
http://aspn.activestate.com/ASPN/Mail/Message/805090
at least for the first version. I wasted a lot more time on the
New/Open/Save/Save As logic, but overall I've got less of a day into it,
mostly because it doesn't do much.

> **********************************************************
> 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.

This is certainly doable, in a way that is what the minimal sample is. The
resourceEditor already using a template.rsrc.py file as its default and you
can change it to suit your most common defaults to save time when building a
new layout.

> SWIG: Relatively effortlessly slurp up "foreign" libraries.

Do you have examples of why we would need direct support of this in
PythonCard?

> 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.)

Why? What is the particular benefit you expect to gain from using XML or any
other Xthingy? I'm not saying it is bad, but we've had this conversation
before on the list and I know what XML will be good for, but I also know
where it is extremely bad or at least less useful than some other solutions.
XML is not magic. My standard position is that XML should never be seen by
human eyes except for debugging purposes. It should be program-generated and
program-consumed and if you have humans typing it you have a lame solution.
On a related note, it is interesting that the wxWindows XML resource format
does not have a DTD, because nobody has been able to figure out how to
express all the possibilities. XML without a DTD has very limited usefulness
outside of the people/programs that agree to share the free form set of
fields.

> How is this different from Boa?

Boa is modeled on Delphi and has a whole lot of other stuff thrown in like
Zope support. While it seems impressive, I also find it slow to start, hard
to figure out how to use, it seems to lack focus, it is a code generator - I
have never found a code generator that didn't cause me problems in the long
run - and overall it just seems bloated and too difficult to use especially
for a beginner. Every time I give it another chance I go away disappointed,
perhaps I'm just missing something, I really wanted to like it the first
time I used it. Riaan has put a huge amount of effort into it, but
unfortunately it is a one man project. If someone knows wxPython and is
comfortable with it and likes Boa, there is no particular reason they
shouldn't just continue to use Boa. Choice is good.

Now, PythonCard is...well, time will tell. Maybe it will only appeal to me
and a few other people, but that's okay. I know wxPython pretty well and I'm
still amazed that I have a hard time writing a wxPython program from scratch
and I certainly can't do many of the PythonCard samples using raw wxPython,
there is just too much to remember.

ka