pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] added Find/Find Next to textIndexer sample

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

I want to have some generic Find and Find/Replace dialogs and find/replace
classes in PythonCard, so as the first step I added a Find/Find Next field
and buttons to the bottom of the textIndexer layout. The actual code that
does the work is shown below. There is quite a bit of code in common with
the three methods, but I didn't try and refactor the code, except where
on_doFind_command and on_doFindNext_command both use method findNext to
search the remaining cards in the stack if a match isn't found on the
current card. This is a brute force search, which is case-insensitive and
matches partial words. If someone with more search experience would like to
optimize the code, I encourage them to do so.

Because of the way textIndexer storage is organized via a separate ZODB
storage class, when a match is not made on the current card, the next card
in the stack is loaded and then the text from field1 is searched. This
additional i/o slows down the search, but since a refresh of field1 is not
done until after the search completes there isn't much feedback about what
was going on. Consequently, I added a StaticText field to display the
current card number, which does update as the card number changes.

You'll need to create at least a few cards and enter text on each to see the
find do its work.

I'm going to add a similar find to the addresses sample which will be
generalized a bit more, probably use a separate Find dialog window and
support searching of multiple fields. It will also search the dictionary
that holds the actual addresses data directly, which will make it closer to
the general find classes later on. I don't have a timeframe for the
addresses find code, I only finished up the code in textIndexer today
because of a post I made to the wx-users mailing list yesterday regarding a
problem with selections in wxTextCtrl.

ka
---
    def findNext(self, searchText):
        startCard = self.wstack._v_current_card
        numCards = len(self.wstack.card_list)-1

        # move to the next card and repeat the search until a match
        # or we come back to the card we started on
        doneSearching = 0
        while not doneSearching:
            if self.wstack._v_current_card == numCards:
                self.wstack.GoFirst()
            else:
                self.wstack.GoNext()

            if self.wstack._v_current_card == startCard:
                doneSearching = 1

            fieldText = self.components.field1.text.lower()
            offset = fieldText.find(searchText)
            if offset != -1:
                offset += fieldText.count('\n', 0, offset)
                self.components.field1.setSelection(offset, offset +
len(searchText))
                self.components.field1.setFocus()
                doneSearching = 1


    def on_doFind_command(self, target, event):
        searchText = self.components.fldFind.text.lower()
        fieldText = self.components.field1.text.lower()
        offset = fieldText.find(searchText)
        if offset != -1:
            # find apparently doesn't count newlines in its total
            offset += fieldText.count('\n', 0, offset)
            self.components.field1.setSelection(offset, offset +
len(searchText))
            self.components.field1.setFocus()
        else:
            self.findNext(searchText)

    def on_doFindNext_command(self, target, event):
        searchText = self.components.fldFind.text.lower()
        fieldText = self.components.field1.text.lower()

        selOffset = self.components.field1.getSelection()[1]
        offset = fieldText[selOffset:].find(searchText)

        if offset != -1:
            offset += selOffset
            offset += fieldText.count('\n', 0, offset)
            self.components.field1.setSelection(offset, offset +
len(searchText))
            self.components.field1.setFocus()
        else:
            self.findNext(searchText)

[Pythoncard-users] Worldclock fixed

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

All,

I've finally posted my fixes to the python version of the Worldclock 
sample to CVS. I've done some testing and the python code is now giving 
the same results as the javascript function.

Those who are living on the bleeding edge can try it out from now - any 
and all feedback is welcome. Those who are more cautious should be able 
to stop using the javascript code from the next release.

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can"

[Pythoncard-users] keyDown, keyUp, and keyPress events

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

Based on a recent discussion on the wx-dev mailing list, the addition of the
key handlers may cause a problem under wxGTK. There may be additional issues
with differences in key codes generated. Please report any issues you find
to the list.

The key events which were defined back in July and added to spec.py, never
got added to the TextField, PasswordField, and TextArea class event
bindings. There was a problem with passing the event on (wxPython
Event.Skip()) if the user code didn't process the event. Anyway, I want to
finally solve the issue, so I've checked in changes to:
  event.py, widget.py, and wxPython_binding.py

There will probably be a change to dispatch.py as well. The current changes
don't do much except allow the user code to handle the event and display the
event in the Message Watcher. I still need to add support for not passing on
the keyPress event, which will be necessary to limit the valid keystrokes
for a field. For example, if you only wanted a user to enter numbers you
would define a on_fieldName_keyPress handler that only called skip() when
the key code was 0 through 9.

The order of events:
  keyDown, keyPress, textUpdate, keyUp

Adding these events exposed some problems with the handling of tabs and the
return/enter key which I also need to investigate. However, it doesn't
appear that any of the samples have been broken by adding the key events. As
an example of handling each event, the following code could be added to
minimal.py:

    def on_field1_keyDown(self, target, event):
        print 'field1_keyDown'

    def on_field1_keyPress(self, target, event):
        print 'field1_keyPressed'
        #event.skip()

    def on_field1_keyUp(self, target, event):
        print 'field1_keyUp'

Note that the 'event.skip()' line commented out above will need to be
uncommented in the future or the keyPress handler above would keep the
characters from showing up in the field as user typed them.

In order to do anything with the event right now you need to get the native
wxPython event and then use wxPython methods.

    def on_field1_keyPress(self, target, event):
        print 'field1_keyPressed'
        nEvent = event.getNativeEvent()
        print nEvent.GetKeyCode()
        #event.skip()

See wxKeyEvent and the Keycodes topics in the wxWindows/wxPython
documentation for more info; I've included the Keycodes topic below. We'll
have to define our own method wrappers and keycode constants in order to
duplicate the wxPython functionality.

I am thinking about just duplicating the codes below, but using a KEY_
prefix instead of WXK_ prefix; the constants will be put in a separate
module file to make it easy to reference them. I'll need some suggestions
for whether we need to do anything specific for supporting Unicode or
keyboards outside the USA generating different 8-bit ASCII key codes
(Russian, Swedish, etc.)

It would be helpful to have some suggestions for a sample or two that need
to do key processing to get a better idea of the functionality we need to
support.

ka
---

Keycodes
Keypresses are represented by an enumerated type, wxKeyCode. The possible
values are the ASCII character codes, plus the following:


 WXK_BACK    = 8
 WXK_TAB     = 9
 WXK_RETURN  = 13
 WXK_ESCAPE  = 27
 WXK_SPACE   = 32
 WXK_DELETE  = 127

 WXK_START   = 300
 WXK_LBUTTON
 WXK_RBUTTON
 WXK_CANCEL
 WXK_MBUTTON
 WXK_CLEAR
 WXK_SHIFT
 WXK_CONTROL
 WXK_MENU
 WXK_PAUSE
 WXK_CAPITAL
 WXK_PRIOR
 WXK_NEXT
 WXK_END
 WXK_HOME
 WXK_LEFT
 WXK_UP
 WXK_RIGHT
 WXK_DOWN
 WXK_SELECT
 WXK_PRINT
 WXK_EXECUTE
 WXK_SNAPSHOT
 WXK_INSERT
 WXK_HELP
 WXK_NUMPAD0
 WXK_NUMPAD1
 WXK_NUMPAD2
 WXK_NUMPAD3
 WXK_NUMPAD4
 WXK_NUMPAD5
 WXK_NUMPAD6
 WXK_NUMPAD7
 WXK_NUMPAD8
 WXK_NUMPAD9
 WXK_MULTIPLY
 WXK_ADD
 WXK_SEPARATOR
 WXK_SUBTRACT
 WXK_DECIMAL
 WXK_DIVIDE
 WXK_F1
 WXK_F2
 WXK_F3
 WXK_F4
 WXK_F5
 WXK_F6
 WXK_F7
 WXK_F8
 WXK_F9
 WXK_F10
 WXK_F11
 WXK_F12
 WXK_F13
 WXK_F14
 WXK_F15
 WXK_F16
 WXK_F17
 WXK_F18
 WXK_F19
 WXK_F20
 WXK_F21
 WXK_F22
 WXK_F23
 WXK_F24
 WXK_NUMLOCK
 WXK_SCROLL

[Pythoncard-users] PythonCard for authoring

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

A thought came to me that PythonCard could also be used for things Flash
and PowerPoint are used now: for quick presentations and as authoring
tools. (At least HyperCard was able to do so).

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Saturday, October 06, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "What goes up has probably been doused with petrol." _/

RE: [Pythoncard-users] PythonCard discussion at cmpnet.byte.joncon

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

> From: Ronald D Stephens
>
> Kevin, I just wonderd if you had seen the discussion goin on over
> at cmpnet.byte.joncon (under the "Confessions of a Corporate IT
> Director" thread)??? Below is one...

I just went to look at it, thanks for the pointer.

> For myself, I guess I am hoping for a killer hypercard like
> IDE..but I am willing to wait ;-)))
>
> Do you plan on using Boa Consrtuctor eventually? Or writing a new
> IDE?? or something else???

I don't think I'll be writing the PythonCard support for Boa, though Patrick
expressed some interest. I'm not particularly fond of code generators and
the Boa UI seems overly complex for doing simple apps. I think Boa is a good
tool for what it is designed to do, it just doesn't feel right to me for
PythonCard.

> For us braindead low IQ part timers, an easy IDE may be the most
> importnat thing...

A great IDE is absolutely essential once the framework is ready for it, we
just aren't there yet. Since we're also looking for an environment more like
HyperCard, I don't think that it will have the same feel and work flow as VB
or Delphi or Boa. Even SuperCard and MetaCard failed to capture the tight
integration and feel of developing in and using HyperCard; the HyperCard
experience is what I would like to achieve, but we may have to settle for an
edit/run cycle more like SuperCard.

What would other people really like to see?

ka
ps. We need a solid framework first, but we can do experiments via runtime
tools (Shell, Message Watcher, Property Editor) and samples (resourceEditor)
prior to having a full IDE.

[Pythoncard-users] OOPs ! :-)) I said my piece, but here is the PythonCard post from cmpnet I MEANT to forwrd before... ;-)))

[Ronald D S. <rd...@ea...>]

Fred Pacquier wrote:
> 
> Well, if you consider Delphi's IDE a commercial-quality GUI, I'd say BOA
> comes close.

Indeed it does. The UI that it presents is quite an exhilarating thing.
However when I tried to actually use all the functionality that it
implies, I was left with the impression that BOA is raising expectations
that it cannot, as yet, really meet. Was I wrong? Are you actually using
BOA to create useful apps?
 
> There are two other interesting projects right now in that domain :
> PythonCard wants to be what HyperCard was for the Mac (and relies,
> surprise, on wxPython). Already does surprising things (and nice fractals!)

I've had a look at it as well, and have had some offline discussions
with Kevin Altis about it. My observation was that HyperCard was never
an app framework decoupled from an IDE, the two were always integrally
bound together. PythonCard *is* currently an app framework decoupled
from an IDE. Nothing wrong with that, per se, but I guess that many
people who hear "does for Python what HyperCard did for the Mac" will
expect the integral IDE right out of the starting gate, and will be
surprised not to find it.
 


-- 
Jon Udell | <http://udell.roninhouse.com/> | 603-355-8980

[Pythoncard-users] PythonCard discussion at cmpnet.byte.joncon

[Ronald D S. <rd...@ea...>]

Kevin, I just wonderd if you had seen the discussion goin on over at cmpnet.byte.joncon (under the "Confessions of a Corporate IT
Director" thread)??? Below is one...

For myself, I guess I am hoping for a killer hypercard like IDE..but I am willing to wait ;-)))

Do you plan on using Boa Consrtuctor eventually? Or writing a new IDE?? or something else???

For us braindead low IQ part timers, an easy IDE may be the most importnat thing...

Ron Stephens



-------- Original Message --------
Path: news.cmpnet.com!not-for-mail
From: Jon Udell <ud...@mo...>
Newsgroups: cmpnet.byte.joncon
Subject: Python GUIs -> Tk, wxPython
Date: Wed, 03 Oct 2001 13:30:36 -0400
Organization: CMP Media Inc.
Lines: 17
Message-ID: <3BB...@mo...>
References: <9o7vhg$rhl$1...@cm...> <9otrkp$ri7$1...@cm...>
<9ou79p$1v3$1...@cm...> <Xns91298A531B71FPaCmAnRDLM@192.215.71.106>
NNTP-Posting-Host: keen13.keene-dsl.monad.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: cmpweb-media0.web.cerf.net 1002130100 11446 208.0.179.13 (3 Oct 2001 17:28:20 GMT)
X-Complaints-To: us...@cm...
NNTP-Posting-Date: 3 Oct 2001 17:28:20 GMT
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
Xref: news.cmpnet.com cmpnet.byte.joncon:3133

> Unfortunately Tkinter programming usually feels strange to people not used
> to Tcl (ie to a lot of people), and has its own specific "look". But if
> cross-platform requirements are less stringent there are other choices. A
> prominent one is the wxPython library (based on the wxWindows C++
> framework). It has a decidedly MFC-like coding style, and allows portable
> GUI apps with native look-n-feel between Win32/Unix/Linux clients (a large
> market segment -- probably Macintosh someday too). Lastly, if a Windows-
> only user base is the target, Python can use the native Win32 API directly,
> in a very natural way to experienced programmers.

I'd strongly second that recommendation. wxPython is a terrific piece of
work, and I expect (though have not yet seen the proof) that could
support the development of complex and commecial-quality GUI apps.


--
Jon Udell | <http://udell.roninhouse.com/> | 603-355-8980

[Pythoncard-users] samples launcher using sizers

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

I modified the samples launcher (samples.py) to use sizers and have checked
it into cvs. The code uses nested wxBoxSizers and is similar to the sizers
in the doodle and hopalong samples, but more complex.

It looks fine under Windows 2000. I would appreciate it if someone running
Linux or Solaris could try it out and let me know if there are any alignment
or overlap issues with the widgets using a variety of themes; a reply to the
list with a JPEG shot of the window would be great, especially if there is a
problem with the layout. The description field expands with the window to
simplify viewing source and resource files.

The code appears below, but the code and .rsrc.py file may change slightly
depending on how the layout looks on Linux and Solaris. Remember that this
isn't what the final user code will look like, I'm using wxPython directly
to try and see what common elements are used by a variety of layouts. The
final user code will be much simpler.

One interesting thing to note is that it is still possible to use the
resourceEditor to do the basic fixed position layout without impacting the
sizer layout.

ka
---
    def setupSizers(self):
        sizer1 = wxBoxSizer(wxVERTICAL)
        sizer2 = wxBoxSizer(wxHORIZONTAL)
        sizer3 = wxBoxSizer(wxVERTICAL)
        sizer4 = wxBoxSizer(wxHORIZONTAL)
        comp = self.components

        btnFlags = wxLEFT | wxALIGN_BOTTOM
        vertFlags = wxLEFT | wxTOP | wxALIGN_LEFT

        sizer4.Add(comp.btnLaunch._delegate, 1, btnFlags, 5)
        sizer4.Add(comp.btnDescription._delegate, 1, btnFlags, 5)
        sizer4.Add(comp.btnSource._delegate, 1, btnFlags, 5)
        sizer4.Add(comp.btnResource._delegate, 1, btnFlags, 5)

        sizer3.Add(comp.stcCmdLineArgs._delegate, 0, wxLEFT | wxBOTTOM |
wxALIGN_TOP, 5)
        sizer3.Add(comp.chkLogging._delegate, 0, vertFlags, 5)
        sizer3.Add(comp.chkMessageWatcher._delegate, 0, vertFlags, 5)
        sizer3.Add(comp.chkNamespaceViewer._delegate, 0, vertFlags, 5)
        sizer3.Add(comp.chkPropertyEditor._delegate, 0, vertFlags, 5)
        sizer3.Add(comp.chkShell._delegate, 0, vertFlags, 5)
        sizer3.Add(5, 5, 1)  # spacer
        sizer3.Add(sizer4, 1, wxALIGN_BOTTOM | wxEXPAND)

        sizer2.Add(comp.listSamples._delegate, 0, wxRIGHT | wxALIGN_TOP, 5)
        sizer2.Add(sizer3, 1, wxEXPAND)

        sizer1.Add(sizer2, 0, vertFlags)
        sizer1.Add(5, 5, 0)  # spacer
        sizer1.Add(comp.stcDescription._delegate, 0, wxLEFT | wxTOP |
wxBOTTOM | wxALIGN_LEFT, 5)
        sizer1.Add(comp.fldDescription._delegate, 1, wxEXPAND)

        sizer1.Fit(self)
        sizer1.SetSizeHints(self)
        self.panel.SetSizer(sizer1)
        self.panel.SetAutoLayout(true)
        self.panel.Layout()

[Pythoncard-users] I'm back, current priorities

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

I'm back. It looks like we had 160+ downloads of release 0.4.5
http://sourceforge.net/project/showfiles.php?group_id=19015
in the last two weeks, but as Andy mentioned in a previous email, the list
has been awfully quiet while I was away. If you are using the current
framework, have found any problems, or are waiting for a particular feature
to be added before you get active on the list, please share your thoughts
and issues with the list.

The TODO.txt file shows my current priorities as documentation, fonts, and
sizers.

There are a few people on the list that are supposedly working on
documentation, so I'll let them respond to the list to let us know their
status.

Based on the responses I got from the wx-users and wxpython-users mailing
lists regarding fonts before I left, I would like to leave fonts as is until
we can get some better support for determining the font family based on a
font face name. That means that the API for fonts will change in the future,
but any updates to user code should be minor. I'll pursue this issue on the
wx-dev mailing list.

I'm going to modify some more of the samples to use sizers and then start
some tests for adding sizers via the .rsrc.py files. I was quite surprised
to see that many of the people downloading the latest release got the
.tar.gz file which implies that they are running Linux or Solaris. Since the
current samples often look pretty bad under Linux because of the fixed
positions and sizes of the widgets, I would like to get some sort of sizer
arrangement working in the next two weeks. Any suggestions for an
implementation or help would be appreciated.

On a related note, I'm thinking of adding support for loading different
.rsrc.py files based on the runtime platform, so that we might have multiple
.rsrc.py files like minimal.win32.rsrc.py, minimal.linux.rsrc.py, and a
default minimal.rsrc.py that would be used if no other was available. The
pythoncard.user.config.py file could specify the user preference for which
to use which will simplify development testing of multiple .rsrc.py files.

I thought some more about a simple flat file database creator to further
test the back-end persistance mechanism idea. I will probably work on that a
bit and then let Patrick, Andy, and some of the other people that expressed
interest in that area expand on the idea. My current preference would be to
support random access, getRecord/setRecord and getField/setField style
methods, though with dot notation, both record (card) and field (widget)
would be attributes. In addition, the user will be able to turn on/off the
persistance mechanism, since apps like most of the current samples don't
really need automatic persistance. We can start a separate thread to go into
issues about data and metadata storage.

Finally, I'm going to spend some more time on the graphic.py module and wrap
up more of the underlying wxPython drawing capabilities.

If you have other issues you would like to see addressed or get a higher
priority, please post a message to the list.

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

[Pythoncard-users] Re: Why so quiet

[Peter <pe...@pe...>]

I'm still very interested in PythonCards progress.  Just unable to do 
anything with it right now.

Ever since Nimda we have been living under a no-internet policy at 
work.  And no personal email, no unauthorized software either.  It's 
been Hell.  Restrictions are starting to lift, not because our systems 
are more secure, but because our president got over her panic attack.

I read the article on OReillyNet about PythonCard - it's nice to see the 
project get noticed.  And I saw another article there about RealBasic as 
another HyperCard replacement candidate.  It's not open source and no 
good on UNIX, but it looked promising.  But RealBasic's biggest flaw, to 
my way of thinking, is the lack of built in persistence (Cards and 
Backgrounds).

I can't wait to see what comes from the ZODB work.

Peter

Re: [Pythoncard-users] Awfully Quiet Around Here

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

As for myself, I am learning Zope. And I really like some things about it
which probably will be appropriate for PythonCard too.

I like the way Zope stores it's objects in a hierarchy of containers
(named folders) and how preperties and objects could be easily reused if
stored above or in this folder.

Also, I like the idea of Zope management interface. It will be nice to
have a mode where logic objects reveal themselves visually. For example,
if PythonCard app needs database connection to do a query, it could
use one defined in the enclosing containers.

Hypercard did acquisition by adding stacks to the path. Zope does the same
by using folders.

PythonCard could go further by allowing drop-in objects. Programmer could
drop a logic object into stack and use it's functionality.

To summarise, in Zope I saw a way to have logic, presentation and
content consistently present in the organized manner with simple
property acquisition rules. So, probably, in PythonCard it could be
beneficial to have something like this.

That was just an idea. I do not know how this could be visually presented.
But some container-structure browser could be built, no doubt.


Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Thursday, September 27, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "A closed mouth gathers no feet." _/

RE: [Pythoncard-users] Awfully Quiet Around Here

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

> Q: Why is it quiet?
>
> A: Kevin has been out of town.

I'm still watching the list, just not working on any code. I'll be back and
active Monday, October 1st.

ka

RE: [Pythoncard-users] Awfully Quiet Around Here

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

Q: Why is it quiet?

A: Kevin has been out of town.

In the mean time, I'm still pursuing the use of ZODB as a persistent
storage. I'll race you!

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Andy Todd
Sent: Thursday, September 27, 2001 4:28 AM
To: Pythoncard-Users
Subject: [Pythoncard-users] Awfully Quiet Around Here

My apologies if this is a duplicate, I'm having a few email issues at
the moment.

Anyone there? I count no messages on this list for the last four days at
least. Has anyone looked at the latest prototype? Does it do everything
you ever wanted? (somehow I doubt it). Does anyone have suggestions,
bugs, documentation, sample applications or opinions of any type they
wish to share? Or am I talking to myself here?

<snip>

Regards,
Andy
--
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can"


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

[Pythoncard-users] Awfully Quiet Around Here

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

My apologies if this is a duplicate, I'm having a few email issues at 
the moment.

Anyone there? I count no messages on this list for the last four days at 
least. Has anyone looked at the latest prototype? Does it do everything 
you ever wanted? (somehow I doubt it). Does anyone have suggestions, 
bugs, documentation, sample applications or opinions of any type they 
wish to share? Or am I talking to myself here?

As an update to my last message, I've tracked down the bug in the 
WorldClock sample and am hoping to have a patch available later this 
week. As an aside I tried testing this sample under cygwin and it will 
not work. There is a known bug with time.timezone() on cygwin python 
that causes an incorrect value to be returned and this messes up all of 
the delicate calculations. There is a patch on sourceforge for this so 
I'm hoping it will get included in Python 2.2 (or at least 2.3). Anybody 
else come across platform specific issues that may trip us up?

I've also been looking at Gadfly, initially for inclusion in the 
dbBrowser sample application but with a view to using it as one of our 
persistence mechanisms. Its looking good but needs a little work at the 
Gadfly end (mainly because it uses regex rather than re), any assistance 
is, of course, welcome.

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can"

[Pythoncard-users] FW: Binary packages for Windows, Unix, etc.

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

Any Solaris users on the list? What sort of distribution do you need?

ka

-----Original Message-----
From: nobody [mailto:no...@so...]On Behalf Of Jeremy McMillan
Sent: Friday, September 21, 2001 11:36 PM
To: al...@se...
Subject: RE: Binary packages for Windows, Unix, etc.


Let me know if you want Solaris packages. I'm not going to  go to the
trouble until I know you'll post them, and I  need to know if you want
static binaries, if you need  separate packages for the dependancies, or if
you want to  include the dependancies. Need to settle naming  conventions,
and I need to have your ear when I discover  something else which requires
project forward thinking.

[Pythoncard-users] Errors in worldclock sample

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

All,

Just to let you know that extensive testing has discovered a bug in the 
worldclock sample.

Specifically the javascript I converted to a python module is 
calculating an incorrect value for the URL to update the image from.

I'm investigating the bug and hope to have a correction soon. In the 
meantime if you want to get the 'correct' image I suggest you switch 
back to using the javascript function to calculate the URL. To 
accomplish this change just uncomment lines 76 to 83 of worldclock.py 
and comment out line 84. This section of the file should change from;

"""
         # try:
         #    jScript = "cscript //nologo xearth.js"
         #    file = os.popen(jScript)
         #    s = file.read()
         #    url = "http://www.time.gov/" + s
         # except:
         #    url = "http://www.time.gov/images/xearths/night.jpg"
         #    #url = "http://www.time.gov/images/xearths/11N/100N.jpg"
         url = "http://www.time.gov/" + xearth.getLatLong()
"""

to

"""
         try:
            jScript = "cscript //nologo xearth.js"
            file = os.popen(jScript)
            s = file.read()
            url = "http://www.time.gov/" + s
         except:
            url = "http://www.time.gov/images/xearths/night.jpg"
            #url = "http://www.time.gov/images/xearths/11N/100N.jpg"
         # url = "http://www.time.gov/" + xearth.getLatLong()
"""

Any questions, please shout.

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Hit me with your fax machine, baby" - Francis Dunnery, "Because I Can"

RE: [Pythoncard-users] fwd: The Pros and Cons of XML

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

I hit the send key too soon on the first post...

I basically agree with what Skip had to say below. Just for reference sake,
here are some more XML-RPC and SOAP links for those that want to investigate
further.

A Busy Developer's Guide to SOAP 1.1
http://www.soapware.org/bdg

SoapWare.Org
http://www.soapware.org/

XML-RPC Home Page
http://www.xmlrpc.com/

Most of the data storage and resource work I'll be experimenting with in the
next month or so will continue to use Python data types like dictionaries
and lists, so I won't be looking at XML much until after that.

I would still appreciate it if someone that knows the Python XML libraries
could fix the XML bugs in the SourceForgeTracker sample (see the readme and
comments in the SourceForgeTracker.py file for more info or just post your
questions to the list.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Skip
> Montanaro
> Sent: Tuesday, September 18, 2001 11:54 AM
> To: pyt...@li...
> Subject: Re: [Pythoncard-users] fwd: The Pros and Cons of XML
>
>
>
> (apologies if you receive this multiple times - i've been having mail
> problems - originally sent 12 Sep 2001 13:50:11)
>
> (I am still having trouble sending to this list.  I originally posted this
> note on September 7th but haven't seen it turn up expect as a mail bounce.
> In some sense this is simply a test.  My apologies if you're seeing this
> message twice.)
>
>     Kevin> At some point we are going to support XML, at least for
>     Kevin> import/export and possibly the resource format. It
> will certainly
>     Kevin> be used for any XML-RPC or SOAP connectivity, which is probably
>     Kevin> how PythonCard apps are going to talk to the rest of
> the world in
>     Kevin> a standard way.
>
> I think there is an important distinction to make between SOAP and XML-RPC
> on the one hand, and things like storing Pythoncard resource
> files in XML on
> the other hand.  From the programmer's standpoint, SOAP and
> XML-RPC are just
> RPC protocols.  I've been using XML-RPC for about three years now, and the
> only time I've ever looked at the raw XML was when I was mucking about in
> the xmlrpclib.py implementation and screwed something up.  My clients and
> servers pass tens of thousands of messages back and forth every day and I
> never pay any attention to the XML.  In other words, from the
> standpoint of
> Pythoncard users or developers, SOAP and XML-RPC might as well be using
> paper tapes encoded in Morse code, tied to the legs of carrier pigeons to
> get the data back and forth.  There are issues of bandwidth usage and the
> costs to marshal and unmarshal data with SOAP and XML-RPC, but they aren't
> insurmountable, and really only come into play if you are
> transferring lots
> of data.  (They would often be problems with other RPC encodings as well.)
>
> The October issue of WebTechniques magazine (not available online until
> September 12) has an article about SOAP.  It posts the obligatory
> XML for a
> simple request and response.  No code was posted (that I recall)
> showing how
> to make a SOAP call from Perl or Python.  In my mind, by dwelling on the
> transport encoding the article completely misses the point of
> using SOAP (or
> XML-RPC or ORBit or Fnorb or ...), which is that for the application
> programmer, they make RPC programming drop dead easy.
>
> All the pros and cons of XML will only come into play when you have to
> invent an XML encoding for, say, Pythoncard resource data.  I would only
> worry about most of the Pros and Cons listed in the Zapthink
> article in that
> light.
>
> All that said, the Zapthink article does look like a good contrast of the
> pros and cons of XML.
>
> --
> Skip Montanaro (sk...@po...)
> http://www.mojam.com/
> http://www.musi-cal.com/
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

RE: [Pythoncard-users] fwd: The Pros and Cons of XML

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

I basically agree with what Skip had to say below. Just for reference sake,
here are some more XML-RPC and SOAP links for those that want to investigate
further.

A Busy Developer's Guide to SOAP 1.1
http://www.soapware.org/bdg

XML-RPC Home Page
http://www.xmlrpc.com/
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Skip
> Montanaro
> Sent: Tuesday, September 18, 2001 11:54 AM
> To: pyt...@li...
> Subject: Re: [Pythoncard-users] fwd: The Pros and Cons of XML
>
>
>
> (apologies if you receive this multiple times - i've been having mail
> problems - originally sent 12 Sep 2001 13:50:11)
>
> (I am still having trouble sending to this list.  I originally posted this
> note on September 7th but haven't seen it turn up expect as a mail bounce.
> In some sense this is simply a test.  My apologies if you're seeing this
> message twice.)
>
>     Kevin> At some point we are going to support XML, at least for
>     Kevin> import/export and possibly the resource format. It
> will certainly
>     Kevin> be used for any XML-RPC or SOAP connectivity, which is probably
>     Kevin> how PythonCard apps are going to talk to the rest of
> the world in
>     Kevin> a standard way.
>
> I think there is an important distinction to make between SOAP and XML-RPC
> on the one hand, and things like storing Pythoncard resource
> files in XML on
> the other hand.  From the programmer's standpoint, SOAP and
> XML-RPC are just
> RPC protocols.  I've been using XML-RPC for about three years now, and the
> only time I've ever looked at the raw XML was when I was mucking about in
> the xmlrpclib.py implementation and screwed something up.  My clients and
> servers pass tens of thousands of messages back and forth every day and I
> never pay any attention to the XML.  In other words, from the
> standpoint of
> Pythoncard users or developers, SOAP and XML-RPC might as well be using
> paper tapes encoded in Morse code, tied to the legs of carrier pigeons to
> get the data back and forth.  There are issues of bandwidth usage and the
> costs to marshal and unmarshal data with SOAP and XML-RPC, but they aren't
> insurmountable, and really only come into play if you are
> transferring lots
> of data.  (They would often be problems with other RPC encodings as well.)
>
> The October issue of WebTechniques magazine (not available online until
> September 12) has an article about SOAP.  It posts the obligatory
> XML for a
> simple request and response.  No code was posted (that I recall)
> showing how
> to make a SOAP call from Perl or Python.  In my mind, by dwelling on the
> transport encoding the article completely misses the point of
> using SOAP (or
> XML-RPC or ORBit or Fnorb or ...), which is that for the application
> programmer, they make RPC programming drop dead easy.
>
> All the pros and cons of XML will only come into play when you have to
> invent an XML encoding for, say, Pythoncard resource data.  I would only
> worry about most of the Pros and Cons listed in the Zapthink
> article in that
> light.
>
> All that said, the Zapthink article does look like a good contrast of the
> pros and cons of XML.
>
> --
> Skip Montanaro (sk...@po...)
> http://www.mojam.com/
> http://www.musi-cal.com/
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Re: [Pythoncard-users] fwd: The Pros and Cons of XML

[Skip M. <sk...@po...>]

(apologies if you receive this multiple times - i've been having mail
problems - originally sent 12 Sep 2001 13:50:11)

(I am still having trouble sending to this list.  I originally posted this
note on September 7th but haven't seen it turn up expect as a mail bounce.
In some sense this is simply a test.  My apologies if you're seeing this
message twice.)

    Kevin> At some point we are going to support XML, at least for
    Kevin> import/export and possibly the resource format. It will certainly
    Kevin> be used for any XML-RPC or SOAP connectivity, which is probably
    Kevin> how PythonCard apps are going to talk to the rest of the world in
    Kevin> a standard way.

I think there is an important distinction to make between SOAP and XML-RPC
on the one hand, and things like storing Pythoncard resource files in XML on
the other hand.  From the programmer's standpoint, SOAP and XML-RPC are just
RPC protocols.  I've been using XML-RPC for about three years now, and the
only time I've ever looked at the raw XML was when I was mucking about in
the xmlrpclib.py implementation and screwed something up.  My clients and
servers pass tens of thousands of messages back and forth every day and I
never pay any attention to the XML.  In other words, from the standpoint of
Pythoncard users or developers, SOAP and XML-RPC might as well be using
paper tapes encoded in Morse code, tied to the legs of carrier pigeons to
get the data back and forth.  There are issues of bandwidth usage and the
costs to marshal and unmarshal data with SOAP and XML-RPC, but they aren't
insurmountable, and really only come into play if you are transferring lots
of data.  (They would often be problems with other RPC encodings as well.)

The October issue of WebTechniques magazine (not available online until
September 12) has an article about SOAP.  It posts the obligatory XML for a
simple request and response.  No code was posted (that I recall) showing how
to make a SOAP call from Perl or Python.  In my mind, by dwelling on the
transport encoding the article completely misses the point of using SOAP (or
XML-RPC or ORBit or Fnorb or ...), which is that for the application
programmer, they make RPC programming drop dead easy.

All the pros and cons of XML will only come into play when you have to
invent an XML encoding for, say, Pythoncard resource data.  I would only
worry about most of the Pros and Cons listed in the Zapthink article in that
light.

All that said, the Zapthink article does look like a good contrast of the
pros and cons of XML.

-- 
Skip Montanaro (sk...@po...)
http://www.mojam.com/
http://www.musi-cal.com/

[Pythoncard-users] Announce: PythonCardPrototype release 0.4.5

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

PythonCard is a software construction kit (in the spirit of Apple's
HyperCard) written in Python.

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

Samples included in the latest release: addresses, conversions, dbBrowser,
dialogs, doodle, findfiles, hopalong, minimal, proof, resourceEditor,
samples, searchexplorer, sounds, SourceForgeTracker, textIndexer, tictactoe,
turtle, widgets, worldclock

To see screenshots of some of the samples, visit:
http://pythoncard.sourceforge.net/samples.html
A description of each sample is included in the docs directory and the
readme.txt file in each sample directory.

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

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

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


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

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

PyCrust 0.6
PyCrust by Patrick K. O'Brien is required by PythonCard, but is no longer
included as part of the PythonCardPrototype releases. Please visit the home
page at   http://sourceforge.net/projects/pycrust/
and download the latest release at
  http://sourceforge.net/project/showfiles.php?group_id=31263


----------------------------
Changes since release 0.4.3 (2001-08-23):

Release 0.4.5 2001-09-17
PyCrust is no longer included in the PythonCardPrototype
  distribution, please download PyCrust at:
  http://sourceforge.net/project/showfiles.php?group_id=31263
moved Bitmap class to graphic.py module
  added getPILBits and setPILBits to Bitmap class
    to simplify using PIL with PythonCard
added BitmapCanvas widget to widget.py
  added doodle and hopalong samples which use BitmapCanvas
  The BitmapCanvas is very experimental and will be
    enhanced and improved
Debug windows are now children of the app window
  Namespace Viewer, Property Editor, Shell
added 'Save Configuration' option to Debug menu
  this will create a pythoncard.user.config.py file
  with the current debug window position and sizes
changed Message Watcher to use sizers
renamed readDictionaryFile to readAndEvalFile
  updated addresses.py and searchexplorer.py to use the new function


Release 0.4.4.5 2001-09-08
posted Help Wanted on SourceForge
  http://sourceforge.net/people/?group_id=19015
posted Python Conference request for papers/tutorials
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/767719
added addMethod to Scriptable class for dynamically adding
  handlers at runtime, see:
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/770015
added 'openBackground' message to replace using __init__
changed background handlers to on_mouseClick form
modified SourceForgeTracker so that double-clicking on a topic
  launches the web page for that topic in a browser
Neil added Pyker.hta and PykerLaunch.hta
  see the following URL for more info
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/766307
Andy added a TODO.txt to document short-term plans for PythonCard
  development
Property Editor and resourceEditor sample were changed to use
  default size (-1, -1) values
added enable and check menu items to menu.py
  see the url below and thread replies
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/766371
started some documentation for the Button class
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/764832
added display of .rsrc.py files in samples.py
Patrick added dot notation support to the Font class
Jeff and Neil provided some Unix screenshots
  These show we need to get sizers working to deal with variable
    size widgets and fonts on different platforms
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/763602
  http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/763659
res.py eval() changed to support using Windows-style line endings
  under Unix
added "Redirect stdout to Shell" option to Debug menu


Release 0.4.4.1 2001-08-31
added samples.py to launch the the various sample programs
  see samples\samples.py
  added readme.txt files to all samples that didn't already
    have one. the readme.txt is displayed as the
    'description' for a sample


Release 0.4.4 2001-08-30
added getting_started.html to docs\html
added basic status bar support
  statusbar.py module
  see test_turtle.py for an example
turtle sample updated
  test_turtle.py now uses a status bar and displays the
  time required to draw a design
  added line(x1, y1, x2, y2) method to turtle
added extra parametes to FileDialog to support saving files
  see resourceEditor for an example
  see dialog.py for complete list of options
added Namespace Viewer using PyFilling (part of PyCrust 0.6)
fixed numerous Property Editor edit/display bugs
  widgets are now displayed in the proper order
added Font support to all widgets
  Font class moved to font.py module
  the actual text descriptions of the fonts is going to
    change, so if you use them, just be aware that the format
    of the font descriptions will change by the next release
  a font can be passed to the Font dialog to set the initial
    font displayed
commented out 'import warnings' for Python 2.0 support
  but PyCrust usage still means that you need Python 2.1.x
  if any Debug windows like the shell will be used
fixed unitialized empty bitmaps on win98
added append method to Choice class
added setFocus method to Widget
dbBrowser sample updated to version 0.2
resourceEditor changes
  resourceEditor can now save .rsrc.py files
    make sure to only work on copies in case of bugs
    also some hand editing of .rsrc.py is still necessary
    depending on what you're trying to do
  Duplicate Widget menu item now causes the duplicate to
    be offset 10 pixels so it can be selected to select
  added template.rsrc.py for defaults
worldclock sample demonstrates simple use of logging

RE: [Pythoncard-users] announce: release 0.4.5

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

In addition to the regular 'proto-0.4.5.zip' source file, there is a win32
binary installer 'proto-0.4.5.win32.exe' and a Unix 'proto-0.4.5.tar.gz'
file; both use distutils. Please report any problems to the list.

ka
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, September 17, 2001 1:04 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] announce: release 0.4.5
>
>
> I'm just announcing to the list for now. As usual, the file is at:
> https://sourceforge.net/project/showfiles.php?group_id=19015
>
> The big change is that PyCrust is no longer included in the
> distribution, so
> you'll need to get PyCrust 0.6 separately. Also, Andy has been work on
> distutils and if no problems are reported with this .zip
> distribution, then
> we'll put up distutils distributions for Linux and Windows tomorrow, but
> there won't be any additional changes to the modules and samples. Please
> download proto-0.4.5.zip and report any problems to the list today if
> possible.
>
> changes since 0.4.4.5
>
> Release 0.4.5 2001-09-17
> PyCrust is no longer included in the PythonCardPrototype
>   distribution, please download PyCrust at:
>   http://sourceforge.net/project/showfiles.php?group_id=31263
> moved Bitmap class to graphic.py module
>   added getPILBits and setPILBits to Bitmap class
>     to simplify using PIL with PythonCard
> added BitmapCanvas widget to widget.py
>   added doodle and hopalong samples which use BitmapCanvas
>   The BitmapCanvas is very experimental and will be
>     enhanced and improved
> Debug windows are now children of the app window
>   Namespace Viewer, Property Editor, Shell
> added 'Save Configuration' option to Debug menu
>   this will create a pythoncard.user.config.py file
>   with the current debug window position and sizes
> changed Message Watcher to use sizers
> renamed readDictionaryFile to readAndEvalFile
>   updated addresses.py and searchexplorer.py to use the new function
>
> ka
> ---
> Kevin Altis
> al...@se...
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

[Pythoncard-users] announce: release 0.4.5

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

I'm just announcing to the list for now. As usual, the file is at:
https://sourceforge.net/project/showfiles.php?group_id=19015

The big change is that PyCrust is no longer included in the distribution, so
you'll need to get PyCrust 0.6 separately. Also, Andy has been work on
distutils and if no problems are reported with this .zip distribution, then
we'll put up distutils distributions for Linux and Windows tomorrow, but
there won't be any additional changes to the modules and samples. Please
download proto-0.4.5.zip and report any problems to the list today if
possible.

changes since 0.4.4.5

Release 0.4.5 2001-09-17
PyCrust is no longer included in the PythonCardPrototype
  distribution, please download PyCrust at:
  http://sourceforge.net/project/showfiles.php?group_id=31263
moved Bitmap class to graphic.py module
  added getPILBits and setPILBits to Bitmap class
    to simplify using PIL with PythonCard
added BitmapCanvas widget to widget.py
  added doodle and hopalong samples which use BitmapCanvas
  The BitmapCanvas is very experimental and will be
    enhanced and improved
Debug windows are now children of the app window
  Namespace Viewer, Property Editor, Shell
added 'Save Configuration' option to Debug menu
  this will create a pythoncard.user.config.py file
  with the current debug window position and sizes
changed Message Watcher to use sizers
renamed readDictionaryFile to readAndEvalFile
  updated addresses.py and searchexplorer.py to use the new function

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

[Pythoncard-users] Jabber and PythonCard

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

Last week, jabberpy 0.2 was announced
http://jabberpy.sourceforge.net/

Yesterday, Roman asked about threading and PythonCard and today I saw this
nice page covering info for writing a Jabber client.

The Jabber Client Developer's Cheat Sheet
http://homepage.mac.com/jens/Jabber/JabberClientCheatSheet.html

This got me thinking about Jabber and PythonCard. Writing a basic Jabber
client in PythonCard has been one of the tests in my mind since we started
the list. Jabber is most typically used as an instant messaging client and
Jabber servers can act as gateways to the most popular instant messaging
services: AOL, ICQ, Yahoo, and MSN; a large number of other transports are
also supported, see http://www.jabber.org/?oid=72. Jabber is also an
architecture and platform for handling presence management and distributing
XML packets. The short story is that Jabber is good stuff. For more info,
check out http://www.jabber.org/

A lot of the components for doing a client with PythonCard are already in
place. I probably won't commit any serious thought and effort to a
PythonCard-based Jabber client for a while, but if someone else wants to
start investigating, it would be a great topic for list discussion because
it will expose a lot of issues with the framework.

ka

[Pythoncard-users] new graphic.py module

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

I moved the PIL Image module import and Bitmap class out of widget.py and
into a new module called graphic.py

I updated the worldclock and tictactoe samples and widget.py to use the new
module.

ka

RE: [Pythoncard-users] threads & PythonCard

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

I don't know why you are having problems with tkinter and threads. Do the
wcgui.py and wsgui.py programs in the the python21\Tools\webchecker
directory run correctly?

The wxPython demo.py program has a threads example. I've asked Robin to help
do the conversion of the webchecker tkinter programs for wxPython as
examples of doing threading with wxPython, which will also work with
PythonCard, but he's been too busy to work on it.

There will probably be some parts of the PythonCard framework that are
threaded, but given the additional complexities that threading will add, I
doubt we'll use threading that much. It is more likely that we'll provide
some examples of using a timer or idle loop or yield operation for the user
code to do longer operations. I just don't know right now.

We haven't gotten into app to app communication at all yet, so again I don't
know the answer. I still want to wrap up most of the basic GUI issues, then
work on data storage for user data and meta data before looking at remote
and local app communication. Anyone else that would like to address
communication issues now by writing some modules and experiments is welcome
to.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Roman
> Suzi
> Sent: Sunday, September 16, 2001 1:47 PM
> To: pyt...@li...
> Subject: [Pythoncard-users] threads & PythonCard
>
>
> I've just understood that Tkinter and threads aren't compatible
> under Windows. Is wxPython compatible with threads?
> Will PythonCard apps be multithreaded?
> What will be the way to interprocesscommunications for
> PythonCard?
>
> Sincerely yours, Roman Suzi
> --
> _/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
> _/ Sunday, September 16, 2001 _/ Powered by Linux RedHat 6.2 _/
> _/ "Phobia: what's left after drinking 2 out of a 6 pack" _/
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>