pythoncard-users — PythonCard Users and Developers

RE: [Pythoncard-users] put on your marketing caps

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

This pass at the release announcement combines Dan's intro and Andy's text
with a slight mod to Andy's suggestions.

The text below does not highlight any samples. It probably should or the
screenshot pages should be upated to emphasize the good stuff. In
particular, people will probably be interested in the resourceEditor for
their own apps, so maybe we need a fullscreen shot of that with the Property
Editor, menu showing, etc. Suggestions, text, HTML and screenshot work, etc.
always appreciated.

I have to admit that in the context of a comp.lang.python announcement and
some other Python mailing lists, Dan's intro seems a bit over the top, but I
guess life doesn't reward the modest. :)

Dan Shafer is working on a sample and tutorial that I will include in
release 0.6.2, which I expect to put out in the next couple of days. I would
appreciate hearing about problems with 0.6.1 not already addressed in the
version in cvs before then. The changelog is at (sorry about the long URL):
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/docs/changelog.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup

ka
---

PythonCard brings visual software development on Open Source tools
to the masses, picking up where Apple's immensely popular but
now-abandoned HyperCard product left off. Written entirely in the
widely used and respected object-oriented Python scripting language,
PythonCard enables end users to create applications and interfaces in
a style that is reminiscent of Microsoft Visual Basic without the
baggage of over-complexity for non-programmers. It then enables the
developer with some minimal amount of programming or scripting
experience to give the user's designs life and power through Python
scripting.

All the information you need about PythonCard can be found on the
project web page at: http://pythoncard.sourceforge.net/

You can download the latest release at:
http://sourceforge.net/project/showfiles.php?group_id=19015

For a list of the samples that have been built with PythonCard and some
screenshots of them in action go to:
http://pythoncard.sourceforge.net/samples.html
A description of each sample is included in the readme.txt file in each
sample directory.

The kind people at SourceForge host the project:
http://sourceforge.net/projects/pythoncard/

If you want to get involved the main contact point is the Mailing list:
http://lists.sourceforge.net/lists/listinfo/pythoncard-users

PythonCard requires Python 2.1.x or later and wxPython 2.3.2.1 or later
and runs on every platform those are available for.
wxPython can be downloaded at http://www.wxpython.org/

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Andy
> Todd
> Sent: Tuesday, January 15, 2002 2:09 AM
> To: pythoncard-Users
> Subject: Re: [Pythoncard-users] put on your marketing caps
>
>
> I rather like the introduction blurb that Dan posted last week, so
> rather than attempt to refine that, I'll have a pop at the bits at the
> end. The text I think we should use is enclosed in triple quotes.
>
> Kevin Altis wrote:
>
> > I would like to update the release announcement for PythonCard.
> The old text
> > I have been using is at the end of this message.
> >
> > This is a good time for the lurkers to come out of hiding and
> provide some
> > input. :)
> >
> > A better release announcement might attract more users and
> developers and
> > help speed the development of PythonCard. If you've been using
> PythonCard
> > and think other people should too, then tell us why. All suggestions are
> > welcome.
> >
> > ka
> > ---
> >
> > PythonCard is a software construction kit (in the spirit of Apple's
> > HyperCard) written in Python.
> >
>
>
> """
> All the information you need about PythonCard can be found on the
> project web page at http://pythoncard.sourceforge.net/
> """
>
> > You can download the latest release at:
> > http://sourceforge.net/project/showfiles.php?group_id=19015
> >
>
>
> I'd get rid of this bit;
>
> > Samples included in the latest release: addresses, conversions,
> dbBrowser,
> > dialogs, doodle, findfiles, hopalong, minimal, proof, resourceEditor,
> > samples, searchexplorer, sounds, SourceForgeTracker,
> textIndexer, tictactoe,
> > turtle, widgets, worldclock
> >
> > To see screenshots of some of the samples, visit:
>
>
> and start again with;
>
> """
> For a list of the samples that have been built with PythonCard and some
> screenshots of them in action go to;
> """
>
> > http://pythoncard.sourceforge.net/samples.html
> > A description of each sample is included in the docs directory and the
> > readme.txt file in each sample directory.
> >
>
>
> Lose this too;
>
> > PythonCard home page
> > http://pythoncard.sourceforge.net/
>
>
> And finally;
>
>
> """
> The project is administered thanks to the kind people at sourceforge, if
> you want to get involved the main contact points are the
>
>
> > SourceForge summary page
> > http://sourceforge.net/projects/pythoncard/
>
>
> and the
>
> >
> > Mailing list
> > http://lists.sourceforge.net/lists/listinfo/pythoncard-users
> >
>
>
> The technical blurb.
>
> >
> > PythonCard requires Python 2.1.x or later and wxPython 2.3.x.
> wxPython is
> > available at http://www.wxpython.org/
> >
>
> """
>
> Replace this
>
> > PythonCard relies on wxPython, it will support the Macintosh
> once wxPython
> > has been ported to the Mac.
> >
>
>
> with;
>
> """
> PythonCard relies on wxPython and is available on all of the platforms
> it runs on.
>
> """
>
>
> Just my thoughts.
>
> Regards,
> Andy
> --
> -----------------------------------------------------------------------
>  From the desk of Andrew J Todd esq.
> "Another year older, still no wiser." - Me, on my birthday

Re: [Pythoncard-users] put on your marketing caps

[Andy T. <an...@ha...>]

I rather like the introduction blurb that Dan posted last week, so 
rather than attempt to refine that, I'll have a pop at the bits at the 
end. The text I think we should use is enclosed in triple quotes.

Kevin Altis wrote:

> I would like to update the release announcement for PythonCard. The old text
> I have been using is at the end of this message.
> 
> This is a good time for the lurkers to come out of hiding and provide some
> input. :)
> 
> A better release announcement might attract more users and developers and
> help speed the development of PythonCard. If you've been using PythonCard
> and think other people should too, then tell us why. All suggestions are
> welcome.
> 
> ka
> ---
> 
> PythonCard is a software construction kit (in the spirit of Apple's
> HyperCard) written in Python.
> 


"""
All the information you need about PythonCard can be found on the 
project web page at http://pythoncard.sourceforge.net/
"""

> You can download the latest release at:
> http://sourceforge.net/project/showfiles.php?group_id=19015
> 


I'd get rid of this bit;

> Samples included in the latest release: addresses, conversions, dbBrowser,
> dialogs, doodle, findfiles, hopalong, minimal, proof, resourceEditor,
> samples, searchexplorer, sounds, SourceForgeTracker, textIndexer, tictactoe,
> turtle, widgets, worldclock
> 
> To see screenshots of some of the samples, visit:


and start again with;

"""
For a list of the samples that have been built with PythonCard and some 
screenshots of them in action go to;
"""

> http://pythoncard.sourceforge.net/samples.html
> A description of each sample is included in the docs directory and the
> readme.txt file in each sample directory.
> 


Lose this too;

> PythonCard home page
> http://pythoncard.sourceforge.net/


And finally;


"""
The project is administered thanks to the kind people at sourceforge, if 
you want to get involved the main contact points are the

 
> SourceForge summary page
> http://sourceforge.net/projects/pythoncard/


and the

> 
> Mailing list
> http://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 


The technical blurb.

> 
> PythonCard requires Python 2.1.x or later and wxPython 2.3.x. wxPython is
> available at http://www.wxpython.org/
> 

"""

Replace this

> PythonCard relies on wxPython, it will support the Macintosh once wxPython
> has been ported to the Mac.
> 


with;

"""
PythonCard relies on wxPython and is available on all of the platforms 
it runs on.

"""


Just my thoughts.

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday

RE: [Pythoncard-users] Re: tix vs. Pycard? for lightweight GUIs (fwd)

[Roman S. <rn...@on...>]

On Tue, 15 Jan 2002, David LeBlanc wrote:

> Um... Tix is a library that runs on top of Tk, not instead of it. It's been
> around for quite some time and probably predates Python's use of Tk
> altogether. It spent a number of years in semi-limbo with no real ownership,
> but Loi Lam, Tix' creator, has returned to it's care and feeding.

> BTW, other options for UI development with Python include Fox and FLTK, not
> to mention WxPython, but those either have a python wrapper on their
> relatively heavy-weight API's (Fox, FLTK) or are a wrapper (WxPython) on a
> substantial package (WxWindows). AFAIK, PythonCard is the only UI wrapper
> framework that aims at simplifying the task of coding a UI.

Well, my idea was that PythonCard matured enough to be considered
serious!

> Dave LeBlanc

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rn...@on... -

RE: [Pythoncard-users] Re: tix vs. Pycard? for lightweight GUIs (fwd)

[David L. <wh...@oz...>]

Um... Tix is a library that runs on top of Tk, not instead of it. It's been
around for quite some time and probably predates Python's use of Tk
altogether. It spent a number of years in semi-limbo with no real ownership,
but Loi Lam, Tix' creator, has returned to it's care and feeding.

It's by no means a simplifier of Tk - more megawidgets and iirc, a
megawidget framework (aids in creating new aggregated "megawidgets" written
in Tcl/Tk themselves), something that Tk has always lacked a recognized
standard version of.

Another thing worth noting about Tix is that it doesn't (as of about a year
ago) follow platform look and feel and so, at least on Windows, felt/looked
a bit clunky. If you like GTK though, you should feel right at home ;-)

BTW, other options for UI development with Python include Fox and FLTK, not
to mention WxPython, but those either have a python wrapper on their
relatively heavy-weight API's (Fox, FLTK) or are a wrapper (WxPython) on a
substantial package (WxWindows). AFAIK, PythonCard is the only UI wrapper
framework that aims at simplifying the task of coding a UI.

Dave LeBlanc

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Roman
> Suzi
> Sent: Monday, January 14, 2002 23:34
> To: pyt...@li...
> Subject: [Pythoncard-users] Re: tix vs. Pycard? for lightweight GUIs
> (fwd)
>
>
> Congratulation!
>
> PythonCard have bacome a choice (from c.l.p):
>
> Sincerely yours, Roman A.Suzi
> --
>  - Petrozavodsk - Karelia - Russia - mailto:rn...@on... -
>
> ---------- Forwarded message ----------
> Date: Tue, 15 Jan 2002 06:38:48 +0000 (UTC)
> From: Andy Todd <an...@ha...>
> To: pyt...@py...
> Newsgroups: comp.lang.python
> Subject: Re: tix vs. Pycard? for lightweight GUIs
>
> st...@fe... (Stephen Ferg) wrote in news:b16e4ef7.0201141505.7b15bac5
> @posting.google.com:
>
> > I'm looking for a quicker, easier way to make simple Python GUIs for
> > quick-and-dirty apps.
> >
> > I've heard good stuff about PythonCard, and now I just heard about
> > Tix.  Does anybody have experience with both of them, to compare them?
> >  Or make recommendations or warnings about them?  Or have
> > recommendations for some other package that supports the coding of
> > lightweight GUIs?
> >
> > Thanks mucho in advance!
> >
>
> Stephen,
>
> In answer to your question, it depends. The two projects you mention have
> slightly different aims and are at different levels of development. I'm
> closer to PythonCard than to Tix but I'll have a stab;
>
> Tix - adds extra widgets and commands on top of TK, which is really
> native to TCL, not Python. It aims to make the library easier to use,
> richer and more pythonic. But its still Tcl/Tk ;-) In this family I'd
> also look at Tkinter (and Tkinter 3000), browse on over to
> http://www.pythonware.com/products/tkinter/index.htm for more
> information. From what I understand Tix is mature and useable today.
>
> PythonCard. This project is still in prototype and aims to provide a
> framework and development tool to make building simple GUI applications a
> lot easier than in any current GUI toolkit for Python (this includes TK,
> wxPython, PyQt, etc). It is now firmly wedded to wxPython
> (http://www.wxpython.org/) and provides a more useable and user friendly
> way to build applications. I would categorise PythonCard as the VB to
> wxPython's MFC (he says, ducking to avoid the flames). The eventual aim
> of PythonCard is to make building a GUI application as simple as painting
> a screen in an IDE (or defining it in a simple text file) and writing as
> little code as possible to control the behaviour of the application.
>
> In conclusion, your best bet is to try both (and other tools like Glade,
> Boa constructor, wxDesigner, PyQt) and see which truly fits your
> requirements.
>
> Of course, a lot depends on your definition of a lightweight GUI. If you
> mean easy to develop, I'd go for PythonCard, if you mean easy on
> resources then I don't think any tool I've mentioned will help you out.
>
> Other things to consider are; platform independence (does it really
> matter to you?), available resources (you can buy books on Tcl/TK but
> there isn't such a beast for PythonCard - yet), and how the toolkit fits
> in with your experience (people who have used Delphi love Boa, people who
> have programmed in swing easily translate to TK). I'm sure I've missed
> plenty of other factors but I'm sure that oversight will be quickly
> rectified.
>
> HTH,
> Andy
> --
> Contents free posts a speciality
> --

[Pythoncard-users] Re: tix vs. Pycard? for lightweight GUIs (fwd)

[Roman S. <rn...@on...>]

Congratulation!

PythonCard have bacome a choice (from c.l.p):

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rn...@on... -

---------- Forwarded message ----------
Date: Tue, 15 Jan 2002 06:38:48 +0000 (UTC)
From: Andy Todd <an...@ha...>
To: pyt...@py...
Newsgroups: comp.lang.python
Subject: Re: tix vs. Pycard? for lightweight GUIs

st...@fe... (Stephen Ferg) wrote in news:b16e4ef7.0201141505.7b15bac5
@posting.google.com:

> I'm looking for a quicker, easier way to make simple Python GUIs for
> quick-and-dirty apps.
>
> I've heard good stuff about PythonCard, and now I just heard about
> Tix.  Does anybody have experience with both of them, to compare them?
>  Or make recommendations or warnings about them?  Or have
> recommendations for some other package that supports the coding of
> lightweight GUIs?
>
> Thanks mucho in advance!
>

Stephen,

In answer to your question, it depends. The two projects you mention have
slightly different aims and are at different levels of development. I'm
closer to PythonCard than to Tix but I'll have a stab;

Tix - adds extra widgets and commands on top of TK, which is really
native to TCL, not Python. It aims to make the library easier to use,
richer and more pythonic. But its still Tcl/Tk ;-) In this family I'd
also look at Tkinter (and Tkinter 3000), browse on over to
http://www.pythonware.com/products/tkinter/index.htm for more
information. From what I understand Tix is mature and useable today.

PythonCard. This project is still in prototype and aims to provide a
framework and development tool to make building simple GUI applications a
lot easier than in any current GUI toolkit for Python (this includes TK,
wxPython, PyQt, etc). It is now firmly wedded to wxPython
(http://www.wxpython.org/) and provides a more useable and user friendly
way to build applications. I would categorise PythonCard as the VB to
wxPython's MFC (he says, ducking to avoid the flames). The eventual aim
of PythonCard is to make building a GUI application as simple as painting
a screen in an IDE (or defining it in a simple text file) and writing as
little code as possible to control the behaviour of the application.

In conclusion, your best bet is to try both (and other tools like Glade,
Boa constructor, wxDesigner, PyQt) and see which truly fits your
requirements.

Of course, a lot depends on your definition of a lightweight GUI. If you
mean easy to develop, I'd go for PythonCard, if you mean easy on
resources then I don't think any tool I've mentioned will help you out.

Other things to consider are; platform independence (does it really
matter to you?), available resources (you can buy books on Tcl/TK but
there isn't such a beast for PythonCard - yet), and how the toolkit fits
in with your experience (people who have used Delphi love Boa, people who
have programmed in swing easily translate to TK). I'm sure I've missed
plenty of other factors but I'm sure that oversight will be quickly
rectified.

HTH,
Andy
-- 
Contents free posts a speciality
-- 
http://mail.python.org/mailman/listinfo/python-list

[Pythoncard-users] Gordon McMillan's installer and PythonCard

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

I started playing with version 5 of Gordon McMillan's installer over the
weekend. I have a working .spec file which I've included below and checked
into cvs for the minimal sample. I have not tested it on Linux, but it
builds standalone on Windows just fine.

I've exchanged some emails with Gordon about adding lines to the spec to
exclude PIL and tkinter from the build. Apparently, the next version of the
installer will have support for excluding packages. Once I figure out the
necessary exclusion lines for the spec file I'll update cvs and reply to
this thread. In the meantime, if you want to exclude PIL/tkinter you can
modify the graphic.py module in the PythonCardPrototype directory to PIL
isn't imported. Just comment out the try/except block and add PIL_FOUND = 0
like so:

"""
try:
    import Image
    # necessary to avoid name collision with Image class
    from Image import fromstring
    PIL_FOUND = 1
except ImportError:
    PIL_FOUND = 0
"""
PIL_FOUND = 0


As with py2exe you'll need to uncomment the import line in minimal.py.
The results of the build are placed in the distminimal directory.

ka
---

"""
A spec file to make a standalone of minimal for
Windows and Linux platforms.  You can get
Gordon McMillans installer from
http://www.mcmillan-inc.com/install1.html

Use this command to build the standalone
and collect the other needed files:

  Build.py minimal.spec

"""

a = Analysis(['minimal.py'],
             pathex=[])
pyz = PYZ(a.pure)
exe = EXE(pyz,
          a.scripts,
          exclude_binaries=1,
          name='buildminimal/minimal.exe',
          debug=0,
          console=1)
coll = COLLECT( exe,
               a.binaries + \
               [('minimal.rsrc.py', 'minimal.rsrc.py', 'DATA')] + \
               [('readme.txt', 'readme.txt', 'DATA')],
               name='distminimal')

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

[Rowland S. <sn0...@ea...>]

On Saturday, January 12, 2002, at 03:44 PM, David LeBlanc wrote:

>
>
>> -----Original Message-----
>> From: pyt...@li...
>> [mailto:pyt...@li...]On Behalf Of Kevin
>> Altis
>> Sent: Friday, January 11, 2002 19:33
>> To: pythoncard-Users
>> Subject: 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.
>
> What ideas did I suggest that can't be built?

Anything can be built - it's just a matter of time.  Currently Kevin's 
doing most of the work, and one person can only take things so far.

I would like to see a fairly sophisticated app builder - but for that to 
happen more people, including myself, are going to have to jump in and 
help.

>
>> 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.
>
> I was just saying that, in supporting windows, prefer later versions. If
> something is supported in NT/2K/XP but not 9X/ME then don't let that 
> stop
> the feature being used.
>
>>>> 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.
>
> I suspect tkinter is somewhat easier for people to use then WxWindows 
> "out
> of the box". That's not meant to be a defense of tkinter though :>

I don't have any experience with tkinter, other than using a few apps 
writtin with it, and for the most part they are pretty lame - the 
limiting factor seems to be tkinter itself, but like I said, i don't 
have enough experience with it to really know.

One of the things that we're trying to get to is at least the first rev 
of a component model that will allow us and others to build some more 
value added components out of the wxPython widgets.  If the model is 
easy to understand and use, then we'll get a body of components that 
make it easier to build a non-trivial app in a short amount of time.

Personally, I think my ideas on a component model are overly 
complicated, I'm currently trying to figure out what is the very minimum 
needed to build and use real-world components.

>
>> 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.
>
> I'm a former user (and still lover) of Tcl/Tk since it was barely 
> usable on
> Windows.
>
>> 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.
>
> Not suggesting that one is better then the other. I wonder if the 
> PythonCard
> abstraction couldn't encompass both (and Fox/FLTK too)?
>
>>>> 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.
>
> Not my point at all. PythonCard _tool_ should have a standard API to the
> extent possible (without rewriting core components like WxPython etc.).
>
>> 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.
>
> 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.
>
>>> 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.
>
> 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).
>
>> 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.
>
> PythonCard keeps sounding like a generic GUI builder - and given 
> antipathy
> towards automatic code generation, only that.

I think gui builder with app framework is closer.

>
>> Regardless, there is a very low chance of us producing something
>> that would
>> generate the HTML and JavaScript for an active web page.
>
> I didn't mention Javascript.
>
>>> 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 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 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?
>
> See above.
>
>>>> 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.
>
> 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.
>
>>>> 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?
>
> Component object model? Standard entry points for modules?
>
>>>> 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.
>
> Different definitions of "dynamic" used here. I can think of several
> definitions. You're using the definition of code creating the interface 
> as
> opposed to something like a resource file (a la' windows) which is a 
> static
> 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.

Sizers are something that we've discussed as being necessary for 
PythonCard to succeed.  The trick is figuring out how to 1) specify 
sizers/constraints in a gui builder and 2) how to capture the 
sizers/constraints in a resource file.

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

We're certainly shooting for a framework that is at a higher level of 
abstraction than wxPython and that adds application development features 
that sit on top of wxPython.

>
>>>> 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.
>
> 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?
>
>>>> 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.
>
> 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?
To me, SOAP is a a communication protocol.  From what I've read, SOAP 
combined with WSDL ( service description ) is something of a distributed 
component model.

IMHO, what we're looking for with PythonCard is a component model closer 
to the JavaBeans model.  JavaBeans is pretty simple until you get into 
the serialization of live beans and complex bean editors, both of which 
we need some level of in PythonCard.

>
>>>> 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.
>
> 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.
>
>>>> 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?
>
> I guess that would all depend on what PythonCard is meant to be. See 
> below.
>
>>> 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.
>
> Well, for starters, XML would be a better representation for resource 
> files
> then what's currently in PythonCard. XML without DTD's are widely and
> successfully used. I don't recall suggesting that XML be typed by 
> humans.
> However, it's easier to read xml then (for example) CSV if you have to 
> read
> it at all. If I had to create a resource file by hand for some reason, 
> i'd
> FAR prefer to do it in XML then in PC resource format.

The Python dictionary format is quite powerful for describing resource 
files, and has the added value of being easily parsed from a textual 
representation.

XML is certainly more verbose than dictionary syntax, but personally I'm 
still not convinced it's easier to read or understand.  Using the native 
dictionary format doesn't exclude the use of XML - someone could define 
an XML resource format and a translator that parses the XML and produces 
a PythonCard resource description, or vice-versa.

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

I think wxPython-Plus would be more descriptive.

Talk to ya,
Rowland


> Regards,
>
> Dave LeBlanc
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

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

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

[David L. <wh...@oz...>]

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Friday, January 11, 2002 19:33
> To: pythoncard-Users
> Subject: 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.

What ideas did I suggest that can't be built?

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

I was just saying that, in supporting windows, prefer later versions. If
something is supported in NT/2K/XP but not 9X/ME then don't let that stop
the feature being used.

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

I suspect tkinter is somewhat easier for people to use then WxWindows "out
of the box". That's not meant to be a defense of tkinter though :>

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

I'm a former user (and still lover) of Tcl/Tk since it was barely usable on
Windows.

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

Not suggesting that one is better then the other. I wonder if the PythonCard
abstraction couldn't encompass both (and Fox/FLTK too)?

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

Not my point at all. PythonCard _tool_ should have a standard API to the
extent possible (without rewriting core components like WxPython etc.).

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

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.

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

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

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

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

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

I didn't mention Javascript.

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

See above.

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

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.

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

Component object model? Standard entry points for modules?

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

Different definitions of "dynamic" used here. I can think of several
definitions. You're using the definition of code creating the interface as
opposed to something like a resource file (a la' windows) which is a static
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.

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

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.

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

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?

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

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?

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

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.

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

I guess that would all depend on what PythonCard is meant to be. See below.

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

Well, for starters, XML would be a better representation for resource files
then what's currently in PythonCard. XML without DTD's are widely and
successfully used. I don't recall suggesting that XML be typed by humans.
However, it's easier to read xml then (for example) CSV if you have to read
it at all. If I had to create a resource file by hand for some reason, i'd
FAR prefer to do it in XML then in PC resource format.

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

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.

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

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.

Regards,

Dave LeBlanc

[Pythoncard-users] changed 'isdefault' attribute to 'default' and textEditor change

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

I updated the 'isdefault' attribute for the Button component. I renamed it
to 'default', changed the _setDefault method and added a _getDefault method
so that it can be used like a normal attribute. You can have only one
default button (obviously) for a dialog or background, so doing something
like:

self.components.btn1.default = 1

will automatically change the default status of any other button that might
have been the default.

I updated the all the dialogs in the samples to use the new name and added
'default' to the Property Editor and resourceEditor. I also updated both the
findfiles and searchexplorer samples so they have default buttons defined in
the their resource files.

The default button works fine on Windows, let me know if it doesn't work
under GTK.

Other changes:
  I changed the gotoLine method in the textEditor sample to ignore wrapped
lines under Windows and jump to the correct line based on newlines ('\n') in
the field; textEditor should always jump to the right line when you
double-click a result line in findfiles. This is different than Notepad
which counts wrapped lines when doing a go to and is part of a larger issue
about how wxTextCtrl reports positions depending on platform and whether the
wxHSCROLL style is used on Windows (PythonCard doesn't use it).

Simon and I got weary of looking at this stuff when he was working on
textRouter, but I'm going to have to get back into it soon to document how
our TextArea class behaves differently on GTK and Windows (and eventually
the Mac). I already switched to the wxTE_RICH style to fix most of the
issues back at release 0.5.3.

added shell key bindings and usage link to toc.html
  http://pythoncard.sourceforge.net/toc.html

ka
ps. I've been using the textEditor sample instead of notepad or PythonWin
for quick edits lately and it has been working fine. I typically grep in
findfiles for things like 'isdefault' which I want to change, then I just
double-click on a result line which opens up the file and jumps to the right
line in the textEditor sample. Then I make my fix, hit Save and repeat. I
also use findfiles all day long to find code in the framework, samples, and
wxPython; I really need to refactor the sgrepmod.py I stole from PythonWin
to make it more efficient and possibly use threads with notification for
updating the results. Of course you can do the same grep/replaces in
PythonWin, Emacs, and probably vim, but sometimes it is nice to eat your own
dog food ;-)

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

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

Kevin:

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

   If Python is installed on the client and is integrated with the browser
as it can be for IE or Mozilla then it may be possible to hook up the code
depending on how wx-specific that code is. Not an easy project though.

   There are other techniques such as providing a PythonCard player plugin
or an "export to plugin" similar to "export to EXE". Are there any benefits
to this? Possibly ;-)

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

   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?

   Neil

RE: [Pythoncard-users] off the deep end

[David L. <wh...@oz...>]

No worries - I sometimes worry that I come across too "in your face" in
email too. I don't feel that you really had anything to apologize for, but I
accept it in the spirit offerrd :-)

This seems like a perfect opportunity to refrain from posting this
hilariously funny 100's of lines long ultimate flame that I found online,
but i'm sure the pig, the goat and the donkey will be happier for it ;-)

As for your earlier post, I think I have not expressed myself well in my
original post that you're responding to. It's also apparant that we differ
in some philosophies; for example, we differ in how we regard XML. On the
other hand, your experience with Boa mirrors mine which is too bad since
it's obvious that a lot of work has gone into it.

WRT the difficulty of coming up to speed on WxWindows, this is a common
problem with large class libraries imo. The classic example is Smalltalk:
you can learn the _language_ in 3 days or less. The _other_ 6 months is
spent in learning the humongous class hierarchy (been there, done that).

As for the rest of the post, i'll either take a stab at replying to yours,
or maybe better yet, start a few new message threads concerning some of the
points we've made back and forth.

Regards,

Dave LeBlanc

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Friday, January 11, 2002 22:47
> To: pythoncard-Users
> Subject: [Pythoncard-users] off the deep end
>
>
> Apologies to David.
>
> I reread my last post and even though I brought up some valid
> issues I think
> I was overly harsh and defensive. Without questions, feedback, and
> criticisms from users and developers and potential users, PythonCard can't
> grow, so all input is always appreciated. This isn't just my
> project either,
> there are other people writing code and contributing in other
> ways so when I
> get on a pulpit somebody should just knock me down.
>
> I got pretty burned out on some wx-dev and wx-users threads this
> week where
> the decisions or explanations didn't go the way I would have
> hoped. That and
> the annoying GTK issue in the resourceEditor really annoyed me, though of
> course a hack is in place now so that is fixed.
>
> Peace,
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] off the deep end

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

Apologies to David.

I reread my last post and even though I brought up some valid issues I think
I was overly harsh and defensive. Without questions, feedback, and
criticisms from users and developers and potential users, PythonCard can't
grow, so all input is always appreciated. This isn't just my project either,
there are other people writing code and contributing in other ways so when I
get on a pulpit somebody should just knock me down.

I got pretty burned out on some wx-dev and wx-users threads this week where
the decisions or explanations didn't go the way I would have hoped. That and
the annoying GTK issue in the resourceEditor really annoyed me, though of
course a hack is in place now so that is fixed.

Peace,

ka

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

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

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

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

[David L. <wh...@oz...>]

Realistically, by the time we're at a real release, Python 2.2 should be
wide-spread. I personally hope (and have seen some signs) that people will
move pretty rapidly towards 2.2.

As for ActiveState... I too confess a weakness for the convenience of the
ActiveState releases of Python, although I have considerable qualms about
their licensing of it and their co-opting of at least one PD software
product entirely. PSF Python now has a nice installer, and for our project,
I don't know that AS Python adds anything (unless PythonWin apps and Windows
Scripting Host compatibility are a goal).

Actually, this does bring up the issue of what the total software context of
PythonCard will be: aside from Python itself and it's attendant libraries
etc, what other components should be considered part of the base? And, aside
from that agreed base, what's the mechanism for describing/defining
(possibly optional) add-on components?

Some ideas:
	* Something equivalent to Perl::DBI to provide "product neutral" database
interfacing. I think there's something analogous to that for Python already.
I'd like us to avoid PyGress, MySqlPython etc. without precluding the use of
those databases by those who chose to use them.
	* Avoid "free for non-commercial use only" products.

Dave LeBlanc

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Friday, January 11, 2002 14:12
> To: pyt...@li...
> Subject: RE: [Pythoncard-users] six blind men describe the beast -
> Python 2.2 requirement
>
>
> > From: Dan Shafer
> >
> > >  Ditto for Python one would assume. Actually, I suggest using
> > Python 2.2 as
> > >  the initial target - the unification of the class hierarchy is
> > just too good
> > >  to pass up. (Frankly, I think this was a big enough change in
> > the language
> > >  to warrant a full bump to 3.0, but so far Guido hasn't sought
> > my counsel ;).
> > >  One wonders what's in store for Python 3.0.)
> >
> > I completely concur. The class stuff in 2.2 has moved the language a
> > LOT closer to a "pure" object model. I thought it should also be
> > called 3.0 and I too wonder at what Guido must have in mind for
> > _that_ release!
> >
> > But for PythonCard, I think a 2.2 target is a solid idea.
>
> I hesitate to require Python 2.2 for the current prototype, 2.2
> is just too
> new. I've been waiting for a solid ActiveState release of 2.2, but perhaps
> it is time I just went with the standard distribution? I have no problem
> with requiring 2.2 for the first real alpha which is not too far
> off, maybe
> a month or so before that's started? The changes in 2.2
> definitely will help
> in cleaning up the current design.
>
> I'm just speculating at this point.
>
> Anyone writing code should make note of 2.2 features they use, so we at
> least know where it would be required. You can add asserts at the top of
> your modules for the features you require.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

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

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

> From: Dan Shafer
>
> >  Ditto for Python one would assume. Actually, I suggest using
> Python 2.2 as
> >  the initial target - the unification of the class hierarchy is
> just too good
> >  to pass up. (Frankly, I think this was a big enough change in
> the language
> >  to warrant a full bump to 3.0, but so far Guido hasn't sought
> my counsel ;).
> >  One wonders what's in store for Python 3.0.)
>
> I completely concur. The class stuff in 2.2 has moved the language a
> LOT closer to a "pure" object model. I thought it should also be
> called 3.0 and I too wonder at what Guido must have in mind for
> _that_ release!
>
> But for PythonCard, I think a 2.2 target is a solid idea.

I hesitate to require Python 2.2 for the current prototype, 2.2 is just too
new. I've been waiting for a solid ActiveState release of 2.2, but perhaps
it is time I just went with the standard distribution? I have no problem
with requiring 2.2 for the first real alpha which is not too far off, maybe
a month or so before that's started? The changes in 2.2 definitely will help
in cleaning up the current design.

I'm just speculating at this point.

Anyone writing code should make note of 2.2 features they use, so we at
least know where it would be required. You can add asserts at the top of
your modules for the features you require.

ka

RE: [Pythoncard-users] Dan Shafer's ScriptExpert

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

> From: Dan Shafer
>
> >Hopefully we can produce a development environment that allows
> >non-programmers to build simple apps without seeing actual code.  This
> >is a big task but would go a long way to getting PythonCard accepted by
> >a larger audience.
>
> I don't know if anyone ever saw my crowning software achievment, "Dan
> Shafer's ScriptExpert," but it was a (largely successful, I think)
> attempt to create a tool in which people could write scripts by
> clicking on buttons and having the program build the script. Highly
> interactive. Sold well for a HC thingie, got a number of good reviews.
>
> Doing something like that for a better-structured language like
> Python might be feasible, but I'm not sure fruitful. That is, I think
> most Python coders would think it silly and useless.

A lot of Python coders, especially the *nix crowd, find IDEs silly and
useless. "I don't need no stinkin' IDE, I have vim or emacs." That doesn't
mean it wouldn't appeal to a particular subset of "inventive users."

> However, creating a squished-down version of that kind of scripting
> tool for a subset of Python that is represented by the PythonCard
> events and handlers, e.g., would be an intriguing notion. Or would it?

A squished down version would certainly make an interesting app.

ka

[Pythoncard-users] Scripting vs. Programming Users

[Dan S. <da...@gu...>]

Kevin Altis wrote:

>  > A sophisticated visual development environment is a must for non
>  > programmers.
>
>We definitely need to be precise here. I don't particuarly care about the
>non-programmers as far what you can do with PythonCard if non-programmers
>means people that aren't going to do any scripting in Python. Dan's
>"Inventive Users" are described as people "who are willing to learn
>scripting but not programming, and who need things that rapidly prototype
>and turn into usable application-like things with minimal hassle." I don't
>understand the programming part, since scripting is programming, but the
>rest sounds right for the less sophisticated programmer end of our audience.

I maintain (and it's completely off-topic which is why I started a 
new thread on it) that there are fundamental differences between 
programming and scripting. I outlined these in a book I wrote about 
300 years ago, but I think there was at least a mild consensus on the 
point then.

Simplistically, scripting removes barriers to entry to software 
development for people who aren't trained in computer science, 
algorithm design, and professional programming. Things like variable 
typing, explicit namespace management, and a bunch of other stuff I'm 
forgetting. At that time, it was also true that scripting languages 
were never compiled and progrmaming languages except for Smalltalk 
always were. That distinction's been blurred.

But I agree with Kevin here. PythonCard should be aimed at people who 
are willing to learn scripting (or what Kevin calls "less 
sophisticated programmer"). They might in turn build things for end 
users who just want to solve a problem. In fact, that's exactly what 
they'll do except much of the time the "end user" will also be them.
>
>I guess what I'm saying is that the intended audience I have in mind does
>not include people looking for a dumbed down FileMaker or HyperCard that
>only goes up to user level 4 (authoring). I'm aiming at people that want to
>use Python to solve problems and need a GUI interface.

I think that makes sense.
-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

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

[Dan S. <da...@gu...>]

>  Ditto for Python one would assume. Actually, I suggest using Python 2.2 as
>  the initial target - the unification of the class hierarchy is just too good
>  to pass up. (Frankly, I think this was a big enough change in the language
>  to warrant a full bump to 3.0, but so far Guido hasn't sought my counsel ;).
>  One wonders what's in store for Python 3.0.)

I completely concur. The class stuff in 2.2 has moved the language a 
LOT closer to a "pure" object model. I thought it should also be 
called 3.0 and I too wonder at what Guido must have in mind for 
_that_ release!

But for PythonCard, I think a 2.2 target is a solid idea.
-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

[Pythoncard-users] (no subject)

[Dan S. <da...@gu...>]

>Hopefully we can produce a development environment that allows
>non-programmers to build simple apps without seeing actual code.  This
>is a big task but would go a long way to getting PythonCard accepted by
>a larger audience.

I don't know if anyone ever saw my crowning software achievment, "Dan 
Shafer's ScriptExpert," but it was a (largely successful, I think) 
attempt to create a tool in which people could write scripts by 
clicking on buttons and having the program build the script. Highly 
interactive. Sold well for a HC thingie, got a number of good reviews.

Doing something like that for a better-structured language like 
Python might be feasible, but I'm not sure fruitful. That is, I think 
most Python coders would think it silly and useless.

However, creating a squished-down version of that kind of scripting 
tool for a subset of Python that is represented by the PythonCard 
events and handlers, e.g., would be an intriguing notion. Or would it?
-- 
Dan Shafer, Author-Consultant
http://www.danshafer.com
http://www.shafermedia.com

[Pythoncard-users] component model redux

[Rowland S. <ro...@we...>]

We need some form of component object model for PythonCard that will
allow us to build sophisticated compound components, and will support
the development of a visual application building tool.

I hope this will kick start another round of discussion on what
type of component model we want.

I've been working on some ideas on and off over the past couple of
months with input from Kevin and Jeff Turner.  I just got back into it 
after a few weeks hiatus, and I think I might be getting overly 
complicated, as well as over my head ;)

I've been trying to think of what features would be necessary to support 
a visual app tool without really defining the requirements for a visual
tool.

I'm going to step back and write down some requirements here, then
take another look at the ideas presented below.

Visual App Builder Requirements

Basic Features

1.  Display a palette of valid component classes.

2.  Allow the creation of one or more forms for a particular
     application.

3.  Allow the creation of simple or compound components that may be
     added to the palette of available components.

4.  Display a particular component's interface.  This includes the
     attributes, events, and methods that the component
     has published as it's public interface.

5.  Allow creation of new instances of a component as elements
     of a Form.

6.  Allow a user to edit the values of a component
     instance's attributes.

7.  Persist component instances and their attribute values to
     a resource file.

Advanced Features

8.  Allow a user to somehow connect the events generated by
     one component to the methods published by another component.
     Some number of logical 'connector' classes will be required
     to allow the wiring together of events and methods
     to build complex behaviors.


Component Model Overview

Components publish Interfaces.  Each Interface describes the events,
attributes and methods that a Component supports.

class Interface :

     def getAttributes( self ) :

     def getEvents( self ) :

     def getMethods( self ) :

Typing

Currently Python is not a strictly typed language, but in order to
build an intelligent visual app builder, we need to know the types
of component attributes and method arguments in order to build
visual editors that are type aware.

Events

Components generate Events. Components publish the names of the
Events that they support.

Components register Listeners.  Components notify registered Listeners 
when Events occur.  Each Event contains a reference to the Component 
that generated the Event.

Attributes

Components have Attributes.  Attributes are typed.  An Attribute has
and 'access' property.  Attribute access can be 'read-only', or
'read-write'.  An attribute's access property determines which
access methods will be automatically provided for the Attribute by the
Component model:

'read-only'   -get<AttributeName>()
'read-write'  -get<AttributeName>() / set<AttributeName>( self, value )

Methods

Methods describe the public methods that a Component supports.

Methods contain Arguments.  Each Argument is typed.

Introspection

An Inspector allows the discovery of a Component implementation's
interface, i.e. it's events, attributes and methods.

Each Component instance provides a reference to an Inspector for
that Component's interface via the Component.getInspector() method.


The following is a meta format for PythonCard component specifications, 
which are themselves meta data about PythonCard components.


type = [ 'boolean', 'dictionary', 'integer', 'list', 'string', ... ]

{
     'events' = [ event-name, ... ],

     'attributes' = {

         name : {

             'type' : type,

             'presence' : 'mandatory' | 'optional',

             'access' : 'read-only' | 'read-write'
         }
     },

     'methods' = {

         name : {

             'arguments' : [
                 {
                   'name' : string,

                   'type' : type
                 }
             ],

             'returns' : type | None
         }
     },

     'interfaces' : [ interface-name ],

     'icon' : icon-file-path,

     'editor' : editor-class-name
}

- type

A list of the built-in data types supported by the component model,
which should include all of the valid Python types ( but doesn't yet ;)

- events

A list of the names of the events that the component generates.

- attributes

A list of the attributes that make up the component.  Each element in the
list is a dictionary with the following keys:

     name        - The name of the attribute.

     type        - The data type of the attribute.

     presence    - A string indicating whether the attribute is
                   required in a resource description or not.
                   The valid values are 'mandatory' and 'optional'.

     access      - A string that specifies whether an attribute can be
                   read-only or read-write.  This property is used to
                   determine which access methods get generated for the
                   component ( get | get/set )

- methods

A list of the methods that make up a component.  Each element in the 
list is a dictionary with the following keys:

     name        - The name of the method.

     arguments   - A list of the arguments that the method supports.
                   Each entry in the list is a dictionary with the
                   following keys:

                       name  - The name of the argument.

                       type  - The data type of the argument

     returns     - The data type of the method's return value, or None.

- icon

The path to the file that contains the icon for the component that will 
be used to represent the component in visual tools.

- editor-class-name

The name of the class that is used to edit instances of the component. 
This will be used by custom components that cannot be edited by some 
combination of the default type editors ( string, boolean, integer, 
list, etc. ).

A ComponentInspector can pull a spec from the ComponentRegistry,
or from an instance of a component.

The definition of an Interface can be specified outside of a Component's
class definition.  This allows for the creation of standard interfaces
that have many implementations.

Example 1 - Timer

class TimerActivated( Event ) :
     ...

TimerInterface = Interface(
     {
         'events' = [ 'TimerActivated' ]

         'attributes' = {

             '`seconds' : {

                 'type' : 'integer',

                 'presence' : 'mandatory',

                 'access' : 'read-write'
             }
         },

         'methods' = {}

         'icon' = 'timer.gif'

         'editor' = None
     }
)

class Timer( Component ) :

     interfaces = [ TimerInterface ]

     def __init__( self, seconds ) :
         self.seconds = seconds
     ...


class TimerClient ( Listener ) :

     def __init__( self, triggerTime ) :
         t = Timer( triggerTime )
         t.addEventListener( 'TimerActivated', self.timeToGo )

     def timeToGo( self, event ) :
         print 'it's time to go!'


c = TimerClient( 5 )

# The following methods are implied by the 'seconds' attribute and
# are created by PythonCard when the component is loaded.

print c.getSeconds()

c.setSeconds( 10 )


Talk to ya,
Rowland

Re: [Pythoncard-users] resourceEditor fix for Linux/GTK

[Cliff W. <log...@ea...>]

On Thu, 10 Jan 2002 23:22:39 -0800
Kevin Altis wrote:

> I've checked in a change to the resourceEditor that hopefully will fix
the
> problem with the resizing handles not working properly. I didn't change
the
> existing Windows code which was already working. Thanks to Cliff Wells
once
> again for the Linux work.
> 
> Cliff didn't have a chance to check the last change I made before he went
> home for the evening, so if there are any tweaks needed I'll post a
> follow-up to this message tomorrow.

I just checked out the CVS and it works fine on Linux/GTK.

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308

[Pythoncard-users] resourceEditor fix for Linux/GTK

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

I've checked in a change to the resourceEditor that hopefully will fix the
problem with the resizing handles not working properly. I didn't change the
existing Windows code which was already working. Thanks to Cliff Wells once
again for the Linux work.

Cliff didn't have a chance to check the last change I made before he went
home for the evening, so if there are any tweaks needed I'll post a
follow-up to this message tomorrow.

ka

[Pythoncard-users] split samples into its own zip?

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

I've updated setup.py and MANIFEST.in to include the 'components' directory
so distutils will work correctly. I'm thinking about splitting the samples
directory into its own zip. On the files page it would look something like:

prototype
  0.6.2
    proto-0.6.2.tar.gz
    proto-0.6.2.win32.exe
    proto-0.6.2.zip
    proto-samples-0.6.2.zip

Part of the reason for doing this is that we never figured out how to
prevent distutils from generating .pyc and .pyo files for every .py file. It
is fine to have those for the framework itself, but it makes it annoying to
look through the sample directories when every module and rsrc.py also has
.pyc and .pyo versions. This bothers me, maybe I'm the only one?

Another reason for the split is that the samples can be placed anywhere the
user wants them, only the PythonCardPrototype package needs to be on the
PYTHONPATH.

The big downside is that people would need to download two files. Another
downside is that since samples and framework versions shouldn't be mixed, it
is a good place for users to make a mistake and blame PythonCard.

Suggestions? The zips we've been using are easy for me and work fine, but
I'm all for "market demand" deciding how we do things.

ka

[Pythoncard-users] textfield, textEditor, findfiles tweaks

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

changed positionToXY in textfield component to handle tuple of length 2 or 3
  This is to deal with a change in wxPython that may change again in a
future version so I'm just being defensive. Actually if Robin changes this
again it might throw an exception in which case it will require a tweak
later.

updated findfiles to deal with the positionToXY issue above. double-clicking
on a result line would return the wrong result in some cases.

changed textEditor.pyw to show the filename in the title bar

ka