pythoncard-users — PythonCard Users and Developers

RE: [Pythoncard-users] prototype cleanup in progress

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

I removed a bunch of the
from somemodule import *
references. I don't think anything has been broken yet, but if you are
getting the latest from cvs, let me know if you run into any problems.

ka

RE: [Pythoncard-users] prototype cleanup in progress

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

This is a BIG CHANGE, so if you have a PythonCardPrototype app you must pay
attention to this one if you want your code to work.

loader.py has been removed and the configuration code moved to config.py

All the samples have been changed to use
  from PythonCardPrototype.config import configOptions
instead of
  from PythonCardPrototype.loader import configOptions

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Wednesday, November 07, 2001 11:29 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] prototype cleanup in progress
>
>
> removed uniqueid.py
>   uniqueid.UniqueIdFactory().createUniqueId() changed to NewId()
> removed monitor.py and navigation.py
>   changed getCurrentBackground() to refer to always refer to the
>   first background in the list; removed all references to _iterator
>
> Rowland and I are working through some other cleanup, so I'll post the
> changes as they are made.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] prototype cleanup in progress

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

removed uniqueid.py
  uniqueid.UniqueIdFactory().createUniqueId() changed to NewId()
removed monitor.py and navigation.py
  changed getCurrentBackground() to refer to always refer to the
  first background in the list; removed all references to _iterator

Rowland and I are working through some other cleanup, so I'll post the
changes as they are made.

ka

RE: [Pythoncard-users] Linux users rejoice, wxMiniFrame removed

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

> I'm investigating some default font point size issues with wxPython, so
> there may be additional changes to font.py, debug.py, etc. to make default
> point sizes work better under Linux.

I updated font.py to use the default system font point size for widgets. For
most Windows users that probably won't change the look of the various
samples, but under Linux the samples will probably have larger fonts and the
widgets and windows may be too small in some cases. Let me know.

I also changed the point size for the Message Watcher scrolling list on
Linux from 10 point to use the system default point size.

ka

[Pythoncard-users] Shell and Namespace Viewer, one window or two?

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

If you use PyCrust standalone, then you are used to having a single
split-pane window with a menubar for the shell, rather than the two windows
that PythonCard uses. I think there is probably a lot of benefit to having
most apps that use the PyCrust shell presenting a common interface to users,
so I'm considering just using Patrick's CrustFrame as is rather than having
separate shell and namespace windows.

The change will require some modifications and probably some experimentation
by Patrick and myself to make sure there aren't any problems with using the
CrustFrame as a child window of the main PythonCard app. So, I would like to
hear whether anyone thinks having one window would actually be bad?

If you haven't run PyCrust standalone, then you can run PyCrust.py or
PyCrustApp.py depending on which version you have installed to see what it
looks like.

ka

[Pythoncard-users] Linux users rejoice, wxMiniFrame removed

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

I've updated all the debug windows: Message Watcher, Namespace Viewer,
Property Editor, and Shell so they just use standard wxFrame windows instead
of wxMiniFrame. When you clicked on one of those windows on Linux in the
past it caused the window to "jump" about 20 pixels. This has been a bug
with wxWindows and wxGTK for a long time and Vadim posted a message today on
wx-users saying he didn't know how to fix it, so I figure it is time to give
up on wxMiniFrame. I think the windows should behave as they did in the
past, but if not, let me know.

I also changed worldclock to use StaticText instead of a TextField with no
border, since the no border option doesn't appear to work with GTK and just
makes the sample look horrible. I left the no border TextField in the
widgets sample in case we're able to do it in GTK or the Mac at a later
time.

I'm investigating some default font point size issues with wxPython, so
there may be additional changes to font.py, debug.py, etc. to make default
point sizes work better under Linux.

ka

RE: [Pythoncard-users] release 0.4.6 zip

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

> Kevin Altis wrote:
>
> > I've posted proto-0.4.6.zip
> > http://sourceforge.net/project/showfiles.php?group_id=19015
> > The changelog is below.
> >
> > I'm not going to build installers for 0.4.6 until next week. If
> any problems
> > are found with the .zip distribution between now and then I'll
> update it to
> > a 0.4.6.1 release.
>
>
> Not a problem, but I've just updated the dbBrowser sample to use a modal
> dialog for login. The sample has been updated to 0.3 and the changes are
> in CVS. There is no problem if we don't include it in this release,
> although it would be a shame not to. In the absence of any requests from
> the list my next task for this sample is to add support for Oracle
> databases. I may also slip in support for CSV files but they don't
> exactly provide the strong metadata that the application expects so the
> results may be dissapointing.

We'll just plan on doing another release. I've been meaning to add a menu
editor dialog to the resourceEditor sample and I may also modify the
resourceEditor to be able to edit a dialog as well. Right now, it doesn't
know that dialog rsrc.py files are of a different format because they aren't
complete stacks.

I never got any feedback on where to store dialogs resources and classes.
There is a lot of sense to just putting the dialog resources in the main
rsrc.py file, but I need to see how that complicates the current framework
resource loading, resourceEditor, etc.

ka

Re: [Pythoncard-users] release 0.4.6 zip

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

Kevin Altis wrote:

> I've posted proto-0.4.6.zip
> http://sourceforge.net/project/showfiles.php?group_id=19015
> The changelog is below.
> 
> I'm not going to build installers for 0.4.6 until next week. If any problems
> are found with the .zip distribution between now and then I'll update it to
> a 0.4.6.1 release.


Not a problem, but I've just updated the dbBrowser sample to use a modal 
dialog for login. The sample has been updated to 0.3 and the changes are 
in CVS. There is no problem if we don't include it in this release, 
although it would be a shame not to. In the absence of any requests from 
the list my next task for this sample is to add support for Oracle 
databases. I may also slip in support for CSV files but they don't 
exactly provide the strong metadata that the application expects so the 
results may be dissapointing.

> 
> I would be very interested to see other examples of user-defined dialogs
> using GenericDialog.
> 
> ka
> ---
[snipped release notes]
> 

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

[Pythoncard-users] release 0.4.6 zip

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

I've posted proto-0.4.6.zip
http://sourceforge.net/project/showfiles.php?group_id=19015
The changelog is below.

I'm not going to build installers for 0.4.6 until next week. If any problems
are found with the .zip distribution between now and then I'll update it to
a 0.4.6.1 release.

I would be very interested to see other examples of user-defined dialogs
using GenericDialog.

ka
---
Release 0.4.6 2001-10-30
added FindDialog to textEditor sample to show use of GenericDialog
  class for user-defined modal dialogs. the user-defined FindDialog
  mimics the look and behavior of the FindDialog in dialog.py
added GenericDialog class (dialognew.py)
fixed _translateFont bug that was returning the wrong font family
  when using the Font dialog
removed textEnter event
  pressing return in TextField or PasswordField should now be the
  same as pressing tab
  updated proof and searchexplorer samples
added modal FindDialog to dialog.py
  updated dialogs sample to show FindDialog
  updated addresses sample to use FindDialog, but didn't implement
  find logic to do the actual searching
added _used flag to Event class and associated methods to support
  proper use of skip with keyPress
added keyDown, keyUp, and keyPress events
added turtle.py module (AbstractTurtle and BitmapTurtle classes)
  updated turtle sample to use the new module
minor fixes to BitmapCanvas
added textEditor sample
converted samples launcher to use sizers
fixed CompactStack in textIndexer (thanks Patrick)

[Pythoncard-users] updated textEditor sample, modal dialog example

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

Here's the updated readme.txt

ka
---
simple text editor

Do not use this sample as a real text editor. Depending on your platform, it
is limited to 32K of text and there could be various bugs that would corrupt
your text, so always work on copies of documents. That's why I didn't put a
Save menu item in the File menu, for safety, you can only do a Save As...

You can set the default font which along with the last position and size of
the window will be saved in a user.config.txt file.

This sample shows off the FindDialog in dialog.py, which is a custom dialog
built directly in wxPython as well as the FindDialog class based on
GenericDialog, which works more like a normal background. The resource
definition for the class is in find.rsrc.py. You can use the FindDialog
class as a template for how to do your own modal dialog classes. You must
use the OK (5100) and Cancel (5101) ids for your default and cancel buttons
or the dialog won't be dismissed properly.

The find dialog remembers the last find settings and so acts more like a
Find Next.

The find algorithm is not able to do a "match whole words only" find.

The About dialog displays the current filename, character, word, and line
count.

This is the only sample that uses a .pyw extension, so it doesn't show a
console window when the sample is run. If any error messages are output due
to a runtime error, you won't see them. You can change the extension back to
.py if you want to experiment with the code.

RE: [Pythoncard-users] modal dialogs for PythonCard

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

I had an import conflict problem with putting the GenericDialog class into
dialog.py that I was unable to track down, so I just checked it in as
dialognew.py. The example code below should work without changes.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, October 15, 2001 4:21 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] modal dialogs for PythonCard
>
>
> I am pleased to say that after some false starts yesterday and today, some
> email exchanges with Robin, a bit of inspiration, and a generous
> donation to
> the god of kludge, we are close to having generic modal dialogs in
> PythonCard. I've included an example below.
>
> The nice thing about the modal dialogs is that they work almost
> identically
> to the Background class. They don't have a menubar or a background image,
> but all of the widgets that we have now should work in the modal
> dialog and
> the attribute and event handlers work identically.
>
> Well not quite identically. Both the default button and the cancel buttons
> need to call event.skip() and you have to add an id attribute to the
> resource
>
> I'm going to mull over this tonight before putting the code into cvs, but
> I'll post when I do. I have some other issues I want to address on this
> topic, but I have to run right now, so I'll post on those issues later as
> well.
>
> ka
> ---
>
> class FindDialog(PythonCardPrototype.dialognew.GenericDialog):
>     def __init__(self, aBg, searchText='', wholeWordsOnly=0,
> caseSensitive=0) :
>         # load the resource
>         aDialogRsrc =
> PythonCardPrototype.res.ResourceFile('find.rsrc.py').getResource()
>
>         PythonCardPrototype.dialognew.GenericDialog.__init__(self, aBg,
> aDialogRsrc)
>
>         # if some special setup is necessary, do it here
>         self.components.fldFind.text = searchText
>         self.components.chkMatchWholeWordOnly.checked = wholeWordsOnly
>         self.components.chkMatchCase.checked = caseSensitive
>
>         print "init done"
>
>     def on_btnFindNext_mouseClick(self, target, event):
>         print "btnFindNext"
>         print self.components.fldFind.text
>         event.skip()
>
>     def on_btnCancel_mouseClick(self, target, event):
>         print "btnCancel"
>         event.skip()
>
> class Minimal(PythonCardPrototype.model.Background):
>
>     def on_btnFind_mouseClick(self, target, event):
>         dlg = FindDialog(self)
>         dlg.showModal()
>         print "fldFind", dlg.components.fldFind.text
>         print "chkMatchWholeWordOnly",
> dlg.components.chkMatchWholeWordOnly.checked
>         print "chkMatchCase", dlg.components.chkMatchCase.checked
>         print "FindDialog result:\naccepted: %s\nreturned: %s\n" %
> (dlg.accepted(), dlg.returned())
>         dlg.destroy()
>
>
> ---
>
> {'type':'GenericDialog',
>     #'file':'find.py',
>     'classname':'Find',
>     'name':'dlgFind',
>     'title':'Find dialog',
>     'position':(5, 5),
>     'size':(370, 120),
>     'components': [
>
> {'type':'StaticText',
>     'name':'stcFindWhat',
>     'position':(7, 10),
>     'text':'Find What:',
>     },
>
> {'type':'TextField',
>     'name':'fldFind',
>     'position':(70, 7),
>     'size':(195, -1),
>     },
>
> {'type':'Button',
>     'name':'btnFindNext',
>     'position':(280, 5),
>     'label':'Find Next',
>     'id':5100,
>     },
>
> {'type':'Button',
>     'name':'btnCancel',
>     'position':(280, 35),
>     'label':'Cancel',
>     'id':5101,
>     },
>
> {'type':'CheckBox',
>     'name':'chkMatchWholeWordOnly',
>     'position':(7, 35),
>     'label':'Match whole word only',
>     },
>
> {'type':'CheckBox',
>     'name':'chkMatchCase',
>     'position':(7, 55),
>     'label':'Match case',
>     },
>
> ] # end components
> } # end GenericDialog
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] moving to a PythonCard alpha

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

I'm going to spend the next few weeks focusing on a wxPython-specific
application framework. I need to catch up on reading background material,
check in to see how anygui is coming along, etc. Depending on how quickly
work progresses, I should be able to bounce between that project and
PythonCard later this year.

Sometime in the next week I plan to add the rough GenericDialog code to cvs
and probably make a few other tweaks before making a PythonCardPrototype
0.4.6 release. That will give us a main window with user-defined dialogs. If
it is possible to add Rowland's multi-window fix without gutting or breaking
model.py, etc. then I'll try and put that in as well.

In order for PythonCard to move beyond the prototype stage we definitely
need more input from the existing user base as well as more developers.
Since PythonCard lacks critical mass at this point I want to see what can be
accomplished building something of general interest to all wxPython users.

PythonCard isn't dead, but I'm not going to spend much more time modifying
the existing prototype. I think it fulfilled its purpose and you can
continue to use it as is for any simple apps you want to build. What I hope
to do in the future is leverage the work on a wxPython framework to build
the first alpha version of PythonCard.

I would still appreciate input on the posts from the last week to help
define the direction PythonCard will take.

ka

[Pythoncard-users] Model/View/Controller

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

Reading the messages on this list for the last couple of days has been a 
challenge for me, and I've been reaching for Google on a regular basis 
when people have started mentioning concepts that I'm not familiar with. 
Learning new tricks, tools and concepts is one of my aims for 
participating in this project by the way, and I'm certainly learning at 
the moment.

One particular phrase that has come up repeatedly (not only here, but 
also on the anygui list) is the design pattern known as 
Model/View/Controller, or MVC. For those reading this list who, like me, 
aren't fully buzzword compliant I've found a useful reference that 
explains the concept in words that even I can understand;

http://www.zope.org/Resources/Mozilla/ZWiki/ModelViewController

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

[Pythoncard-users] wxPython event binding and lookup example

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

I'm evaluating how to do things in wxPython that we're doing today in
PythonCard user code. I thought I would post the tests to the list as I do
them in case anyone else has comments or suggestions. If you aren't familiar
with wxPython, then most of this message isn't going to make much sense.

The example below is done with the minimal sample as the starting point, so
you can open minimal with a shell and try it yourself.

What I wanted to do was bind a method to a wxButton control, so that when
you click the button, it puts some text into the wxTextCtrl named field1 at
the same level in the hierarchy (both controls sit on a wxPanel). In
PythonCard:

    def on_btn1_mouseClick(self, target, event):
        self.components.field1.text = 'click btn1'

The name of the mouseClick method below is just a name, it doesn't have to
be 'mouseClick' though that is descriptive. The next question is probably
where would the handler be defined in user code? Also, to be safe, rather
than using 'self', event.GetEventObject() would probably have to be used
instead to get the wxButton instance.

>>> bg = pcapp.getCurrentBackground()
>>> comp = bg.components
>>> from wxPython.wx import *
>>> b = wxButton(bg.panel, -1, 'btn1', (0, 30), name='btn1')
>>> b.GetParent()
<C wxPanel instance at _1516878_wxPanel_p>
>>> p = b.GetParent()
>>> p.FindWindowByName('field1')
<C wxTextCtrl instance at _7e2858_wxTextCtrl_p>
>>> b.GetParent().FindWindowByName('field1')
<C wxTextCtrl instance at _7e2858_wxTextCtrl_p>
>>> b.GetParent().FindWindowByName('field1').SetValue('hello btn1')
>>> def mouseClick(self, event):
...     self.GetParent().FindWindowByName('field1').SetValue('click btn1')
...
>>> import new
>>> m = new.instancemethod(mouseClick, b, wxButton)
>>> m
<method wxButton.mouseClick of wxButton instance at 0154706C>
>>> EVT_BUTTON(b, b.GetId(), m)

ka

[Pythoncard-users] Sourceforge

[Thomas H. <tho...@io...>]

Andrew Kuchling posted this link to python-dev:
http://www.advogato.org/article/357.html

Interesting to everyone using SF.

Thomas

[Pythoncard-users] still going...

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

I'm going to wait until tomorrow to post the prototype I'm working on. 
I need to mull some stuff over.

-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

[Pythoncard-users] Fw: PAGE - A drag and drop GUI Generator for tk

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

Food for thought. There is a screenshot and generated source at
http://page.sourceforge.net/example.html

ka
---

"Don Rozenberg" <ro...@mc...> wrote in message
news:<9r1...@en...>...
> PAGE can now be installed on Win32.
>
> PAGE is a tool which helps to create GUI for Python programs.  It uses
> Tk and Tix widgets.  PAGE is not an end-all, be-all tool, but rather
> one that attempts to ease the burden on the Python programmer. It is
> aimed at the user who will put up with a less-than-general GUI
> capability in order to get an easily generated GUI. It does not build
> an entire application but rather is aimed at building a single GUI
> window.  PAGE is based on Stewart Allen's Visual Tcl program. In fact,
> it is vTcl, with an additional module that generates Python code and
> some bug fixes.  PAGE is built on version 1.2.2 of Visual Tcl, version
> 8.1.1 of Tix, and Tcl/Tk version 8.3. It supports many Tk
> widgets and a subset of the Tix widget set.  The user will have to
> acquire and install Tix and tcl to use this program.
>
> Page works with Python 2.1.1 and now runs on
> Linux and Win32. It has been tested on Linux Mandrake 8.1 and Win98.
>
>
> The PAGE web site is
>
>         http://page.sourceforge.net

Re: [Pythoncard-users] Possible Project Idea

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

Kevin Altis wrote:

>>From: Patrick K. O'Brien
>>
>>I was trying to find a reason to get more involved in PythonCard
>>by finding
>>a project that overlapped my current interests. Namely, using ZODB as the
>>persistent storage for simple database applications that will have a
>>wxPython interface (as well as a web interface and possibly a Zope
>>interface). I also thought picking a sample app that embraced the need for
>>multiple windows (which a few people mentioned as a high priority) would
>>help focus our efforts.
>>
> 
> We do need multiple windows. In fact, in order to make reasonable progress
> on an environment we need to be able to create the environment in PythonCard
> itself, since it takes too much time and effort to do every piece using raw
> wxPython. If we can redo the Message Watcher, Property Editor (a better one
> this time) as PythonCard windows they will be much easier to maintain and
> enhance. My first window was the FindDialog and once we get past these
> future direction messages, I'll get back to that. We can then start adding
> other dialogs and windows we would need for an environment, redo the
> resourceEditor, etc.


I have multiple windows working in the prototype of the design I posted 
to the list the other day.  I'm copying pasting code from 
PythonCardPrototype in to my prototype and have a sample app that:

Loads from a Resource file.
Has multiple windows, as specified in the resource file.
Can handle MouseClickEvent generated from Button
All Components ( Button ) in this case, can have their own Script object 
that handles any Events for the Component.

The Script/Scriptable model is very flexible and will allow us to build 
a user scripting environment ala Handlers and the last PythonCardPrototype.

Rewriting the MessageWatcher, etc. using strictly PythonCard should be 
pretty straightforward with Components and Scripts.

I'm making lot's of progress today and will post what I have this evening.


> 
>>Based on your feedback it sounds to me like there is no overlap. Sigh.
>>
> 
> I wouldn't say that. Why can't that just be a sample? You'll probably have
> less issues with a moving class spec which is what is going to cause trouble
> with ZODB, which has no generic external tools for manipulating the
> database. This is more or less the direction I wanted to go with the
> textIndexer and addresses samples, both or which have the beginnings of a
> more generic storage model.
> 
> So, your idea is a good one, why not get started? As pieces are solidified,
> we can transition them to the general framework.


If we can define a set of interfaces that provide an abstraction layer 
to discovering changes and then storing those changes, anyone could work 
on implementations for Zope, XML files, etc. on their own and then we 
could roll them into the code base.

Here are my ideas for a storage abstraction:

class ChangeEvent( Event ) :

    def __init__( self, changeable )
       self.changeable = changeable

class ChangeEventListener :

     def changed( changeEvent ) :
        raise 'abstract-method-error'

class Changeable :

     def addListener( changeListener )
         ...

     def fireChangeEvent( changeable )
         # call changed( ChangeEvent( changeable ) ) on
         # all listeners

Components can be Changable, and the persistence subsystem can register 
as a listener to a Document object

class Component( Changeable ) :
     ...

class Document( Changeable ) :
     ...

class DocumentStorage( ChangeEventListener ) :

     def changed( changeEvent )
         ...
 
Documents listen for ChangedEvents generated by Components, 
DocumentStorage objects listen for ChangeEvents generated by Documents.

Something like DocumentStorage would be the abstraction layer between 
PythonCard and Zope, mySql, XML files, etc.

When we get to the HyperCard model, we chould have a StackStorage class, 
or something to that effect.


> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 



-- 
Talk to ya,
Rowland

"The whole problem with the world is
that fools and fanatics are always so
certain of themselves, and wiser people
so full of doubts."

-- Bertrand Russell,
    quoted in the book
    A Word a Day

[Pythoncard-users] the HyperCard model

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

I've been going over Thomas Heller's Doc/View code posted to the
wxpython-users list as well as looking at the Doc/View application framework
provided by wxWindows (but not included in wxPython) and thinking about the
HyperCard model. So, without further delay, I present another mind spew.

From a user/programmer standpoint HyperCard had a very interesting model.
The simplest way to see this model in an updated form is to download
Revolution
http://www.runrev.com/revolution/index.html
http://www.runrev.com/revolution/downloads/downloads.html
Script length is limited in this version, but it does run on a variety of
platforms, so everyone can look at it. The scripts are a HyperTalk
derivative, or more generally known as xTalk script languages.

One of the main points of PythonCard is to use Python as the scripting
language and leverage the existing Python libraries, so Revolution isn't a
viable substitute, but by taking a look at it, those of you not familiar
with HyperCard will see some of the original HyperCard model in action.

Almost every "object" in HyperCard could have an associated script. There
was a hierarchy to the objects so that if an event or message to an object
wasn't handled at one layer it would pass onto the next object in the
hierarchy. We've implemented a simple version of this in the current
framework, which you can see in the tictactoe sample; only one background
handler is required to deal with all the mouseClick messages for the
BitmapButtons. You can't actually get the same result just using wxPython
EVT_ bindings directly, since those have no concept of message passing.

There were really only two widget types, button and field. Rather than
distinct "classes" for radio buttons and check boxes, those were just
different "styles" of buttons along with opaque, rectangle, round rect,
shadow, standard, default, oval, and popup. Popup was a menu (our Choice
class). Depending on the style, a button could also have a standard Mac icon
(32x32 black and white with a mask). I have to agree with Rowland, that
trying to stuff everything into a button or field type seems outmoded today
and that it is better to have distinct classes instead.

Like buttons, fields also had a transparent style. Transparency is something
we can't do with wxPython, at least not consistently. Transparency combined
with overlapping buttons and fields, was a common aspect of many HyperCard
stacks. Most of the time, these combinations were elegant hacks done to get
around HyperCards' limited widget set.

You can think of the stack as both a document and an application. A document
such as a text file has no smarts, but a HyperCard stack which is the
document type of the HyperCard application does have smarts. Furthermore,
anyone with HyperCard can modify the document/application to better suit
their needs. Of course, you could also create a HyperCard stack that
manipulated other document types, further complicating the normal
application/document definitions. If you're not familiar with HyperCard,
you're probably starting to see why it is hard to describe exactly what
HyperCard was.

Stacks were made up of one or more backgrounds and each background contained
one or more cards. Cards are roughly analogous to a record in a database,
but each card can have unique objects on it in addition to the common
objects shared between cards on the same background. The current PythonCard
framework supports only a single background and no cards. You can also think
of the card and background as layers, with the card elements layered on top
of the background layer, so visually anything on the card layer would
overlap anything in the background layer. If you wanted to create something
directly analogous to a normal flat-file database in HyperCard then you put
all your buttons and fields in the background layer and if you wanted a
button or field to share the same state across cards then you set a "shared
hilite" flag to true.

HyperCard transparently saved both the meta-data and data for all the
objects except the script, which you had to save manually. Most of the time
this was welcome, sometimes this was extremely annoying, especially when you
Cut an object out of the stack and then ended up copying something else
before pasting it and ended up losing the object, script, etc. Depending on
the feature set of our environment, we'll probably have similar issues. At a
minimum, I would like the option to suspend whatever transparent save
mechanism we implement both to improve performance of certain operations and
allow for reverting to the last saved version of an applciation/document.

I haven't used HyperCard in a long time, so any errors above are due to a
bad memory. Please feel free to supplement or correct the descriptions above
or bring up important aspects of the HyperCard model that I skipped.

Writing up the description above has convinced me even more that we probably
don't want to adhere to the HyperCard model too closely, but just take the
best parts. As the tag line says, "PythonCard is a software construction kit
(in the spirit of Apple's HyperCard) written in Python." PythonCard is not
HyperCard.

ka

RE: [Pythoncard-users] Possible Project Idea

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

> From: Patrick K. O'Brien
>
> I was trying to find a reason to get more involved in PythonCard
> by finding
> a project that overlapped my current interests. Namely, using ZODB as the
> persistent storage for simple database applications that will have a
> wxPython interface (as well as a web interface and possibly a Zope
> interface). I also thought picking a sample app that embraced the need for
> multiple windows (which a few people mentioned as a high priority) would
> help focus our efforts.

We do need multiple windows. In fact, in order to make reasonable progress
on an environment we need to be able to create the environment in PythonCard
itself, since it takes too much time and effort to do every piece using raw
wxPython. If we can redo the Message Watcher, Property Editor (a better one
this time) as PythonCard windows they will be much easier to maintain and
enhance. My first window was the FindDialog and once we get past these
future direction messages, I'll get back to that. We can then start adding
other dialogs and windows we would need for an environment, redo the
resourceEditor, etc.

> Based on your feedback it sounds to me like there is no overlap. Sigh.

I wouldn't say that. Why can't that just be a sample? You'll probably have
less issues with a moving class spec which is what is going to cause trouble
with ZODB, which has no generic external tools for manipulating the
database. This is more or less the direction I wanted to go with the
textIndexer and addresses samples, both or which have the beginnings of a
more generic storage model.

So, your idea is a good one, why not get started? As pieces are solidified,
we can transition them to the general framework.

ka

RE: [Pythoncard-users] Possible Project Idea

[Patrick K. O'B. <po...@or...>]

What did I have in mind? Well, you kind of killed what I had in mind. <wink>

I was trying to find a reason to get more involved in PythonCard by finding
a project that overlapped my current interests. Namely, using ZODB as the
persistent storage for simple database applications that will have a
wxPython interface (as well as a web interface and possibly a Zope
interface). I also thought picking a sample app that embraced the need for
multiple windows (which a few people mentioned as a high priority) would
help focus our efforts.

Based on your feedback it sounds to me like there is no overlap. Sigh.

---
Patrick K. O'Brien
Orbtech
"I am, therefore I think."

-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Kevin
Altis
Sent: Monday, October 22, 2001 12:37 PM
To: Pythoncard
Subject: RE: [Pythoncard-users] Possible Project Idea

> From: Patrick K. O'Brien
>
> * Some kind of persistent data storage.

A lot of apps don't need persistent storage. We should probably also make a
distinction between the meta-data for widgets and the field/record data they
contain.

> If there is interest in this idea, here is what I think needs to happen:
>
> 1. Decide on a sample application that reflects the kind of app
> people would
> have done in HyperCard.

That's part of the problem. HyperCard was a general purpose software
construction kit that was used for all sorts of applications. Even things
that couldn't be done well in it directly such as traditional BIG apps: Word
processor, spreadsheet, SQL database, draw program, etc. people using
HyperCard as a front-end if you will for BIG apps or used external code to
do do stuff that HyperCard didn't have built-in support for such as a grid
control (spreadsheet).

However, HyperCard did impose enough limitations through its model and tools
that for a lot of things it simply got in the way. I think this is what
Rowland refers to when he says we should just abandon the HyperCard baggage.
I'm pretty much convinced now that we should have a more generic model and
then if we want to follow the HyperCard model later, it should be built on
the more generic model.

> 2. Decide how we are going to store the data - CSV, ZODB, XML, MySQL, etc.

Initially, I would suggest an abstraction layer between the storage of data
and meta-data and then use a backend that is easy to parse and manipulate
with tools outside of PythonCard. That means not using ZODB or any binary
storage format. The reason for the restriction is that until the model and
interfaces settle down we'll have to muck about in the resource and data
files, finding bugs, coding examples from scratch, etc.

> 3. Develop the app in a collaborative fashion to get feedback
> from more than
> one person.
>
> 4. Document as much as possible so that this serves as a tutorial
> of sorts.
>
> 5. Repeat for the next app until PythonCard is perfect.
>
> How does this idea grab everyone else? Good, bad, indifferent?

If there is one app that will cover most of the issues you've brought up it
is probably a contact manager like the addresses sample, but with more
features. However, in order to generate more interest an app that
manipulated and published web pages via a template system, outlines,
whatever, would probably be a better choice. What did you have in mind?

ka


_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

RE: [Pythoncard-users] Possible Project Idea

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

> From: Patrick K. O'Brien
>
> * Some kind of persistent data storage.

A lot of apps don't need persistent storage. We should probably also make a
distinction between the meta-data for widgets and the field/record data they
contain.

> If there is interest in this idea, here is what I think needs to happen:
>
> 1. Decide on a sample application that reflects the kind of app
> people would
> have done in HyperCard.

That's part of the problem. HyperCard was a general purpose software
construction kit that was used for all sorts of applications. Even things
that couldn't be done well in it directly such as traditional BIG apps: Word
processor, spreadsheet, SQL database, draw program, etc. people using
HyperCard as a front-end if you will for BIG apps or used external code to
do do stuff that HyperCard didn't have built-in support for such as a grid
control (spreadsheet).

However, HyperCard did impose enough limitations through its model and tools
that for a lot of things it simply got in the way. I think this is what
Rowland refers to when he says we should just abandon the HyperCard baggage.
I'm pretty much convinced now that we should have a more generic model and
then if we want to follow the HyperCard model later, it should be built on
the more generic model.

> 2. Decide how we are going to store the data - CSV, ZODB, XML, MySQL, etc.

Initially, I would suggest an abstraction layer between the storage of data
and meta-data and then use a backend that is easy to parse and manipulate
with tools outside of PythonCard. That means not using ZODB or any binary
storage format. The reason for the restriction is that until the model and
interfaces settle down we'll have to muck about in the resource and data
files, finding bugs, coding examples from scratch, etc.

> 3. Develop the app in a collaborative fashion to get feedback
> from more than
> one person.
>
> 4. Document as much as possible so that this serves as a tutorial
> of sorts.
>
> 5. Repeat for the next app until PythonCard is perfect.
>
> How does this idea grab everyone else? Good, bad, indifferent?

If there is one app that will cover most of the issues you've brought up it
is probably a contact manager like the addresses sample, but with more
features. However, in order to generate more interest an app that
manipulated and published web pages via a template system, outlines,
whatever, would probably be a better choice. What did you have in mind?

ka

Re: [Pythoncard-users] Possible Project Idea

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

Patrick,

I'm with you, let's get started.

Patrick K. O'Brien wrote:

> Here is an idea that might help us focus and determine the direction for
> further PythonCard development. The key to the idea is to start with the end
> in mind. By that I mean, let's start with a description of what we want to
> end up with and work backwards to see what we have to accomplish to achieve
> that end.


Making sure we make available working versions as often as possible. 
Working code is good code, big ideas are only useful if you are writing 
a book. As a project manager of mine once said "release hard and release 
often".

> 
> As I see it, the end that most people seem to want is a tool that lets them
> easily create simple GUI applications that manage information without having
> to know much about GUIs or databases or even programming. What does this
> imply?


I agree, its always been one of the goals of the project. Whilst no one 
has talked about it to the best of my knowledge (although I haven't got 
the archives handy), there implication was always that we would build 
the framework and then tack a build environment on top. Now you mention 
it, and I think about it, why shouldn't we build them in parallel.

> 
> * Some kind of visual screen builder.


We already have a head start here with the resource editor, property 
editor, message watcher and PyCrust. There is no reason why we can't 
build on these and produce a fully featured IDE. The missing link as I 
see it is a script editor that allows us to specify trigger code or 
methods against particular events, widgets or event/widget combinations. 
  Kevin may have some thoughts about using specific wx controls after 
his experimentation with the textEditor sample last week.


> 
> * Some kind of persistent data storage.
> 


My thoughts on this subject apply to PythonCard as a whole. We should 
use a simple, lightweight, storage layer that is easy to provide with 
PythonCard (or comes as standard with Python) but we should use a 
generic interface so that we can easily replace our storage layer. I 
know you are concentrating on Zope, and I'm leaning towards Gadfly at 
the moment. It needs a little light polishing and the author is being a 
little quiet at the moment, but I am holding out hope. We can simplify 
the interface even more with something like SQLDict 
(http://dustman/net/andy/python/SQLDict) to provide dot notation access 
to the data and Bob's your Uncle.

> This also implies that some things are less important. For example, support
> for multiple GUI toolkits would be nice, but users would be happy with just
> wxPython as long as it was made easy. Storing widget definitions in a
> resource file is nice, but users would rather not even see that, let alone
> care about how the resource file is formatted or whether it is XML or not.


I like resource files and agree with Kevin that we should keep them. We 
definitely need to wrap this up in any IDE we develop for PythonCard so 
that is step 2 on our requirements list.

> 
> With this in mind, I think we need to keep ourselves focused on the goal,
> and not get too sidetracked by things like the format of the resource file.
> Especially since we have no easy persistent data storage mechanisms that
> allow an app to have multiple windows/screens/records, and we have only the
> beginning of a visual screen builder.


See above, but perhaps one way to test out different storage layers 
would be to write a two-way interface between our databases and our 
resource files. We need a general data model to provide the basis for 
our work, but I for one would not like to dive straight into some kind 
of dynamic data access handling (for user defined applications).

> 
> So if the goal is simple visual construction of screens that access
> transparently persistent data, I'd like to suggest that we embark on a joint
> effort to create such an application from scratch, using the tools that we
> have so far in PythonCard, as a way to flesh out further requirements. The
> development of this sample application could even be documented as a
> tutorial for others.


It may be a little tricky to use as a tutorial, but you never know. The 
best part of such a project would be the development of an even more 
useful sample application and as a spark for the further development of 
the framework.

> 
> If there is interest in this idea, here is what I think needs to happen:
> 
> 1. Decide on a sample application that reflects the kind of app people would
> have done in HyperCard.


I think you've got it defined at the top of the page. I've been reading 
Joel on Software (http://www.joelonsoftware.com/) recently so I'll even 
start a functional specification tomorrow. Draft, obviously.

> 
> 2. Decide how we are going to store the data - CSV, ZODB, XML, MySQL, etc.


Lets start with ZODB and I'll try and then fit it to Gadfly or MySQL 
using SQLDict. If anyone wants to use XML they can try it later but I 
would suggest that is an output format rather than a storage mechanism.

> 
> 3. Develop the app in a collaborative fashion to get feedback from more than
> one person.


Always happy to chip in.

> 
> 4. Document as much as possible so that this serves as a tutorial of sorts.


And provide plenty of doc strings so that we can auto generate as much 
as possible. Rowland has sent me a copy of his code to parse spec.py and 
  generate documentation so there is no reason why we can't expand that 
to  document the framework and/or our developer application as well. 
With studious tweaking (and the borrowing of ideas from some of the 
other documentation projects) we can minimise our documentation as much 
as possible.

> 
> 5. Repeat for the next app until PythonCard is perfect.
> 
> How does this idea grab everyone else? Good, bad, indifferent?
> 


I like it, let development commence.

> ---
> Patrick K. O'Brien
> Orbtech
> "I am, therefore I think."
> 


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

RE: [Pythoncard-users] Re: hoping for more input

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

Thanks for the comments!

> From: Rodney Somerstein
>
> Message watcher functionality is definitely useful. I think that in
> general, the command line should be hidden as much as possible from the
> user in PythonCard. Being able to bring one up only as needed is
> definitely
> useful, though.

Originally, the idea of the shell was to give us a HyperCard-like message
box, but multi-line. Once Patrick had PyCrust working it made sense to
utilize all the power available. It is extremely common for even new Python
programmers to use a Python shell, so I don't feel it is a bad thing to have
a full shell rather than a simplistic input/output mechanism like the
HyperCard msg box. An important distinction right now is that the shell is
only available if one or more of the "Debug" windows is requested at
startup. In the future, the framework could be changed so that those windows
could be invoked later.

It is important to not confuse the shell with working from the command-line
prompt of MS-DOS or Unix, also referred to as shells. You might start a
PythonCard program Windows 2000 as:

  C:\python\PythonCardPrototype>samples\proof\proof -s

or Windows 98

  C:\python\PythonCardPrototype>c:\python21\python samples\proof\proof.py -s

but all the other interaction would be from the runtime "Shell". If you look
at the turtle and resourceEditor samples, you'll see the trick at the bottom
for having an app invoke a Debug window like the shell regardless of the
pythoncard.config.py, pythoncard.user.config.py, or command-line option.

    # now force the shell to be enabled
    PythonCardPrototype.config.Configuration().setOption('showShell', 1)

> I actually think that dependence on the command line is one of Python's
> weaknesses. It makes things easier when launching from Unix. But, it is
> much harder for users to follow if they are used to Windows or Mac OS.
> Given this, PythonCard should be a double-clickable application
> that can be
> launched easily by a user and then let them create applications easily
> using PythonCard as the scripting language. If someone has to start the
> whole Python environment to run their applications, you will lose many
> potential new users.

If the association has been made between the file extensions (.py, .pyw) and
the python executables, then you can open an application in Windows using
the Explorer and just double-clicking. This should be the default with your
installation. I don't know the variations under Unix, but I'm pretty sure
you can do something similar (help me out here Unix folks). There are two
distinct flavors of Python on the Mac right now that are being merged. One
is more of a Mac classic environment and the other is more like Unix. In
both cases, I believe a script can be launched by double-clicking, but again
I'm not using the Mac these days, so somebody else will need to
confirm/correct me.

> Similar to the above, PythonCard needs to provide a way to deliver easily
> launchable and distributable applications. If it doesn't compile
> to Java or
> some other language, then there needs to be really good documentation
> describing how to create a standalone application on each supported
> platform. It isn't sufficient to expect the user to figure out
> how to do it
> on their own.

Having a standalone installation for a PythonCard application that doesn't
require the user to already have Python, the wxPython, PythonCard, and
PyCrust packages is not a simple problem to solve. This is probably doable
using py2exe under Windows, but nobody has tried yet that I know of. It is
more complicated under Unix and the Mac, but there are possibilities. One
suggestion for the app itself is that we use a zip bundle similar to a Java
.jar/.war file to package up all scripts, resource files, sounds, images,
etc. into one file. With the write header, this could be double-clickable.
We probably won't explore these issues until much later in the project
cycle.

Once we figure out how to do it, automating the process shouldn't be a big
deal.

ka

[Pythoncard-users] a wxPython example

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

When the framework was started we had the stated goal of hiding all of
wxPython, partially because we thought we might want to eventually sit on
top of other GUI toolkits. The code and discussion below explores what
user/programmer code might look like if we weren't using dot notation or
class wrappers for wxPython widgets.

First of all, PythonCard widgets/components use a unique alphanumeric name
to uniquely identify each widget. I really like this aspect of what we have
today since dictionaries and lists are fundamental to Python, you can skip
using numeric identifiers entirely. A widget in wxPython terms is a control.
wxPython already supports setting the name of a control directly, so it is
possible to reference a particular control just by using its name in many
cases. widget.py in the prototype framework sets the name as part of
initialization as shown by this code fragment for the TextField class from
widget.py:

        delegate = wxTextCtrl(
            aParent._getDelegate(),
            self.getId(),
            aResource.text,
            wxPoint( aResource.position[ 0 ], aResource.position[ 1 ] ),
            wxSize( aResource.size[ 0 ], aResource.size[ 1 ] ),
            style = borderStyle | wxCLIP_SIBLINGS,
            name = aResource.name )


If you run the proof sample with the shell, you can see the name and class
info of the underlying wxPython controls. A background in PythonCard
contains a Panel class (wxPanel) which contains all the widgets/controls.
Thus the wxPython methods can be used with the panel as the following
example shows.

>>> bg = pcapp.getCurrentBackground()
>>> comp = bg.components
>>> children = bg.panel.GetChildren()
>>> for c in children:
...     print c.GetName(), c.__class__.__name__, c.GetClassName()
...
field1 wxTextCtrlPtr wxTextCtrl
field2 wxTextCtrlPtr wxTextCtrl
button1 wxButtonPtr wxButton
  ...and so on...

There is already a method to find windows by name and since wxTextCtrl is
derived from a wxWindow and wxControl, you can do:

>>> f = bg.panel.FindWindowByName('field1')
>>> f.GetName(), f.GetClassName()
('field1', 'wxTextCtrl')

That means a lot of the work currently done by the WidgetDict class could
probably be done by just using a helper method to look up the name or id of
a wxPython control or just use the built-in wxPython method. The event
dispatch should still work as well. The framework simply needs to be changed
to bind/dispatch using wxPython controls instead of wrapped
widgets/controls.

The handler lookup could be changed to start from the control itself or its
immediate parent and then work up the chain until it gets to the app. Right
now the lookup starts with the background.

The framework we have today supports dot notation for all widget attributes
and the components dictionary. In general, an attribute such as 'text' maps
directly to _get/_set methods such as _getText/_setText. Here are the actual
methods from the TextField class.

    def _setText( self, aString ) :
        """Sets the text value and marks the widget as not-modified.
        aString may contain newline characters if the text widget is
multi-line."""
        self._getDelegate().SetValue( aString )

    def _getText( self ) :
        """Gets the contents of the widget. Notice that for a multiline text
        widget, the lines will be separated by (Unix-style) \\n characters,
        even under Windows where they are separated by a \\r\\n sequence in
        the native control."""
        return self._getDelegate().GetValue()

As you can see, these methods just turn around and call wxPython methods.
There are more complicated _get/_set examples, but quite a few are as simple
as this. The other thing that is going on here is an attempt to use more
consistent names. wxPython sometimes uses GetValue/SetValue and other times
has GetLabel/SetLabel. wxStaticBitmap uses GetBitmap/SetBitmap, but
wxBitmapButton uses GetBitmapLabel/SetBitmapLabel. PythonCard certainly has
its own problems, but we were attempting to fix some naming issues when we
came up with the attribute names.

So, what would getting and setting an attribute look like without dot
notation and using wxPython directly? 'panel' below might need to be another
FindWindowByName() call, but maybe the code would look something like this:

  self.panel.FindWindowByName('field1').SetValue('hello world')
  txt = self.panel.FindWindowByName('field1').GetValue()

compare that to what we currently do:

  self.components.field1.text = 'hello world'
  txt = self.components.field1.text

Somewhere between the two extremes is probably the right answer. It would be
possible to put a dot notation layer directly on top of wxPython by
providing a dictionary of attribute names and then the methods for that
attribute.

  {'text':['GetValue', 'SetValue']}

Some variation like that.

ka