pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] evaluating shelve module

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

shelve is one option we have for creating persistant data. ZODB is another.
We can't use something like anydbm, because the actual files created by
anydbm aren't portable across operating systems, only the source is
portable. Dan Shafer has started looking at shelve as described below. Those
of you interested in this area should share your findings on the list.

The shelve module is documented at:
http://www.python.org/doc/current/lib/module-shelve.html

There is an older tracker item for shelve as well:
http://sourceforge.net/tracker/index.php?func=detail&aid=442150&group_id=190
15&atid=369015

ka
---

Dan Shafer opened up a new tracker item on shelve:
http://sourceforge.net/tracker/?func=detail&atid=369015&aid=506564&group_id=
19015

Summary:
Looking at shelve
I had a chat with Kevin over the last day or two about
document models and decided to dive into the
development effort in a semi-modest way by looking
into persistent object stores for PythonCard.

The shelve stuff looks very straight-forward and
clean, so I'm going to take a first pass through a
couple of quick tests with it.

It is very transparent, fully cross-platform, and
handles any arbitrary Python object.

I'm not yet sure how this factors into or influences
the document model. I think I can make this pretty
transparent as long as we assume single-user stacks.
The shelve we create can be given the same name as the
stack/app transparently to the user.

My first step will be to take the Addresses stack and
switch it from a text file to a shelve for storage,
just to get my arms around the beast and to show two
different document models. Then I'll take one of my
old HyperCard stacks that makes more extensive use of
storage and give it a whirl.

A shelve can be _opened_ for read access by multiple
users but only the first one to open it gets write
privileges (like FileMaker at least used to be), and
there seems to be no way to control this (i.e.,
explicit role or privilege assignment). I think that's
perfectly acceptable, though, don't you?

Since I don't anticipate at this point that we'd even
expose this to a user, who would simply get automatic
data storage and retrieval a la HyperCard, I don't
think we need to wrapper anything.

Exploring it has been fun.

Dan

RE: [Pythoncard-users] project name vote in progress

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

Today is your last day to vote!

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Friday, January 18, 2002 10:43 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] project name vote in progress
>
>
> I'm going to let the vote run for a few days to make sure that
> nobody misses
> a chance to cast a vote. I'll accept submissions through Monday night USA
> west coast time and then tally the votes up Tuesday morning when I get up.
> You don't have to be on the list to vote, so those of you that aren't
> subscribers and are just reading the list archives can send in your votes
> too. One vote per person please and no trickery with using multiple email
> accounts or I may disqualify some entries. There are less than 60
> people on
> the mailing list and I doubt everyone will vote, so tallying
> shouldn't be a
> problem.
>
> Please email me directly, don't post to the list. Just put the name you
> would like to see used for the project in the subject line of your message
> like this:
>
> vote - PythonCard
> or
> vote - Monty
> or
> vote - Snake Oil
> etc.
>
> There have been a lot of name suggestions made by David LeBlanc,
> Dan Shafer,
> and others and I don't want to try and list them all here, so browse the
> archives if you need a refresher. I'm guessing that if you can't
> remember a
> particular name, it probably didn't have much impact on you. You can
> "write-in" whatever name you want to see used, even if nobody has
> suggested
> it before. I would like to put this issue to rest, so be serious about the
> names. We could be using it for the next five to ten years.
>
> ka
> ---
> Kevin Altis
> al...@se...

RE: [Pythoncard-users] FW: tkinter pluses and minuses

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

Here's Laura Creighton's thoughts on tkinter

ka
---

I also am unfamiliar with wxPython.  When I decided what to use, I
asked on the Python list and at the time was told that wxPython leaked
memory like a seive.  It also looked like and effort to make a
GUI system which worked very well with Windows, in the way that
Windows users and programmers find natural.  Not being a Windows
user or programmer, this advantage was wasted on me.  And I had
already programmed in Tk  (I have a Tcl-less Tk that runs over
Limbo somewhere), though not extensively.  What I really liked was
Fredrik Lundh's documentation -- and the fact that when i don't
know how to do something in Tkinter Joe Knapka (or somebody else
on python-list) can tell me how.

In terms of tempting tkinter users --- tk, let alone Tkinter is
a heck of a lot easier to use than earlier GUI systems, especially
given the grid geometry manager.  And for some reason it appeals
to people who don't like GUI systems in general -- the comment
'if you have to have a GUI then you can quickly knock one together 
with tkinter' is one I have heard many times.  But I think that
PythonCard is already an excellent competitor with this audience.

The hard leap for PythonCard, I think, will be convincing people that
it is 'mainstream' enough that it will be supported 5 or 10 years from
now.  The best fix I know of for that is to have a very vigorous, well
funded userGroup who will hire some maintainers on behalf of the
userGroup.  Some Scandinavian libraries have taken that approach to
share the cost of some orphan library software.  But there may be
better approaches.  This is one of the challenges of Open Source
Software, and a new enough one that many good ways to go 'beyond
shrinkwrap' may not have been thought of yet.

Good Luck,
Laura Creighton

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Saturday, January 19, 2002 5:06 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] FW: tkinter pluses and minuses
> 
> 
> Joe Knapka sent me some good comments on tkinter that we should 
> keep in mind
> as we beef up the features of the framework. At some point, we 
> need to have
> a good story to tell to people that might want to convert over from using
> tkinter to PythonCard.
> 
> ka
> 
> -----Original Message-----
> From: Joseph A Knapka
> Sent: Saturday, January 19, 2002 10:33 AM
> Subject: Re: FW: tkinter pluses and minuses
> 
> 
> Kevin Altis wrote:
> >
> > Magnus, suggested that you would be better qualified to answer what is
> good
> > about tkinter, what you like, etc.
> >
> > You can sing the praises of tkinter, beat up on wxPython, 
> PythonCard, etc.
> I
> > just need to get some expert opinion.
> 
> Well, I have no experience with wx or PythonCard. The main
> reason I like Python/Tkinter is that it makes using Tk
> easier than Tcl does, but that's not exactly high praise :-)
> 
> I do like the Tkinter canvas widget, which completely supports
> structured graphics - that is, you can say, essentially,
> "Put a filled circle at location 100,100 with radius 50
> and fillcolor red, and call it CIRCLE_1", and you never have
> to worry about repainting it or any of that - the canvas
> takes care of everything. Later, you can say "Delete
> CIRCLE_1", and that circle (only) will vanish, and any
> effects it had on overlapping graphic items is undone.
> (I intend to implement the Anygui canvas in essentially
> this way.)
> 
> Another thing I really, really like about Tk is
> its layout managers, grid(), place(), and pack().
> My impression is that wx's layout facilities are
> much more primitive than Tk's, which is why I
> haven't even bothered to try wx -- I hate layout
> management, I want to spend as little time worrying
> about it as possible, and Tk makes it easy. I
> suppose I ought to try writing some wx code,
> though, just to see what I'm missing.
> 
> Aside from that, Tkinter supports the usual suspects,
> widget-wise: Text areas (multiline) and entry fields
> (single line), buttons (radio-, check-, push-), labels,
> listboxes, menus, scrollbars... With varying levels of
> convenience. It's possible to bind UI events directly to
> Python code in a simple way:
> 
> widget.bind("<Event description>",callable)
> 
> where "<event description>" can be any event - you
> can bind to keyboard events in list boxes, or
> mouse events in labels, or whatever.
> 
> It's portable - *nix, Win32, Mac. And Tkinter is about
> 83000 times easier than writing UI code in C or C++ directly
> to the Windows or X api, or any low-level UI library that I
> know of... so I rarely use anything else. I've been working
> with Tk for quite a while, under Tcl and Python, so I don't
> much notice the icky parts any more.
> 
> Things that suck about Tkinter:
> 
> (1) Every single UI operation goes through a parse-and-
> interpret by the Tcl interpreter embedded in Tkinter.
> So, it's slow. (Note that this is an artifact of the
> Tkinter implementation - there's a binary API to Tk,
> but Tkinter doesn't use it.)
> 
> (2) While the canvas is very convenient, it too is
> slow, due to its basic nature, not because of the Tcl
> interpreter. You might want a simplified canvas that just
> issues a REPAINT event and dirty-rect data when it needs
> to be redrawn. But no such is available in Tk.
> 
> (3) Sometimes setting up the proper interaction between
> widgets, like scrollbars and list- or textboxes, can
> be confusing. But on the other hand, if you've done it
> once you can always look at the code you wrote before -
> it's always the same. And it's only one line of code -
> just has to be the RIGHT line! But I have to look that
> stuff up every time I do it.
> 
> (4) A working knowledge of Tcl/Tk is extremely valuable,
> if not indispensible, when writing Python/Tkinter code.
> So if you don't already know Tcl, that sucks for you.
> 
> Hope that helps,
> 
> -- Joe

Re: [Pythoncard-users] minimal resource file translation

[Francois G. <fgr...@al...>]

on 20/01/02 22:35, al...@se... at
pyt...@li... wrote:

> From: "Kevin Altis" <al...@se...>
> Just as a test, someone could provide me with the translated text for
> minimal.rsrc.py (the full resource file is shown below).
> 
> The only items below which need to be changed are:
> 
> 'title':'Minimal PythonCard Application',
 'title':'Application PythonCard minimum',

> 'label':'File',
 'label':'Fichier',
> 
> 'label':'E&xit\tAlt+X' } ] }
 'label':'Q&uitter\tAlt+Q' } ] }
> 
> 'text':'Hello PythonCard' },
 'text':'Bonjour PythonCard' },
> 
> Do not change the attribute names: 'title', 'label', 'text'

RE: [Pythoncard-users] minimal resource file translation

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

I see what you're saying about just doing string translation, that makes
sense. Every component in PythonCard has a unique name within its scope. It
would probably be too limiting to require that the names be unique in a flat
namespace for the entire app. If we did have a flat namespace we could just
use:

{
'bgMin':['title':'Minimal PythonCard Application'],
'menuFile':['label':'File'],
'menuFileExit':['label':'E&xit\tAlt+X'],
'field1':['text':'Hello PythonCard']
}

A component could have multiple string attributes, which is why I used a
list and kept the attribute name above.

A more verbose dictionary (yes eventually XML...) where we could just have
string translation might look like a simplified resource format that keeps
the hierarchy and the elements necessary to identify the component at each
level:

  { 'name':'bgMin',
    'title':'Minimal PythonCard Application',

    'menubar':
    {
        'menus':
        [
            { 'name':'menuFile',
              'label':'File',
              'items': [
                { 'name':'menuFileExit',
                  'label':'E&xit\tAlt+X' } ] }
        ]
    },

   'components':
   [
    { 'name':'field1',
      'text':'Hello PythonCard' },
   ]
  }

I omitted the 'type' attribute in the list above, but it might be necessary.
It is trivial to provide a front-end that hides the actual file format, so I
don't think the added complexity would be a problem. So this ends up being a
resource file supplement just dealing with localized strings. This would be
a much simpler app than the resourceEditor (layout editor) since it would be
focused on just localizing strings. I can go ahead and put one together for
the next big release once we settle other open issues. The framework will
default to using the base resourceEditor strings when it can't find a
substitute in the appropriate localization file.

How does that sound?

Given that a layout could require changes when using a different language
and that I still don't expect most users to create layouts with sizers, I
feel we should at least have the option of a full localized resource as
well. Of course, I'm still in favor of Mac, Windows, and Linux layouts too
for the same reason. I expect that the UI guidelins on the Mac are going to
be a bit of a problem with sizers; a sizer layout may never look quite
right. Obviously, sizers are less work in the long run if you want to work
everywhere, but unless we figure out an intuitive interface to creating and
maintaining them, there are going to be a lot of fixed layouts created.

We should be able to support a variety of solutions depending on
user/programmer sophistication and whether they are interested in doing the
localization and/or sizer work.

ka


> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Neil
> Hodgson
> Sent: Sunday, January 20, 2002 5:44 PM
> To: pythoncard-Users
> Subject: Re: [Pythoncard-users] minimal resource file translation
>
>
>     In most cases, it is better to translate the strings used rather than
> the resources. The resources describe aspects of the application that
> translators don't need to modify such as widget layout. Sometimes a
> translation needs more or less space than the original but while this may
> require changing the layout when using fixed coordinates, dynamic layouts
> that use sizers or similar may continue to work. Even on Windows where
> dialogs are generally fixed layouts, other widgets such as menus
> and message
> boxes are self-sizing.
>
>    SciTE was internationalised in version 1.41, 2.5 months ago. It uses a
> simple text file to specify translations in the form original=translation
> (http://www.scintilla.org/SciTETranslation.html). It has been
> localised into
> 7 languages with over 300 downloads of translations so far.
> Translators have
> found the file format easy to work with. It doesn't currently behave very
> cleverly with respect to character sets, assuming the user has chosen a
> system locale that allows showing the characters used. A future
> version may
> require or allow translations to be in UTF-8. Having a simple string
> translation table is a popular scheme used by other software,
> although some
> libraries require the translations to be compiled into a more efficient
> format.
>
>    When a new version of the application is released with additional UI
> elements, you don't want there to be a delay before users of localised
> versions can use it. By using resource based translation, the new features
> are not present until the translation is complete. By using string based
> translation, the new features are available immediately albeit
> with English
> strings. This encourages incremental translation with users able to fix up
> minor additions and contribute the fix back to the original author or
> translator.
>
>    To make string based translation robust against small edits such as
> changing access keys or the presence/absence of "..." or ":" at the end of
> labels, these can be removed from the original versions of the
> strings with
> the endings replaced automatically after the translations if
> present. So for
> the "&Open..." item (where "&" marks the next character as the
> access key),
> the French translation is
> Open=&Ouvrir
>    For more robustness, other transformations such as case
> folding and space
> stripping could be performed.
>
>    Neil

RE: [Pythoncard-users] an IDLE clone (PythonCard IDE, wxIDLE...)

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

-----Original Message-----
From: Stephen M. Gava [mailto:elg...@us...]
Sent: Sunday, January 20, 2002 5:13 PM
To: Kevin Altis
Subject: Re: FW: [Pythoncard-users] an IDLE clone (PythonCard IDE,
wxIDLE...)


Kevin Altis wrote:
> Stephen,
> I'm not currently on the idle-dev list. I wanted to forward this email to
> you since you appear to be the most active person when I browsed the
> archives. If an IDLE clone is started, anyone involved would of course get
> on the idle-dev mailing list, though the clone would be written in
wxPython
> or wxPython/PythonCard not tkinter. If you have any thoughts I would
> appreciate the feedback.

Hi Kevin,
another python ide project huh? Man, last time I searched at sourceforge
and freshmeat I found dozens and dozens of them already in progress or
just starting up, the more the merrier I guess!

As for idle itself, as you are probably aware it is undergoing a lot of
development at the moment via the idlefork project
( http://idlefork.sourceforge.net/ )
; a new configuration system with a gui based user configuration
interface is nearing completion, after which execution of code from
within idle in a separate process will be re-implemented in a more
general way, which hopefully gets all the debugging features working
again. When these new features have been fully tested Guido's plan is
that they (along with many other bug-fixes and new features already
implemented) will be rolled into python idle as the next "all singing
and dancing" version of idle (which will hopefully be ready for release
with python 2.3).

If you are interested in the future of idle have a look at the "Mission
Statement" on the idlefork website
( http://idlefork.sourceforge.net/mission.html )
where you'll find a precis of a lot of discussion about idle which took
place on idle-dev in June/July last year, and which resulted in a lot of
decisions about idle's future, including the decision that idle will
continue with a tkinter gui. Tkinter's wide platform support is the main
factor mentionned there, but it's low reliance on external libraries is
also a major factor here.

My thoughts on the production of a wxPython/PythonCard based idle
'clone', are that if you have a group of folks inspired to do it, by all
means go ahead and do it! Developer and user choice are both good
things. If you do start a project along these lines though, by all means
call it "IDLE inspired" or "IDLE like" if that is your aim, but my
personal feeling would be please don't call it wxIDLE or "new IDLE" or
anything like that, there would just be too many IDLE's. We already have
IDLE, and it's official developmental branch IDLEfork, that's enough
IDLE's! 8^)

>
> Is there an updated version of the documentation available? The version at
>   http://www.python.org/idle/doc/
> say 0.5 and the version of IDLE I have (Python 2.1.1) is version 0.8

Production of a new set of documentation for idle is one of the things
on the list for the idlefork project. Any volunteers? *I hear echoes*

Anyway, if you have any other questions for me, please ask, and, by the
way, if you know anyone who would be interested in working on idlefork
itself (coding, testing, or documentation) please let me know!! ;-)

Best wishes,
Stephen.
--
Stephen M. Gava  <elg...@us...>
IDLEfork ( http://idlefork.sourceforge.net )  " just like IDLE, only crunchy
"

Re: [Pythoncard-users] minimal resource file translation

[Neil H. <ne...@sc...>]

    In most cases, it is better to translate the strings used rather than
the resources. The resources describe aspects of the application that
translators don't need to modify such as widget layout. Sometimes a
translation needs more or less space than the original but while this may
require changing the layout when using fixed coordinates, dynamic layouts
that use sizers or similar may continue to work. Even on Windows where
dialogs are generally fixed layouts, other widgets such as menus and message
boxes are self-sizing.

   SciTE was internationalised in version 1.41, 2.5 months ago. It uses a
simple text file to specify translations in the form original=translation
(http://www.scintilla.org/SciTETranslation.html). It has been localised into
7 languages with over 300 downloads of translations so far. Translators have
found the file format easy to work with. It doesn't currently behave very
cleverly with respect to character sets, assuming the user has chosen a
system locale that allows showing the characters used. A future version may
require or allow translations to be in UTF-8. Having a simple string
translation table is a popular scheme used by other software, although some
libraries require the translations to be compiled into a more efficient
format.

   When a new version of the application is released with additional UI
elements, you don't want there to be a delay before users of localised
versions can use it. By using resource based translation, the new features
are not present until the translation is complete. By using string based
translation, the new features are available immediately albeit with English
strings. This encourages incremental translation with users able to fix up
minor additions and contribute the fix back to the original author or
translator.

   To make string based translation robust against small edits such as
changing access keys or the presence/absence of "..." or ":" at the end of
labels, these can be removed from the original versions of the strings with
the endings replaced automatically after the translations if present. So for
the "&Open..." item (where "&" marks the next character as the access key),
the French translation is
Open=&Ouvrir
   For more robustness, other transformations such as case folding and space
stripping could be performed.

   Neil

[Pythoncard-users] FW: Python is just as good as C++ for real apps

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

I recently exchanged the following emails with someone that posted on
wx-users asking about porting from Visual Basic (VB) to wxWindows. Like many
people, especially people using C++, he is under the mistaken impression
that Python is not good for building real apps. For the most part, I think
that is simply wrong. My arguments in favor of Python are below. The
messages are in order of most recent at the top to oldest at the bottom. I
removed the original posters name, email and signature.

I'm sure if I misspoke below, Neil or other C++ coders that use Python will
correct me. They might even have points to add that I overlooked. I didn't
even get into all the downsides of programming in C++.

ka
---

From: Kevin Altis
Subject: RE: VB -> wxWin

It depends on what you mean by big apps. If you are worried about speed of
the menus, windows, widgets, event handling, etc. that is a non-issue. If
you are worried about having access to lower-level OS routines, that again
is generally a non-issue. Either there is a Python library that already
provides access or it is a relatively painless affair to wrap the needed
C/C++ so that it can be used directly by Python. Python has much better
built-in cross-platform support than C++, even with the wxWindows library.
You can even call Python from within C/C++ or inline C/C++ code in Python.
Python has threads. Python has profiling tools to isolate which section of
your code might need to be optimized or rewritten in C/C++.

There are drawing samples for wxPython and I have put some drawing samples
into PythonCard as well. These are actually a bit slower than they need to
be because I did a double-buffered bitmap widget that should have some of
the operations moved into C, but it is surprisingly fast as is. The speed is
mostly a matter of the video card used. My hopalong sample is comparable in
speed to the version I did in Java.

The only way to know for sure if your particular application would have
execution speed issues is of course to try it. However, the assumption that
Python is somehow inferior to C++ for real apps is just plain wrong. Your
initial message prompted my reply because your original code was in VB and
you definitely aren't going to lose anything going from VB to Python except
the simplicity of using COM components; you can use COM from Python, it just
isn't as simple as from within VB. You should seriously consider Python and
wxPython as a solution.

ka
---

Subject: Re: VB -> wxWin

Thank you, but I'd rather stay with C++. Although Python is a very
interesting programming language, it is more for scripting than creating big
app's.

---
From: Kevin Altis
Subject: RE: VB -> wxWin

If you would like to program in Python (and everyone should :) you can check
out PythonCard
  http://pythoncard.sourceforge.net/
This isn't just a random plug. Many of the good things in VB are influencing
the design of the framework, some naming conventions for event handler
readability, how the layout editor works, etc. If you need them, you can
build standalone EXEs using py2exe or Gordon McMillan's installer. There are
screenshots of some of the samples (there are over 20 samples) that come
with each release:
  http://pythoncard.sourceforge.net/samples.html

PythonCard sits on top of wxPython so you can use the wxPython/wxWindows API
code in a PythonCard app in addition to our wrappers which are designed to
simplify the "raw" wxWindows API.

It won't help you with automatic code translation from VB to Python or
translating your VB forms into PythonCard resources (layouts). The
resourceEditor sample, while primitive, will help you quickly recreate your
layouts.

I would very much like to get feedback from a VB user such as yourself on
features you really need or would like to see added.

The only problem I see based on your requirements is that there isn't a firm
date on the wxPython Mac port other than Real Soon Now. PythonCard/wxPython
runs fine on Linux/GTK. It is possible to run GTK under OS X.

ka
---

Subject: VB -> wxWin

Does anybody have experiences translating a Visual Basic program into a
wxWindows application? Maybe a tool which does that?

I have got about 10 programs written in VB3 or VB6 which I have to make
running under Mac and Linux, all of them
    - not using any databases
    - not using any complicated ocx or dll (just vb runtime)
    - relatively clean, uncommented vb code
    - few Windows API calls (like BitBlt)

I thought about writing a program/script which translates the "Visual" into
"wxWindows" and the "Basic" code into "C++". I think this should be possible
up to some small code parts which I would translate manually.
Is there already such a tool? Does anybody have experiences in doing such
things, maybe converting from other languages?

[Pythoncard-users] minimal resource file translation

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

Just as a test, someone could provide me with the translated text for
minimal.rsrc.py (the full resource file is shown below).

The only items below which need to be changed are:

  'title':'Minimal PythonCard Application',

  'label':'File',

  'label':'E&xit\tAlt+X' } ] }

  'text':'Hello PythonCard' },

Do not change the attribute names: 'title', 'label', 'text'

Obviously, it won't be possible to translate some of the words above using
7-bit ASCII, but maybe it doesn't matter because on the platform where the
appropriate encoding is set the 8-bit ASCII or Unicode would appear
correctly because the right character encoding is already being used? That's
one of my open questions on how all this should work. If you're programming
in Python in French or Russian or German or Japanese or whatever, what do
the strings look like in your source? I'm obviously pretty ignorant in these
matters.

The minimal.py source doesn't need to change at all since it doesn't deal
with any other strings, date, currency, etc.

Anyway, if someone wants to send me some translations for the text above for
each language/country you know that would be a start. Alternatively, make
copies of the minimal.rsrc.py file and add .fr, .fr_CH, .fr_BE... to the
filenames, though in the case of this sample, probably only .fr would be
needed for a French translation; and PythonCard would still be PythonCard,
at least in Western European languages. Zip the modified resource files and
send the zip to me. Also, please run:

>>> import locale
>>> locale.setlocale(locale.LC_ALL, '')
'English_United States.1252'
>>> locale.getdefaultlocale()
('en_US', 'cp1252')

on your system and let me know the results including what OS (Linux, Windows
95/98/ME/NT 4/2000/XP) you're using. I'll mod the framework to load the
appropriate resource file based on what getdefaultlocale() returns, so we'll
have a straw man implementation.

ka
---
minimal.rsrc.py:

{ 'stack':{ 'type':'Stack',
            'name':'Minimal',

    'backgrounds':
 [
  { 'type':'Background',
    'name':'bgMin',
    'title':'Minimal PythonCard Application',
    'size':( 200, 100 ),

    'menubar':
    {
        'type':'MenuBar',
        'menus':
        [
            { 'type':'Menu',
              'name':'menuFile',
              'label':'File',
              'items': [
                { 'type':'MenuItem',
                  'name':'menuFileExit',
                  'label':'E&xit\tAlt+X' } ] }
        ]
    },

   'components':
   [
    { 'type':'TextField',
      'name':'field1',
      'position':(0, 0),
      'text':'Hello PythonCard' },
   ]
  }
 ]
 }
 }

RE: [Pythoncard-users] internationalization

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

Excellent info Francois! I snipped the text and made a few comments.

> From: Francois Granger
> >
> >The relevant module in Python is locale:
> >   http://www.python.org/doc/current/lib/module-locale.html
>
> Be carefull, as far as I know, localisation in Python is available
> for Unix/Linux plateform, but does not work well for other.
> One of the main mechanism is the gettext module based on some default
> Linux behavior with a really diiificult portability...

I'm not sure we have to use it, but gettext is documented at:
  http://www.python.org/doc/current/lib/module-gettext.html

On my Windows 2000 system, I can do:

>>> import locale
>>> locale.setlocale(locale.LC_ALL, '')
'English_United States.1252'
>>> locale.getdefaultlocale()
('en_US', 'cp1252')

If you look at locale.py in the Python Lib folder, you'll see the
encoding_alias, locale_alias, windows_locale dictionaries which provide the
list of abbreviations we are interested in.

> Main Internationalisation norms are:
>
> ISO 639 for name of languages
> ISO 3166 for name of country
> RFC 1521, 1766, 3066 for MIME supporrt wich deal with caracter
> encoding and language support.
>
>
> >It would be relatively simple for the
> >framework to check the users locale when it starts up and use the
> >appropriate resource file.
>
> I don't know of any portable code to do this yet.

I was just thinking about resource constants initially. The resource file
needs to have an identifier, so that when the program starts and checks the
locale, (for example  'English_United States.1252', 'en_US' in my case) it
then loads the appropriate resource file. The framework could be said to
assume English ('en') and United States (US) by default.

> I can be of some help on this matter. But I have a limited amount of
> PythonCard and programming expertise, and time is a really limited
> resource (as for many others).

Input on the list like this and testing is always helpful even if people
don't have time to write code. Thanks again for your feedback.

> I did a first shot at an international module. I know that it is
> broken right now. I am already trying to fix it to enhance the
> language suppport issue. But if you want to give it a try....
>
> http://francois.granger.free.fr/MacPython and then download numToWord
> according to your plateform.

I'll take a look.

ka

Re: [Pythoncard-users] internationalization

[Francois G. <fgr...@al...>]

>From: "Kevin Altis" <al...@se...>
>
>Part of the point of resource files is that someone other than the coder
>should be able to translate the various menus, fields, buttons, labels,
>strings used in dialogs, etc. to another language increasing the target
>audience for a program. As part of the PythonCard framework and
>documentation we can provide guidelines for writing programs that are easier
>to internationalize by providing conventions to follow.
>
>I would like to have at least one sample that deals with
>internationalization issues. I don't expect to completely solve this issue
>in one pass, especially since we don't have complete Unicode support for use
>everywhere.
>
>The relevant module in Python is locale:
>   http://www.python.org/doc/current/lib/module-locale.html

Be carefull, as far as I know, localisation in Python is available 
for Unix/Linux plateform, but does not work well for other.
One of the main mechanism is the gettext module based on some default 
Linux behavior with a really diiificult portability...

Main Internationalisation norms are:

ISO 639 for name of languages
ISO 3166 for name of country
RFC 1521, 1766, 3066 for MIME supporrt wich deal with caracter 
encoding and language support.


>It would be relatively simple for the
>framework to check the users locale when it starts up and use the
>appropriate resource file.

I don't know of any portable code to do this yet.

>  The user code would of course have to use the
>right string, date, and number formatting to work transparently. The user
>code would not have to maintain a separate set of handlers or names
>referencing resource objects since the names such as 'menuFileExit' are ids
>never seen by the user, only by the user code.
>
>For example, if we used country codes, we might have:
>
>minimal.rsrc.py
>minimal.fr.rsrc.py

Sorry, 'fr' (lower case) is a language code. It have to be completed 
by the country code in some circumstances...

>language is not the same as their country, so using a language identifier
>might be a better choice. In fact, we probably need to deal with language
>and country independently.

It will be neede for full internationalisation. And it will be a nice 
start to get these features as early as before 1.0 instead of waiting 
for a 1.1 International version as is usual in the commercial 
software market...

>If someone could volunteer to help chase down relevant internationalization
>issues, help with doing an international PythonCard sample, that would be a
>great help. This is not an area of expertise for me, but I know it is
>something we have address at some point and I would like to get it on the
>radar now rather than later.

I can be of some help on this matter. But I have a limited amount of 
PythonCard and programming expertise, and time is a really limited 
resource (as for many others).

I did a first shot at an international module. I know that it is 
broken right now. I am already trying to fix it to enhance the 
language suppport issue. But if you want to give it a try....

http://francois.granger.free.fr/MacPython and then download numToWord 
according to your plateform.

RE: [Pythoncard-users] an IDLE clone (PythonCard IDE, wxIDLE...)

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

Editing Python Source Code
http://www.python.org/editors/

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Saturday, January 19, 2002 8:09 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] an IDLE clone (PythonCard IDE, wxIDLE...)
>
>
> After listening to Guido's talk about Python and CP4E I got
> inspired to but
> together some background material links and topics relevant to an IDE for
> PythonCard. Please respond to this thread with other links or relevant
> issues. I don't know when we might pursue this, but it could certainly be
> done in parallel with some of the other work Rowland and I have
> been doing.
> If nothing else, this will make a good placeholder message to go back to
> when the motivation fairy visits one of us.
>
> There were a few threads back in August on wxPython-users about doing a
> wxPython IDLE (wxIDLE) program.
> http://aspn.activestate.com/ASPN/Mail/Message/722717
> Nothing seems to have come from that discussion; I think it ended up with
> people wishing Riaan would do a Boa-lite, but he is swamped and isn't even
> working on Boa as far as I can tell. Boa already has a lot of what people
> want, but a lot of extra stuff too. Anyway, there is probably
> enough wxIDLE
> interest that people not even interested in PythonCard would probably help
> with the effort.
>
> One Day of IDLE Toying
> http://hkn.eecs.berkeley.edu/~dyoo/python/idle_intro/index.html
>
> IDLE home page
> http://www.python.org/idle/
>
> The IDLEfork  Project
> http://idlefork.sourceforge.net/
> This is the place for IDLE developers.
>
> IDLE Documentation
> http://www.python.org/idle/doc/
> This is the most useful document I've seen for use as a spec.
> There is a lot
> to be said for just duplicating the features and key bindings of the
> tkinter-based IDLE, but using wxPython/PythonCard with wxSTC. The
> key would
> be to not deviate from the IDLE spec on the first pass, so that it is a
> straight coding effort without lots of design/redesign going on.
>
> We already have the Shell component, we just continue to use PyCrust.
>
>
> In the "six blind men describe the beast" thread, Neil Hodgson said:
>    "Writing a small editor isn't all that hard. I don't expect the initial
> version of an editor for PythonCard that handled the vast
> majority of needed
> features would take long at all. You can get tied up in details
> though. The
> biggest question to me would be how do you determine which files
> are part of
> a PythonCard project and where within those files are the event
> handlers? Do
> you do VB style file segmentation or just present the whole file to the
> user?"
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] an IDLE clone (PythonCard IDE, wxIDLE...)

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

After listening to Guido's talk about Python and CP4E I got inspired to but
together some background material links and topics relevant to an IDE for
PythonCard. Please respond to this thread with other links or relevant
issues. I don't know when we might pursue this, but it could certainly be
done in parallel with some of the other work Rowland and I have been doing.
If nothing else, this will make a good placeholder message to go back to
when the motivation fairy visits one of us.

There were a few threads back in August on wxPython-users about doing a
wxPython IDLE (wxIDLE) program.
http://aspn.activestate.com/ASPN/Mail/Message/722717
Nothing seems to have come from that discussion; I think it ended up with
people wishing Riaan would do a Boa-lite, but he is swamped and isn't even
working on Boa as far as I can tell. Boa already has a lot of what people
want, but a lot of extra stuff too. Anyway, there is probably enough wxIDLE
interest that people not even interested in PythonCard would probably help
with the effort.

One Day of IDLE Toying
http://hkn.eecs.berkeley.edu/~dyoo/python/idle_intro/index.html

IDLE home page
http://www.python.org/idle/

The IDLEfork  Project
http://idlefork.sourceforge.net/
This is the place for IDLE developers.

IDLE Documentation
http://www.python.org/idle/doc/
This is the most useful document I've seen for use as a spec. There is a lot
to be said for just duplicating the features and key bindings of the
tkinter-based IDLE, but using wxPython/PythonCard with wxSTC. The key would
be to not deviate from the IDLE spec on the first pass, so that it is a
straight coding effort without lots of design/redesign going on.

We already have the Shell component, we just continue to use PyCrust.


In the "six blind men describe the beast" thread, Neil Hodgson said:
   "Writing a small editor isn't all that hard. I don't expect the initial
version of an editor for PythonCard that handled the vast majority of needed
features would take long at all. You can get tied up in details though. The
biggest question to me would be how do you determine which files are part of
a PythonCard project and where within those files are the event handlers? Do
you do VB style file segmentation or just present the whole file to the
user?"

ka

[Pythoncard-users] Bruce and Guido videos about Python, CP4E

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

Neither of these videos are new, but I think that Bruce and Guido cover some
areas that are relevant to PythonCard and might provide some inspiration.
Sit back with your favorite drink, relax, and listen.

Python 9: Interview with Bruce Eckel (approx. 25 minutes)
http://technetcast.ddj.com/tnc_play_stream.html?stream_id=466

Guido van Rossum: Computer Programming for Everyone! (approx. 50 minutes)
http://technetcast.ddj.com/tnc_play_stream.html?stream_id=240

Both of these video/audio streams are at:
http://technetcast.ddj.com/tnc_catalog.html?item_id=91

ka

[Pythoncard-users] FW: tkinter pluses and minuses

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

Joe Knapka sent me some good comments on tkinter that we should keep in mind
as we beef up the features of the framework. At some point, we need to have
a good story to tell to people that might want to convert over from using
tkinter to PythonCard.

ka

-----Original Message-----
From: Joseph A Knapka
Sent: Saturday, January 19, 2002 10:33 AM
Subject: Re: FW: tkinter pluses and minuses


Kevin Altis wrote:
>
> Magnus, suggested that you would be better qualified to answer what is
good
> about tkinter, what you like, etc.
>
> You can sing the praises of tkinter, beat up on wxPython, PythonCard, etc.
I
> just need to get some expert opinion.

Well, I have no experience with wx or PythonCard. The main
reason I like Python/Tkinter is that it makes using Tk
easier than Tcl does, but that's not exactly high praise :-)

I do like the Tkinter canvas widget, which completely supports
structured graphics - that is, you can say, essentially,
"Put a filled circle at location 100,100 with radius 50
and fillcolor red, and call it CIRCLE_1", and you never have
to worry about repainting it or any of that - the canvas
takes care of everything. Later, you can say "Delete
CIRCLE_1", and that circle (only) will vanish, and any
effects it had on overlapping graphic items is undone.
(I intend to implement the Anygui canvas in essentially
this way.)

Another thing I really, really like about Tk is
its layout managers, grid(), place(), and pack().
My impression is that wx's layout facilities are
much more primitive than Tk's, which is why I
haven't even bothered to try wx -- I hate layout
management, I want to spend as little time worrying
about it as possible, and Tk makes it easy. I
suppose I ought to try writing some wx code,
though, just to see what I'm missing.

Aside from that, Tkinter supports the usual suspects,
widget-wise: Text areas (multiline) and entry fields
(single line), buttons (radio-, check-, push-), labels,
listboxes, menus, scrollbars... With varying levels of
convenience. It's possible to bind UI events directly to
Python code in a simple way:

widget.bind("<Event description>",callable)

where "<event description>" can be any event - you
can bind to keyboard events in list boxes, or
mouse events in labels, or whatever.

It's portable - *nix, Win32, Mac. And Tkinter is about
83000 times easier than writing UI code in C or C++ directly
to the Windows or X api, or any low-level UI library that I
know of... so I rarely use anything else. I've been working
with Tk for quite a while, under Tcl and Python, so I don't
much notice the icky parts any more.

Things that suck about Tkinter:

(1) Every single UI operation goes through a parse-and-
interpret by the Tcl interpreter embedded in Tkinter.
So, it's slow. (Note that this is an artifact of the
Tkinter implementation - there's a binary API to Tk,
but Tkinter doesn't use it.)

(2) While the canvas is very convenient, it too is
slow, due to its basic nature, not because of the Tcl
interpreter. You might want a simplified canvas that just
issues a REPAINT event and dirty-rect data when it needs
to be redrawn. But no such is available in Tk.

(3) Sometimes setting up the proper interaction between
widgets, like scrollbars and list- or textboxes, can
be confusing. But on the other hand, if you've done it
once you can always look at the code you wrote before -
it's always the same. And it's only one line of code -
just has to be the RIGHT line! But I have to look that
stuff up every time I do it.

(4) A working knowledge of Tcl/Tk is extremely valuable,
if not indispensible, when writing Python/Tkinter code.
So if you don't already know Tcl, that sucks for you.

Hope that helps,

-- Joe

[Pythoncard-users] internationalization

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

Part of the point of resource files is that someone other than the coder
should be able to translate the various menus, fields, buttons, labels,
strings used in dialogs, etc. to another language increasing the target
audience for a program. As part of the PythonCard framework and
documentation we can provide guidelines for writing programs that are easier
to internationalize by providing conventions to follow.

I would like to have at least one sample that deals with
internationalization issues. I don't expect to completely solve this issue
in one pass, especially since we don't have complete Unicode support for use
everywhere.

The relevant module in Python is locale:
  http://www.python.org/doc/current/lib/module-locale.html

I do not know whether wxPython has additional internationalization features
we should be aware of.

I plan to add support for strings and other country/language dependent
elements in the resource file. It would be relatively simple for the
framework to check the users locale when it starts up and use the
appropriate resource file. The user code would of course have to use the
right string, date, and number formatting to work transparently. The user
code would not have to maintain a separate set of handlers or names
referencing resource objects since the names such as 'menuFileExit' are ids
never seen by the user, only by the user code.

For example, if we used country codes, we might have:

minimal.rsrc.py
minimal.fr.rsrc.py

Showing that a "French" version of the resource is available and should be
used if the users locale default was French. Of course, the users preferred
language is not the same as their country, so using a language identifier
might be a better choice. In fact, we probably need to deal with language
and country independently.

If someone could volunteer to help chase down relevant internationalization
issues, help with doing an international PythonCard sample, that would be a
great help. This is not an area of expertise for me, but I know it is
something we have address at some point and I would like to get it on the
radar now rather than later.

Other suggestions, places to look for help, etc.?

ka

[Pythoncard-users] Fw: Technical Journal of the Python Language

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

This is probably a good opportunity for anyone that wants an excuse to write
something about PythonCard.

ka

"Bryan Richard" <co...@py...> wrote ...
> Py (pyzine.com) is a print zine published four times a year covering
> all aspects of the Python language.  The goal of Py is to promote the
> use of Python and provide a means for writers and developers to
> expound on the benefits of the language.
>
> Py is looking for article submissions for inclusion in its first
> issue.  We will consider any topic but are specifically looking for
> works on the following:
> - UI
> - Shell
> - Web
> - Zope
> - Beginner
> - Games
> - Services
>
> You will find the submission guidelines at pyzine.com.
>
> Py will be a low-cost, high quality zine, written by the developers
> who are using Python today.  The audience will range from the advanced
> Python hacker to the newbie who will be using Python tomorrow.
> Contribute.
>
> Be well,
>
> Bryan Richard
>
> co...@py...
> http://www.pyzine.com
>

[Pythoncard-users] printing support on the way

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

I just did the following test from the Shell using the simpleBrowser sample
and it worked correctly under Windows and Cliff confirmed that it works
under Linux, so I think we have a simple cross-platform solution for
printing in the form of a wrapped wxHtmlEasyPrinting class.

simpleBrowser.py -s  # this opens to the diveintopython site

Then I opened the docs/html/index.html file of PythonCardPrototype, though
you should be able to use any URL or text. Then in the shell I did:

>>> from wxPython import wx
>>> source = comp.htmlDisplay._delegate.GetParser().GetSource()
>>> base = comp.htmlDisplay._delegate.GetParser().GetFS().GetPath()
>>> base
'C:/python/PythonCardPrototype/docs/html/'
>>> from wxPython import html
>>> p = html.wxHtmlEasyPrinting()
>>> p.PrintText(source, base)

This brought up a print dialog and I clicked okay. With a few utility
wrappers, this should let us easily print anything that wxWindows can
display: plain text files, formatted files using the limited set of HTML
available to us, images, etc. without worrying about platform differences.
We can support the more elaborate wxPython printing methods as well for
better font support, but this will get us started.

Note that the Python Powered GIF
(http://webware.sourceforge.net/PythonPowered.gif) doesn't show up if you
open index.html because of the Host: header not being sent in the current
wxHTTP class, that is supposedly fixed in wxWindows cvs and will work in
wxPython 2.3.3.

If you want to experiment on your own, look at the wxHTML notes in the
wxWindows documentation for more information about specific classes and
methods.

ka

[Pythoncard-users] project name vote in progress

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

I'm going to let the vote run for a few days to make sure that nobody misses
a chance to cast a vote. I'll accept submissions through Monday night USA
west coast time and then tally the votes up Tuesday morning when I get up.
You don't have to be on the list to vote, so those of you that aren't
subscribers and are just reading the list archives can send in your votes
too. One vote per person please and no trickery with using multiple email
accounts or I may disqualify some entries. There are less than 60 people on
the mailing list and I doubt everyone will vote, so tallying shouldn't be a
problem.

Please email me directly, don't post to the list. Just put the name you
would like to see used for the project in the subject line of your message
like this:

vote - PythonCard
or
vote - Monty
or
vote - Snake Oil
etc.

There have been a lot of name suggestions made by David LeBlanc, Dan Shafer,
and others and I don't want to try and list them all here, so browse the
archives if you need a refresher. I'm guessing that if you can't remember a
particular name, it probably didn't have much impact on you. You can
"write-in" whatever name you want to see used, even if nobody has suggested
it before. I would like to put this issue to rest, so be serious about the
names. We could be using it for the next five to ten years.

ka
---
Kevin Altis
al...@se...

Re: [Pythoncard-users] Linux and PythonCard, there will be a 0.6.3 release soon

[Neil H. <ne...@sc...>]

Magnus Lie Hetland:

> Yeah, yeah... This was from an early version (not that it's any better
> now ;) and the main reason for size problems is, of course, fixed
> coordinates etc. Oh, well. Maybe we'll fix that sometime later (with a
> preferred-size approach =E0 la AWT.)
>
> Thanks for your input, though :)

   It's nice to be able to dish some out after all the complaints I get f=
or
my software ;-)

   I do appreciate what you are doing with anygui and expect you will
achieve usable but sub-optimal UIs. This is just a really hard problem.

   Neil

Re: [Pythoncard-users] Linux and PythonCard, there will be a 0.6.3 release soon

[Magnus L. H. <ma...@he...>]

Neil Hodgson <ne...@sc...>:
>
> Magnus Lie Hetland:
>=20
> > Hm. The only problem I see there is the old version of Swing acting
> > up... (And one checkbox in Mac OS classic...)
>=20
>    The old Swing is the worst, particularly cutting off the Cancel butt=
on
> text.

Right... But it isn't really supported, so that doesn't count ;)

I guess we ought to get a newer Non-Windows Swing screenshot there...
=20
[snipped lots of stuff]

Yeah, yeah... This was from an early version (not that it's any better
now ;) and the main reason for size problems is, of course, fixed
coordinates etc. Oh, well. Maybe we'll fix that sometime later (with a
preferred-size approach =E0 la AWT.)

Thanks for your input, though :)

>=20
>    Neil
>=20


--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

Re: [Pythoncard-users] Linux and PythonCard, there will be a 0.6.3 release soon

[Neil H. <ne...@sc...>]

Magnus Lie Hetland:

> Hm. The only problem I see there is the old version of Swing acting
> up... (And one checkbox in Mac OS classic...)

   The old Swing is the worst, particularly cutting off the Cancel button
text.

   The multi-line text boxes differ markedly in whether they wrap or have
scroll bars and whether the scrollbars are visible or disabled. Tkinter's
scroll bar thumbs can fill the scrollbars yet not change to empty/disabled
mode. It looks like there is one new line after the text but GTK(2) makes
the text scrollable vertically for no obvious reason. GTK crops the first
radio button's text "g" vertically. Probably the "p" and "y" too but that is
harder to detect. The choice of font for the text edit is weird on MacOS
Tkinter and Jython/W2K - choosing Courier or similar is against platform
standards. Different list behaviour with GTK(2) because it doesn't associate
the current item with selection (see the dotted rectangle on a different
item to the blue). Non-standard button size and default button highlighting
on Windows. Not putting a border around the text box on MacOS. On MacOS, the
Cancel button is too small to show the normal amount of space around the
text and the OK button overlaps the window sizer. On the wxPython and
Jython/W2K versions there are focus indicators in both the text edit (a
caret) and the list (dark blue selection, assuming standard colours with
blue for focussed selection and grey for unfocussed).

   Neil

Re: [Pythoncard-users] Linux and PythonCard, there will be a 0.6.3 release soon

[Magnus L. H. <ma...@he...>]

Neil Hodgson <ne...@sc...>:
>
> Kevin Altis:
> 
> 
> > My tests tonight revealed many small problems I was unaware of since
> nobody
> > had reported them.
> 
>    Many of us cross-platformers are so used to this state of affairs that it
> is barely noticeable. Stupid font choice on one platform? Disappears into
> the background as we are just so happy to be able to read the text. Cut off
> text? Mmm, there is a 'C' and the left half of an 'o', must be 'Colour'.
> Background bleeds over some text? Fine.
> 
>    The anygui demo page shows a lot of the classics:
> http://anygui.sourceforge.net/screenshots.php
 
Hm. The only problem I see there is the old version of Swing acting
up... (And one checkbox in Mac OS classic...)

But, of course, I'm quite biased in the matter <wink>

>    Neil

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

Re: [Pythoncard-users] Linux and PythonCard, there will be a 0.6.3 release soon

[Neil H. <ne...@sc...>]

Kevin Altis:


> My tests tonight revealed many small problems I was unaware of since
nobody
> had reported them.

   Many of us cross-platformers are so used to this state of affairs that it
is barely noticeable. Stupid font choice on one platform? Disappears into
the background as we are just so happy to be able to read the text. Cut off
text? Mmm, there is a 'C' and the left half of an 'o', must be 'Colour'.
Background bleeds over some text? Fine.

   The anygui demo page shows a lot of the classics:
http://anygui.sourceforge.net/screenshots.php

   Neil

RE: [Pythoncard-users] possible project names

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

> > At the end of it all, I find I still prefer PythonCard.
>
> Yes, yes, yes!
>
> I guess I must have missed the beginning of this discussion, but can
> someone please sum up (preferrably in a sentence or two) why we
> wouldn't want to use that name? IMO it has a lot going for it...

Danny Goodman put it this way:
"This thread gets me off my duff because I think the card-ness of
PythonCard's name and any metaphor used to describe its components shackles
it with too much baggage (both good and bad). Those who know HyperCard well
will have certain expectations that PythonCard is not intended to meet;
those who may have only heard of HyperCard will feel like they have to know
something else before getting to know PythonCard.

Hemispherical-floating-arm computers notwithstanding, anything that conjures
up "Apple" in non-Apple users'/programmers' minds is not a plus for the
promotion of a new OS-platform-independent technology, IMHO. If it's a good
authoring environment, it will attract old 'Card farts, like me (...and hi,
Dan!) even if you name it something that would get bleeped on "South Park."

And Kevin will be able to spend more time explaining what it is, rather than
defending what it isn't."

ka