pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] Message Watcher fix - repost

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

On Wed, 2 Jan 2002 12:56:16 -0800
"Kevin Altis" <al...@se...> wrote:


> Ignore the original code, it was bad. This is checked into cvs.
> 

Works fine.  As I mentioned to you earlier, there is still the occasional
scroll to the top (I don't know why Freeze/Thaw don't prevent this), but
it's infrequent and fast so it looks to be a non-issue.

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

RE: [Pythoncard-users] Message Watcher fix - repost

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

Argh, it is going to be one of those days. Laggy email and accidentally
hitting send before finishing a message....

Ignore the original code, it was bad. This is checked into cvs.

        if used or (not self.hideUnused.GetValue()):
            if self.msgHistory.GetLastPosition() > 29000:
                self.msgHistory.Freeze()
                # delete many lines at once to reduce overhead
                text = self.msgHistory.GetValue()
                self.msgHistory.SetValue(text[text.index('\n', 3000) + 1:])
                self.msgHistory.AppendText(eventText)
                self.msgHistory.Thaw()
            else:
                self.msgHistory.AppendText(eventText)

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Wednesday, January 02, 2002 12:02 PM
> To: pyt...@li...
> Subject: RE: [Pythoncard-users] Message Watcher fix
>
>
> > From: Cliff Wells
> >
> > It seems to work okay, up until the point that it tries to
> delete the old
> > messages, then the message window scrolls wildly up and down for a while
> > (it seems that maybe deleting the first message causes a scroll
> to the top
> > of the list, then it scrolls back to the end, then back to the top,
> > etc...).  Is there a way to lock the list until the deletes are done?
>
> Okay, let's try some new wxWindows methods, Freeze and Thaw and
> see if they
> help.
>
>         if used or (not self.hideUnused.GetValue()):
>             self.msgHistory.Freeze()
>             while self.msgHistory.GetLastPosition() > 29000:
>                 # delete first line of history
>                 self.msgHistory.Remove(0, self.msgHistory.XYToPosition(0,
> 1))
>             self.msgHistory.Thaw()
>             self.msgHistory.AppendText(eventText)
>
> > It doesn't seem to mangle the first message though =)
>
> Bonus
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

RE: [Pythoncard-users] Message Watcher fix

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

Ignore the original code, it was bad. This is checked into cvs.


> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Wednesday, January 02, 2002 12:02 PM
> To: pyt...@li...
> Subject: RE: [Pythoncard-users] Message Watcher fix
>
>
> > From: Cliff Wells
> >
> > It seems to work okay, up until the point that it tries to
> delete the old
> > messages, then the message window scrolls wildly up and down for a while
> > (it seems that maybe deleting the first message causes a scroll
> to the top
> > of the list, then it scrolls back to the end, then back to the top,
> > etc...).  Is there a way to lock the list until the deletes are done?
>
> Okay, let's try some new wxWindows methods, Freeze and Thaw and
> see if they
> help.
>
>         if used or (not self.hideUnused.GetValue()):
>             self.msgHistory.Freeze()
>             while self.msgHistory.GetLastPosition() > 29000:
>                 # delete first line of history
>                 self.msgHistory.Remove(0, self.msgHistory.XYToPosition(0,
> 1))
>             self.msgHistory.Thaw()
>             self.msgHistory.AppendText(eventText)
>
> > It doesn't seem to mangle the first message though =)
>
> Bonus
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] Message Watcher fix

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

On Wed, 2 Jan 2002 12:01:46 -0800
"Kevin Altis" <al...@se...> wrote:
> 
> Okay, let's try some new wxWindows methods, Freeze and Thaw and see if
they
> help.
> 
>         if used or (not self.hideUnused.GetValue()):
>             self.msgHistory.Freeze()
>             while self.msgHistory.GetLastPosition() > 29000:
>                 # delete first line of history
>                 self.msgHistory.Remove(0, self.msgHistory.XYToPosition(0,
> 1))
>             self.msgHistory.Thaw()
>             self.msgHistory.AppendText(eventText)

Calling Freeze/Thaw for every message slows it down too much, try this
instead:


        if used or (not self.hideUnused.GetValue()):
            while self.msgHistory.GetLastPosition() > 29000:
                self.msgHistory.Freeze()
                # delete first line of history
                #print self.msgHistory.GetLineLength(0),
self.msgHistory.XYToPosition(0, 1)
                self.msgHistory.Remove(0, self.msgHistory.XYToPosition(0,
1))
                self.msgHistory.Thaw()

            self.msgHistory.AppendText(eventText)
            #print self.msgHistory.GetLastPosition()

This way they're only called when deleting from the list.  BTW, yes this
seems to fix it.


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

RE: [Pythoncard-users] Message Watcher fix

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

> From: Cliff Wells
>
> It seems to work okay, up until the point that it tries to delete the old
> messages, then the message window scrolls wildly up and down for a while
> (it seems that maybe deleting the first message causes a scroll to the top
> of the list, then it scrolls back to the end, then back to the top,
> etc...).  Is there a way to lock the list until the deletes are done?

Okay, let's try some new wxWindows methods, Freeze and Thaw and see if they
help.

        if used or (not self.hideUnused.GetValue()):
            self.msgHistory.Freeze()
            while self.msgHistory.GetLastPosition() > 29000:
                # delete first line of history
                self.msgHistory.Remove(0, self.msgHistory.XYToPosition(0,
1))
            self.msgHistory.Thaw()
            self.msgHistory.AppendText(eventText)

> It doesn't seem to mangle the first message though =)

Bonus

ka

Re: [Pythoncard-users] Message Watcher fix

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

On Wed, 2 Jan 2002 11:17:15 -0800
"Kevin Altis" <al...@se...> wrote:

> I updated the Message Watcher in cvs so that when the list starts to get
> full it deletes the oldest messages in the list.
> 
> The history list doesn't use the wxTE_RICH style, so the current change
> (line 117 of debug.py) may have a 1-off error under Linux due to
differences
> in line ending handling between Windows and Linux. There are some
additional
> problems with using wxTE_RICH, so if someone can check whether the code
> mangles the first line of the history list under Linux I would appreciate
> it.
> 
> The simplest way to get a lot of content in the Message Watcher is to
open
> up a sample and uncheck hide unused messages and then just move the mouse
> around inside a widget generating a lot of mouseMove messages.
> 

It seems to work okay, up until the point that it tries to delete the old
messages, then the message window scrolls wildly up and down for a while
(it seems that maybe deleting the first message causes a scroll to the top
of the list, then it scrolls back to the end, then back to the top,
etc...).  Is there a way to lock the list until the deletes are done?

It doesn't seem to mangle the first message though =)

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

[Pythoncard-users] AppleScript Studio online book

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

Here is another good place to get ideas for the PythonCard layout editor and
IDE we'll eventually create (lots of pictures :-). This is sort of a
replacement for HyperCard in the Apple world, so it is probably pretty easy
to use.

Building Applications With AppleScript Studio
http://developer.apple.com/techpubs/macosx/CoreTechnologies/AppleScriptStudi
o/applescriptstudio/index.html

AppleScript Studio is part of OS X 10.2. There is some more info at
  http://db.tidbits.com/getbits.acgi?tbart=06667

Tell me what you like and don't like about what you see.

ka

[Pythoncard-users] Message Watcher fix

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

I updated the Message Watcher in cvs so that when the list starts to get
full it deletes the oldest messages in the list.

The history list doesn't use the wxTE_RICH style, so the current change
(line 117 of debug.py) may have a 1-off error under Linux due to differences
in line ending handling between Windows and Linux. There are some additional
problems with using wxTE_RICH, so if someone can check whether the code
mangles the first line of the history list under Linux I would appreciate
it.

The simplest way to get a lot of content in the Message Watcher is to open
up a sample and uncheck hide unused messages and then just move the mouse
around inside a widget generating a lot of mouseMove messages.

ka

Re: [Pythoncard-users] Linux fixes

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

On Tue, 1 Jan 2002 18:46:24 -0800
"Kevin Altis" <al...@se...> wrote:
> today. I guess Linux users just assumed I wrote bad code on purpose and
> didn't report the problems to the list before now ;-) Anyway, a big new
> years thanks to Cliff!

Linux users assume _everyone_ else writes bad code ;-)

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

[Pythoncard-users] HtmlWindows supported HTML tags

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

I copied this list from the latest docs. I don't know when the docs were
last updated, so the current wxWindows sources might actually support more
than the tags below, but it is unlikely that wxHtmlWindow supports less. I
would say the tags below are safe to use.

ka
---
Tags supported by wxHTML
wxHTML is not full implementation of HTML standard. Instead, it supports
most common tags so that it is possible to display simple HTML documents
with it. (For example it works fine with pages created in Netscape Composer
or generated by tex2rtf).

Following tables list all tags known to wxHTML, together with supported
parameters. A tag has general form of <tagname param_1 param_2 ... param_n>
where param_i is either paramname="paramvalue" or paramname=paramvalue -
these two are equivalent. Unless stated otherwise, wxHTML is
case-insensitive.

Table of common parameter values

We will use these substitutions in tags descriptions:


[alignment]     CENTER
                LEFT
                RIGHT
                JUSTIFY

[v_alignment]   TOP
                BOTTOM
                CENTER

[color]         #nnnnnn
                where n is hexadecimal digit

[fontsize]      -2
                -1
                +0
                +1
                +2
                +3
                +4
                 1
                 2
                 3
                 4
                 5
                 6
                 7

[pixels]        integer value that represents dimension in pixels

[percent]       i%
                where i is integer

[url]           an URL

[string]        text string

[coords]        c(1),c(2),c(3),...,c(n)
                where c(i) is integer


List of supported tags

P               ALIGN=[alignment]

BR              ALIGN=[alignment]

DIV             ALIGN=[alignment]

CENTER

BLOCKQUOTE

TITLE

BODY            TEXT=[color]
                LINK=[color]
                BGCOLOR=[color]

HR              ALIGN=[alignment]
                SIZE=[pixels]
                WIDTH=[percent]
                WIDTH=[pixels]

FONT            COLOR=[color]
                SIZE=[fontsize]
        FACE=[comma-separated list of facenames]

U

B

I

EM

STRONG

CITE

ADDRESS

CODE

KBD

SAMP

TT

H1

H2

H3

H4

H5

H6

A               NAME=[string]
                HREF=[url]

PRE

LI

UL

OL

DL

DT

DD

TABLE           ALIGN=[alignment]
                WIDTH=[percent]
                WIDTH=[pixels]
                BORDER=[pixels]
                VALIGN=[v_alignment]
                BGCOLOR=[color]
                CELLSPACING=[pixels]
                CELLPADDING=[pixels]

TR              ALIGN=[alignment]
                VALIGN=[v_alignment]
                BGCOLOR=[color]

TH              ALIGN=[alignment]
                VALIGN=[v_alignment]
                BGCOLOR=[color]
                WIDTH=[percent]
                WIDTH=[pixels]
                COLSPAN=[pixels]
                ROWSPAN=[pixels]

TD              ALIGN=[alignment]
                VALIGN=[v_alignment]
                BGCOLOR=[color]
                WIDTH=[percent]
                WIDTH=[pixels]
                COLSPAN=[pixels]
                ROWSPAN=[pixels]

IMG             SRC=[url]
                WIDTH=[pixels]
                HEIGHT=[pixels]
                ALIGN=TEXTTOP
                ALIGN=CENTER
                ALIGN=ABSCENTER
                ALIGN=BOTTOM
                USEMAP=[url]

MAP             NAME=[string]

AREA            SHAPE=POLY
                SHAPE=CIRCLE
                SHAPE=RECT
                COORDS=[coords]
                HREF=[url]

META            HTTP-EQUIV="Content-Type"
                CONTENT=[string]

[Pythoncard-users] Linux fixes

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

Cliff Wells helped fix some long-standing Linux issues with PythonCard
today. I guess Linux users just assumed I wrote bad code on purpose and
didn't report the problems to the list before now ;-) Anyway, a big new
years thanks to Cliff!

I've updated the file launching code in findfiles.py, samples.py and
resourceEditor.py. sys.executable is used so that the same version of Python
that you started those samples with will be used to launch any Python
scripts.

findfiles.py should now do grep searches correctly since it no longer
mangles directory paths with lower().

I'm still looking into the widget drag and resize problem in the
resourceEditor and hope to have some answers from the wx-dev mailing list in
the next few days.

ka

[Pythoncard-users] HtmlWindow component and simpleBrowser sample

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

I've added an HtmlWindow component and simpleBrowser sample to test the
HtmlWindow component. I do not know how this component will evolve in
PythonCard because it seems to be in flux in wxWindows and its main purpose
seems to be to support Windows-style Help files. I'm adding HtmlWindow, so
that we can at least experiment with it. The component doesn't support
normal event bindings for OnLinkClicked, OnCellMouseHover, etc. so we will
have to fabricate our own virtual events depending once again on how
wxHtmlWindow changes in wxWindows.

I did not add HtmlWindow to the resourceEditor and don't plan to until the
future of the component is clearer.

ka
---
from the readme.txt:
simpleBrowser is not designed to be a full web browser.

The default URL is set to http://diveintopython.org/toc.html, but you can
change that in the resource file.

Due to limitations in HtmlWindow and the underlying wxHtmlWindow class, both
the HtmlWindow component and the simpleBrowser sample are likely to change a
great deal between releases. wxHtmlWindow does not have event bindings, nor
can you select the text in the control.

As of wxPython 2.3.2.1, the underlying wxHtmlWindow class does not send a
Host: header to web servers, so servers expecting a full HTTP/1.1 request
will generally return an error page. This includes almost all Apache
servers, including SourceForge. The next version of wxHtmlWindow and
wxPython should fix this problem so that the control works with more
servers.

I recommend working with HTML files on your local system to avoid HTTP
server issues.

The control does not support frames, JavaScript, and many other more
advanced HTML features. Just try it with files on your local system to see
what does and doesn't work. I think that it does give us a very simple way
to do non-editable styled text with embedded images, tables, etc. and this
is the area I would like to explore. It is not going to give us the power of
Mozilla or the Internet Explorer ActiveX control.

The underlying wxHtmlWindow control does support embedding other wxWindows
classes in HTML and while this is fairly advanced, it is also very powerful.
See the wxPython demo.py for an example. We should keep this in mind as the
framework progresses.

See the wxWindows/wxPython help file for more info on HTML classes.

RE: [Pythoncard-users] Control Points don't allow resizing in resourceEditor

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

> > Hmm, they work under Windows 2000 and Windows 98 and I haven't really
>
> It works for me under Win2000 as well.
> Actually, I noticed that they didn't work in 0.53 (under Linux)
> either, but
> I didn't report it as I knew you were releasing a new version.

Argh.

> > changed the algorithms that much. Do you get any errors in the console
> when
> > the resourceEditor starts up? If so, failed initialization
> could screw up
> > everything else. Open the Message Watcher window and see if any messages
> are
> > firing.
> >
>
> There are no errors upon startup.  The message watcher shows mouse events
> for entering, leaving, and mousedown in bottomRight, but when it receives
> the mouseDown event, it causes the control points to disappear as if the
> control is no longer selected.

The resizing handles are supposed to disappear until the mouse is released.
As the mouse is dragged the control is supposed to resize. This could very
well be a GTK issue, but nobody else has reported it. Then again, nobody
reported the addresses sample startup problem either.

So, is everyone running Linux seeing the same problem? I don't run Linux, so
the only way I'll ever know about problems is if people report them (thanks
Cliff).

The resizing handles work the way they do partly because I was trying to get
around a problem Rowland mentioned a long time ago with the experimental
resizing code in the widgets sample. If you open that up, you can hold down
the control key when you mouseDown on a widget and depending on where you
mouseDown inside the control you can move or resize it. Works fine under
Windows, but it never worked right under Linux.

ka

Re: [Pythoncard-users] Control Points don't allow resizing in resourceEditor

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

On Mon, 31 Dec 2001 17:18:44 -0800
"Kevin Altis" <al...@se...> wrote:

> Hmm, they work under Windows 2000 and Windows 98 and I haven't really

It works for me under Win2000 as well.
Actually, I noticed that they didn't work in 0.53 (under Linux) either, but
I didn't report it as I knew you were releasing a new version.  

> changed the algorithms that much. Do you get any errors in the console
when
> the resourceEditor starts up? If so, failed initialization could screw up
> everything else. Open the Message Watcher window and see if any messages
are
> firing.
> 

There are no errors upon startup.  The message watcher shows mouse events
for entering, leaving, and mousedown in bottomRight, but when it receives
the mouseDown event, it causes the control points to disappear as if the
control is no longer selected.

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

RE: [Pythoncard-users] Control Points don't allow resizing in resourceEditor

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

> I just downloaded PythonCard 0.61 from SF so I could play with the
> resourceEditor.  However, I notice that the control points don't appear
> functional (resizing doesn't work).
>
> Python 2.1.1, wxPython 2.3.2.1 on RH Linux 7.1.

Hmm, they work under Windows 2000 and Windows 98 and I haven't really
changed the algorithms that much. Do you get any errors in the console when
the resourceEditor starts up? If so, failed initialization could screw up
everything else. Open the Message Watcher window and see if any messages are
firing.

ka

[Pythoncard-users] Control Points don't allow resizing in resourceEditor

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

Kevin,

I just downloaded PythonCard 0.61 from SF so I could play with the
resourceEditor.  However, I notice that the control points don't appear
functional (resizing doesn't work). 

Python 2.1.1, wxPython 2.3.2.1 on RH Linux 7.1. 

Regards,

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

[Pythoncard-users] dumb addresses.py bug

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

This has been around forever but I never tried running the app on a box that
didn't have Outlook installed, so of course I missed this stupid typo.
Surely somebody must have run addresses.py on Linux before and noticed it
didn't work. Oh well, it is fixed in cvs.

        if disableOutlook:
            self.menuBar.enable('menuFileImportOutlook', 0)

should be

        if disableOutlook:
            self.menuBar.setEnabled('menuFileImportOutlook', 0)

ka

[Pythoncard-users] tentative multi-window success

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

I was playing around tonight and decided to try an experiment. I duplicated
the minimal directory and renamed it to 'multiwindow', then I copied the
doodle.py and doodle.rsrc.py sample files into the 'multiwindow' directory.
I added some imports to the minimal.py source file and an openBackground
handler to load the resource file for doodle and code to create another
background window. The source is below. Absolutely no changes were made to
the doodle files.

Get this, it worked the first time! The minimal window came up along with
the doodle window and all the events worked fine. Exiting is a problem
because the doodle window was not really a child of the minimal window, so
both windows have to be closed separately, but I know how to fix that. I
love being surprised.

There are a number of places where the Background class needs to be tweaked
and of course there are other issues, especially with the runtime debug
windows, but it looks very promising. So just imagine that any 'background'
can easily be used as part of your own program. Not a bad way to start the
new year.

We're more or less already doing this kind of thing with the GenericDialog
windows and it makes me think that perhaps it might be better if each
background resource was put in its own file. We also need to move the
menubar as an attribute of the background instead of the stack, but that's
another easy change.

I just want to say that Rowland Smith's original framework is still pretty
excellent kung fu! Kudos to Robin Dunn as well for wxPython and his other
contributions as well as everyone else on the mailing list that has helped
get PythonCard this far. This is so cool.

Happy New Year,

ka
---

from PythonCardPrototype import model, res
import doodle

class Minimal(model.Background):
    def on_openBackground(self, target, event):
        rsrc = res.ResourceFile('doodle.rsrc.py').getResource()
        self.doodleWindow = doodle.Doodle(self.stack,
                                          -1,
                                          rsrc,
                                          rsrc.stack.backgrounds[0])
        self.doodleWindow.Show()

    def on_menuFileExit_select(self, menu, event):
        self.Close()

if __name__ == '__main__':
    app = model.PythonCardApp(Minimal)
    app.MainLoop()

[Pythoncard-users] resourceEditor attribute limitations

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

Until the resourceEditor has its own property editor - it currently uses the
runtime Property Editor (PE) - the following component (widget) attributes
can't be edited:

  name, alignment, layout, style, border

The reason you can't edit these attributes at runtime is that they can only
be set during initialization of a component; this is partly a wxPython
limitation. If the resourceEditor allowed these to be changed, it would have
to remove the component and then recreate it, which is not something you
would want to happen for all programs.

The PE is not set up to allow backgrounds or components to be "listeners"
for changes made in the PE and none of the widget attribute set methods are
designed to notify listeners of changes. If we want to support notification
on any _set (dot notation usage) or set method call we should discuss the
pros and cons.

At some point, the resourceEditor will have its own PE window which can
handle all the duties of creation, deletion, reordering the components and
so on. Until then, I'm afraid changes to the attributes above still require
editing the .rsrc.py file by hand. My apologies for this limitation.
Improving the resourceEditor is one of my top priorities, so I expect this
limitation to go away in the next month or so.

I just fixed a long-standing bug in the PE, which wasn't showing the
alignment attribute for StaticText components. While fixing the bug I
realized that the non-editable attributes limitation probably wasn't clear
to anyone except myself.

ka

[Pythoncard-users] Re: Thinking in Python - BoxObserver issues

[Bruce E. <Br...@Ec...>]

>2. Threads and interaction with the main event loop
>     There are no thread examples in PythonCard, perhaps we
>       should adapt an example from
>       http://wiki.wxpython.org/index.cgi/wxPython_20Cookbook

Or you could just adapt the "ColorBoxes.java" example from
"Thinking in Java".

Since there doesn't seem to be a lot of coverage of Python threads
anywhere, I've thought of adding a chapter on that in "Thinking in
Python."

Note also that ColorBoxes.java is designed to show threads, whereas
BoxObserver is only designed to show the observer pattern, and
doesn't have any threading in it. The common feature between both
of them is that they use a grid of colored boxes.


Most current information can be found at:
http://www.mindview.net/Etc/notes.html
===================
Bruce Eckel    http://www.BruceEckel.com
Contains free electronic books: "Thinking in Java 2e" & "Thinking
in C++ 2e"
Please subscribe to my free newsletter -- just send any email to:
joi...@ea...
My schedule can be found at:
http://www.mindview.net/Calendar
===================

[Pythoncard-users] Thinking in Python - BoxObserver issues

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

As I mentioned yesterday, I've been emailing back and forth with Bruce Eckel
about patterns, Python, and PythonCard. Bruce is working on a new book
called Thinking in Python. You can find out more about the book and download
the current version here:

http://www.mindview.net/Books/TIPython

Bruce asked me about how I would do the BoxObserver example in Sect11.htm
which is supposed to be a visual example of observers. I ended up writing a
version in PythonCard that didn't deal with threads or the Observer pattern,
but did solve the problem of clicking on a square in a grid and changing the
color of each neighbor to the same color as the square clicked. That code is
at the end of this message as well as Sect11.htm of Thinking in Python,
Revision 0.1.1

When I was writing the code a lot of issues came up, some of which we've
discussed before and some that we haven't but will need to address as the
framework progresses. The original ColorBoxes example was from Chapter 14 in
Thinking in Java, 2nd Edition. It showed off threads and used the Java
GridLayout sizer mechanism, so those became part of the issue list. The list
is below and we can use it as a starting point for further discussion. If
you would like to revise the source code and use the Observer pattern to
solve the problem, that can replace my code in the book.

ISSUES

1. Model View Controller versus direct manipulation
     The code could be written so that the GUI is just a visualization
       of underlying classes I think, but there is very little MVC in
       PythonCard user code right now. It is more like doing VB.

2. Threads and interaction with the main event loop
     There are no thread examples in PythonCard, perhaps we
       should adapt an example from
       http://wiki.wxpython.org/index.cgi/wxPython_20Cookbook

3. subclasses of standard widgets
   a. using standard widgets/components as delegates in
      user-defined classes

4. event binding to a class other than the parent
     we probably need this for compound components and more flexible
     programming when the user/programmer doesn't want the framework
     automatically binding events

5. default resource file and PythonCard apps that don't have
     a user-defined resource file.

6. fixed layouts and "sizers"
     wxPython has a variety of sizer and constraint mechanisms, but none
       of them are wrapped in PythonCard. The samples that use sizers, put
       the sizer initialization in the openBackground handler; it isn't
       very elegant.

7. can the existing notifyEventListeners method of EventSource be
     used as is for notifying observers for something other than
     native events?
     Widget (widget.py) subclasses Component (pom.py),
     which subclasses EventSource (event.py)
     how about when we refactor the framework?

The code below does not use much OOP programming or implement the Observable
pattern, which was the original intent of the BoxObserver.py code. It is
simply
a starting place.

I did not use sizers since that will just make the code more confusing
initially.

ka
---

boxobserver.py:

from PythonCardPrototype import log, model
import random

GRID = 8

class ColorBoxesTest(model.Background):

    def on_openBackground(self, target, event):
        self.document = []
        for row in range(GRID):
            line = []
            for column in range(GRID):
                line.append(self.createBox(row, column))
            self.document.append(line[:])

    def createBox(self, row, column):
        colors = ['black', 'blue', 'cyan',
        'darkGray', 'gray', 'green',
        'lightGray', 'magenta',
        'orange', 'pink', 'red',
        'white', 'yellow']

        width, height = self.panel.GetSizeTuple()
        boxWidth = width / GRID
        boxHeight = height / GRID

        log.info("width:" + str(width) + " height:" + str(height))
        log.info("boxWidth:" + str(boxWidth) + " boxHeight:" +
str(boxHeight))

        # use an empty image,
        # though some other widgets would work just as well
        boxDesc = {'type':'Image', 'size':(boxWidth, boxHeight), 'file':''}
        name = 'box-%d-%d' % (row, column)
        # there is probably a 1 off error in the calculation below
        # since the boxes should probably have a slightly different
        # offset to prevent overlaps
        boxDesc['position'] = (column * boxWidth, row * boxHeight)
        boxDesc['name'] = name
        boxDesc['backgroundColor'] = random.choice(colors)
        self.components[name] =  boxDesc

        return self.components[name]

    def changeNeighbors(self, row, column, color):
        # this algorithm will result in changing the color of some
        # boxes more than once, so an OOP solution where only
        # neighbors are asked to change or boxes check to see if they
        # are neighbors before changing would be better per the original
        # example
        # does the whole grid need to change its state at once like in
        # a Life program?
        # should the color change result in the propogation of another
        # notification event?
        for r in range(max(0, row - 1), min(GRID, row + 2)):
            for c in range(max(0, column - 1), min(GRID, column + 2)):
                self.document[r][c].backgroundColor = color

    # this is a background handler, so it isn't specific to a single
    # widget
    # Image widgets don't have a mouseClick event (wxCommandEvent in
wxPython)
    def on_mouseUp(self, target, event):
        prefix, row, column = target.name.split('-')
        self.changeNeighbors(int(row), int(column), target.backgroundColor)

if __name__ == '__main__':
    app = model.PythonCardApp(ColorBoxesTest)
    app.MainLoop()



boxobserver.rsrc.py:

{'stack':{'type':'Stack',
          'name':'BoxObserver',
    'backgrounds': [
    {'type':'Background',
         'name':'bgBoxObserver',
          'title':'Demonstrates Observer pattern',
          'position':(5, 5),
          'size':(500, 400),

         'components': [

] # end components
} # end background
] # end backgrounds
} }

[Pythoncard-users] Call for a small program - willing to give a bonus (fwd)

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

---------- Forwarded message ----------
Date: Sun, 30 Dec 2001 15:15:34 +0100
From: Tom Karas <Tom...@ht...>
To: pyt...@py...
Newsgroups: comp.lang.python, comp.lang.pascal.delphi.misc, comp.lang.ruby,
    comp.lang.java.programmer, borland.public.kylix.non-technical
Followup-To: comp.lang.python
Subject: Call for a small program - willing to give a bonus

Hello out there.

Because of several mails, that my original posting and even the second
posting
on the same thread could not be found i decided to post my first posting
again.
I set a followup-to comp.lang.python so you will find any answers there.

Sorry for any inconvenience.

<quote>
Hello out there,
  who wants to practice his skills and make the start of a language
learn
software.

The reason: AFAIK there are just a few - if any - language learn
programs under a GPL or FreeBSD-Style Licenses available - which could
be run under linux and windows.

I am learning spanish in an exchange with a mexican who learns german
right now - and i bought several programs for windows - but none of them
fulfill what a good learn software IMHO should do.

One of the things that are often missing: presentation of a verb in
different forms plus a few different examples:
   the verb to be:
I am in the pool.                     Ich bin im Pool.
You are cool.                         Du bist cool.
He is at the movies with his sister.  Er ist mit seiner Schwester im
Kino.

This is a quite simple example but i think this are the things one has
to
tackle at the beginning of learning a language

The KDE project - www.kde.org - noticed a couple of weeks ago that the
educational stuff under  kde was kind of lagging behind. Since then
there popped quite a few new programs out. But although the kde project
does a great job - the programs still can't be used under windows
( at least not without a big effort).

So i thought this is were python, java, ruby or even kylix/delphi  could
work. I do not know any of these languages but are willing to learn one
(probably python) so i am not able to write the program myself, but i
would help in maintenance stuff. (that would mean to type vocabulary in,
to make example sentences, maintain the web site )

</quote>


Later the program should also be able to play sound. I heard,
this could be difficult with python !?

So maybe Java would be a better bet ?

I am even willing to pay a little for the solution that fits some basic
needs,
but because i am a student this will be more like a little bonus.

For more details mail me:

Tom...@ht...

Best regards

Tom

-- 
Trust the computer industry to shorten the term "Year 2000" to Y2K.
It was this kind of thinking that got us in trouble in the first place.
Adrian Tyvand
-- 
http://mail.python.org/mailman/listinfo/python-list

[Pythoncard-users] updated favorites.py for searchexplorer

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

I added a PythonCard mailing list search to the searchexplorer favorites.py
file.


 'PythonCard mail list (ASPN)': {'pastSearches': ['documentation',
'sizers'],
                                 'postURL': '&type=Archive_PythonCard',
                                 'preURL':
'http://aspn.activestate.com/ASPN/search?query='},

You can download the updated file here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/samples/searchexplorer/favorites.py

And yes I still intend to add an edit dialog for the site list in the
searchexplorer.

ka

[Pythoncard-users] FW: playing around in PythonCard

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

I've been having an email exchange with Bruce Eckel about PythonCard. The
message below is applicable to just about everyone.

ka

-----Original Message-----
From: Kevin Altis [mailto:al...@se...]
Sent: Saturday, December 29, 2001 11:38 AM
To: Bruce Eckel
Subject: playing around in PythonCard


If and when you start to play I would suggest just running the
resourceEditor sample. Since the resourceEditor uses the Property Editor
window, all the other debug windows will also be loaded. Using the Debug
menu, select Shell, Message Watcher, etc. and move and resize the windows to
be on your screen the way you want them. If you don't want the debug windows
visible by default then go ahead and select them again in the Debug menu or
just click their close boxes. Now choose Save Configuration in the debug
menu. This will create a pythoncard_user_config.py file, so your debug
windows won't default to position (0, 0).

Since the resourceEditor loads the template.rsrc.py resource template by
default you will already have a working scratch pad to play around with in
the shell. For example you can select Add BitmapCanvas from the Component
menu. Give it a more meaningful name so the the text entry dialog looks
something like:

{'type':'BitmapCanvas', 'name':'canvas', 'position':(10, 10),
'size':(-1, -1), }

and then click OK. Now drag the handles to resize the canvas. Open up the
Shell window and type:

comp.

notice the command-completion window that pops up. type 'canvas' or select
from the menu. If you type

comp.canvas.

you'll see all the attributes and methods for the BitmapCanvas widget. Type
a few lines

>>> comp.canvas.foregroundColor = 'blue'
>>> comp.canvas.setFillColor('blue')
>>> comp.canvas.drawRect(10, 10, 100, 50)

Fun, no? You might want to use a BitmapCanvas to draw stuff rather than
using the Image widget... It is fairly primitive since I sort of slapped it
together in order to move the turtle.py module from a sample into the
framework itself and I needed a buffered bitmap for some other samples, but
it works for basic stuff and it does support all the main mouse events.

Patrick needs to better document all the shell commands, so this sounds like
a good time to bug him about it again. Nothing like calling the kettle black
:)

Ctrl+Shift+C will copy all the selected text in the shell, while Ctrl+C will
leave out the >>> stuff. If you arrow up to the beginning of a method and
press return it will copy the whole method/function so you can edit it. A
lot of things are like IDLE, a lot of things aren't.

Anyway, the Shell is one of the big pluses for experimenting and interactive
coding with something like PythonCard. You can add handlers dynamically too.

http://aspn.activestate.com/ASPN/Mail/Message/770015

ka
---

configuration = {
'defaultBackgroundPosition':(5, 5),
'enableLogging':0,
'logToStdout':1,
'logfile':'pythoncard.log',
'messageWatcherPosition':(900, 0),
'messageWatcherSize':(248, 320),
'messageWatcherVisible':1,
'namespacePosition':(52, 420),
'namespaceSize':(800, 300),
'namespaceVisible':1,
'propertyEditorPosition':(788, 322),
'propertyEditorSize':(360, 240),
'propertyEditorVisible':1,
'shellPosition':(50, 600),
'shellSize':(700, 230),
'shellVisible':1,
'showMessageWatcher':0,
'showNamespace':0,
'showPropertyEditor':0,
'showShell':0,
}

[Pythoncard-users] PythonCardPrototype release 0.6.1

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

I still haven't gotten any bug reports, so hopefully I won't need to do a
0.6.2 right away, but with all the little tweaks I won't be surprised if I
broke one thing while fixing something else.

ka
---

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

Remember to backup or just delete your old PythonCardPrototype directory
before installing a new version, so that the old files aren't still in the
package directory. As always, report any problems to the list.

Release 0.6.1 2001-12-28
changed all menu shortcuts from using - to + (Ctrl+F instead of Ctrl-F)
changed GetSize to GetSizeTuple and GetPosition to GetPositionTuple
  hopefully this has fixed the selection bugs in resourceEditor
  using size or position attributes as a list will now result in
    a runtime error
added New, Save, Revert to resourceEditor and documentChanged
fixed default resource file loading


Release 0.6 2001-12-27
*** wxPython 2.3.2 or later is now required to use PythonCard ***
added assert wxc.__version__ >= "2.3.2" to model.py
  the move to wxPython 2.3.2 fixes the menu accelerator bugs
*** resourceEditor sample is now a fully functional layout editor ***
updated resourceEditor
  added Run command, Run Options, and dialogs for editing the stack,
  background, and menu for an application
  added commands to change the component order
    component order is shown in the Property Editor
  added a grid option, so components can be aligned to the grid
  this isn't a commercial-quality layout editor since it still uses
    the runtime Property Editor to edit component (widget) properties,
    lacks extensive error checking and field validation and has
    many missing features and some oddball bugs, but overall it works
    well enough to do a fixed position layout quickly and easily
    and there is no Undo!
changed wxPython imports from
  from wxPython.wx import *
  to the more explicit
  from wxPython import wx
  added missing imports such as 'import types' where needed
replaced occurrences of wx.true and wx.false with 1 and 0
added a components directory
merged wxPython_binding.py into binding.py and moved widget-specific
  bindings to individual module files
moved spec.py descriptions for each widget to its respective widget
  module
split widget.py so each widget is in its own file in the components
  directory
  all widgets (components) are now self-contained modules in the
  components directory. each module includes the spec, event bindings,
  and attribute descriptions (formerly in spec.py) in addition to the
  widget class. when the module is imported it "registers" itself, so
  that the class is available for applications.
added drawPointList and drawLineList (2.3.2 feature) to the
  BitmapCanvas widget, switched to drawPointList in hopalong sample
  for a roughly 4x speed improvement
  also added Chaos1ScriptFastest.txt turtle script example
updated the setup.py script for minimal.py and provided some basic
  instructions in the readme.txt. It is necessary to uncomment the
  import in minimal.py prior to using py2exe due to how the dynamic
  imports are done for components
fixed _setFile bug in Image class
updated findfiles open/save code to automatically load and save
  the last grep parameters used to a 'findfiles.grep' file
updated log.py and config.py to use module-level functions in place
  of directly accessing the singleton classes from other modules
  log.info() instead of log.Log.getInstance().info() ...
  added logToStdout option to redirect log output to stdout
changed defaultStackPosition to defaultBackgroundPosition in
  pythoncard_config.py and pythoncard_user_config.py
moved title, position, size, statusBar, and icon attributes from
  the 'stack' to the 'background'
fixed alternative resource file loading
  added example of usage to SourceForgeTracker sample

ka