pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] Estimated release date for new version of PythonCard

[Alex T. <al...@tw...>]

Ruben Marquez wrote:

>Hi,
>
>I've been away from PythonCard for a while.  I'm happy
>to see that it seems to be in active development. 
>However, I was surprised to see that the last official
>release is over a year old.  Am I missing something. 
>Is everyone just working off of the CVS version (like
>the Boa users)?  Any way, no pressure, just checking. 
>Thanks.
>  
>
It is in active development - but since the last release the great 
majority of changes have been enhancements, improvements or bug fixes to 
the tools (which usually had a workaround).

* That's from memory - so particularly unreliable :-)

So I suspect that there could a be a fair proportion of users out there 
still using quite happily the last released version.
And I think there is another good portion who are happily working from 
CVS and getting the advantage of the improvements in the tools 
(resourceEditor and standalone Builder mostly)


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.12.8/161 - Release Date: 03/11/2005

[Pythoncard-users] Estimated release date for new version of PythonCard

[Ruben M. <rmc...@ya...>]

Hi,

I've been away from PythonCard for a while.  I'm happy
to see that it seems to be in active development. 
However, I was surprised to see that the last official
release is over a year old.  Am I missing something. 
Is everyone just working off of the CVS version (like
the Boa users)?  Any way, no pressure, just checking. 
Thanks.

-Ruben


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

[Pythoncard-users] Simplesizer - found the right person to thank.

[Alex T. <al...@tw...>]

Many months ago,  there was some discussion about sizers, etc. One nice 
simple idea was suggested; at the time, I kind of "rejected" it because 
there are some simple things it didn't get quite right.

But recently I decided there were more things it could do right - and it 
was very simple. So I implemented something loosely based on that thread 
in the simpleSizer which I added to PythonCard in the last 2 or 3 
months; when I was doing that, I couldn't find the original email 
thread, so I didn't remember who had suggested it, and couldn't properly 
thank Fred for suggesting it.

But today I stumbled over it - so here is a belated attribution of the 
idea .... thanks Fred.
(And I realize my memory wasn't quite perfect, so it is much more 
"loosely" based than I had thought.)


  Sells, Fred wrote:

>> B. Geometry managements (aka sizers, resizing, etc.)
>> We had a simple grid (default to 100x100) with "attachment 
>> properties" on
>> each widget.  If both right and left edge of widget were attached, it 
>> would
>> move and resize with window resize, etc.  To simplify the use of
>> attachement, we had an attachment dialog that had 4 sets of identical
>> "attaching controls" arranged at North, South, East, West.  Combined 
>> with
>> multiple widget select, you could attache left and right sides of a 
>> bunch at
>> once, then go back and individually set top,bottom.  It was not as 
>> elegant
>> as most UI builders, but it was easy (the product was, after all, "ezX")
>>  
>>
> I think it's a little bit too simple for Pythoncard; it can't 
> adequately handle some very simple cases (e.g. the scrolling text 
> dialog, with one growable size textarea and one fixed size button 
> below it), and I think that could put a lot of people off.


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.12.6/152 - Release Date: 31/10/2005

[Pythoncard-users] Helpful Wrapper functions

[Alex T. <al...@tw...>]

A while back I mentioned some code to help dynamically create dialogs 
with a number of (text) buttons, and then later a function to help 
create pop-up menus.

Today I had need of dialog presenting a moderate number of checkBoxes, 
and thought it would be much easier to use a wrapper rather than laying 
out a custom dialog, and so created a wrapper function to do this; it 
turned out to be very similar to the multiButton one I had done before.

There was some discussion back in June and August about adding these to 
the core PythonCard distribution - and no-one argued against it. So I 
went ahead and committed into CVS tonight (and am in the process of 
adding a sample to demonstrate their usage).

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.12.6/152 - Release Date: 31/10/2005

Re: [Pythoncard-users] Window frames

[Alex T. <al...@tw...>]

Alex Tweedly wrote:

> Tony Mullen wrote:
>
>> Hello,
>>
>> I'm new to PythonCard and to wxPython and I'm still working on getting
>> a clear understanding of how they work together.  I would like to
>> create windows in my application which do not have the header bar, or
>> in some cases with no frame at all (for example for a splash screen
>> widget).  I see in the PythonCard Framework Overview that various
>> window styles are not supported.  Is there a workaround for this?  
>>
> Not yet - but I'm looking into it now.:-)   I wanted this about six 
> months back - but not strongly enough to pursue it then; but I have 
> some ideas on how it might be tackled.
>
> I will say more later today.
>
I'm proposing that we implement this enhancement in two phases, as 
below. If no-one brings up any problems or objections over the next few 
days, I'll put this into CVS. It is (of course) fully backward compatible.

Overview:

A resource file contains a "style" for the background / window. This 
defaults to [] (and is usually omitted in that case), or it can 
currently take the value      ["resizeable"]    to indicate th window 
should be resizeable. All other style factors are fixed.

We will extend this to also allow this to be a list of strings which are 
wxWindow style constants - e.g.
          'style':['wx.SYSTEM_MENU', 'wx.CAPTION', 'wx.CLOSE_BOX'],



Phase 1.
(you can do this in the short term, even before any CVS change).

You'll need to edit in any style changes to the rsrc file by hand. I 
wouldn't be surprised if these are lost when the rsrc file is edited in 
the resourceEditor - so keep a copy if the values you need.

Change your local copy of PythonCard/model.py as follows (be *sure* to 
keep a safe copy)

Around line 640 (for latest CVS copy,  I think around line number 614 
for 0.8.1), you'll find

>         # KEA 2004-01-18
>         # have to explicitly declare the close box in wxPython 2.5
>         style = wx.MINIMIZE_BOX | wx.SYSTEM_MENU | wx.CAPTION | 
> wx.CLOSE_BOX
>         if aBgRsrc.style == ['resizeable']:
>             style = wx.DEFAULT_FRAME_STYLE

change that to

>         # KEA 2004-01-18
>         # have to explicitly declare the close box in wxPython 2.5
>         if aBgRsrc.style == []:
>             style = wx.MINIMIZE_BOX | wx.SYSTEM_MENU | wx.CAPTION | 
> wx.CLOSE_BOX
>         elif aBgRsrc.style == ['resizeable']:
>             style = wx.DEFAULT_FRAME_STYLE
>         else:
>             style = 0
>             for i in aBgRsrc.style:
>                 style |= eval(i)

(the long term fix will put this in a try:except clause - but you can 
get by without that for a few days ...)

Phase 2.

a. Add the try: except protection around the eval() statement
b. Extend the resourceEditor to support the definition of window styles.
(this isn't hard - I've got a basic version working, but will need more 
testing ...)

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.12.6/152 - Release Date: 31/10/2005

Re: [Pythoncard-users] Window frames

[Alex T. <al...@tw...>]

Tony Mullen wrote:

>Hello,
>
>I'm new to PythonCard and to wxPython and I'm still working on getting
>a clear understanding of how they work together.  I would like to
>create windows in my application which do not have the header bar, or
>in some cases with no frame at all (for example for a splash screen
>widget).  I see in the PythonCard Framework Overview that various
>window styles are not supported.  Is there a workaround for this? 
>  
>
Not yet - but I'm looking into it now.:-)   I wanted this about six 
months back - but not strongly enough to pursue it then; but I have some 
ideas on how it might be tackled.

I will say more later today.

>Also, does this lack of scrolling refer only to Backgrounds, or is
>scrolling not supported in any widgets?
>  
>
It's supported in TextFields, ListFields, etc. and other text widgets.

I don't think there's any support for wx's ScrolledWindows - i.e. what 
you'd want for a general scrolling window.

You can, of course, create your own wx.ScrolledWindow - but it means you 
have to use (and learn) wx's way of getting and handling events, drawing 
items, etc.   This can still be worthwhile - you get the benefit of 
PCard's ease of use for most of your menus, widgets, etc. - and only 
revert to using the more primitive wx calls directly when needed.

I've done my own scrolling within a BitMapCanvas when I didn't need 
standard scroll bars - you may be able to do that and simply add scroll 
bars with wx.

Let us know more about what you want to do with the scrolling and we may 
be able to suggest either workarounds,

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.12.6/152 - Release Date: 31/10/2005

[Pythoncard-users] Window frames

[Tony M. <mul...@gm...>]

Hello,

I'm new to PythonCard and to wxPython and I'm still working on getting
a clear understanding of how they work together.  I would like to
create windows in my application which do not have the header bar, or
in some cases with no frame at all (for example for a splash screen
widget).  I see in the PythonCard Framework Overview that various
window styles are not supported.  Is there a workaround for this?=20
Also, does this lack of scrolling refer only to Backgrounds, or is
scrolling not supported in any widgets?

Thanks very much,

Tony Mullen

Re: [Pythoncard-users] FloatCanvas position setting

[Alex T. <al...@tw...>]

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.361 / Virus Database: 267.12.5/149 - Release Date: 25/10/2005

Re: [Pythoncard-users] FloatCanvas position setting

[Alex T. <al...@tw...>]

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.361 / Virus Database: 267.12.5/149 - Release Date: 25/10/2005

[Pythoncard-users] FloatCanvas position setting

[Smith, F. <F....@te...>]

The FloatCanvas component appears to ignore any position setting -
whether its set in the ResourceEditor or Code Editor directly. The
resource editor also ignores the setting in the .rsrc.py file. Is this a
bug or correct behaviour. If it's the latter it seems odd.

Can anyone shed some light.

Frank

Re: [Pythoncard-users] Pygame / Pythoncard / system tray Icon

[Alex T. <al...@tw...>]

Mike Pippin wrote:

> I want to use a python card GUI to get information from users and save 
> it to a file then when a button is clicked close the pythonCard gui 
> and start an application running in pygame.....But I also want the 
> ability from the pygame application to close the pygame application 
> and reopen the PythonCard app.....Im having trouble figuring out 
> pythoncard because of the lack of documentation
>  
> ..... How would I start and close a pythoncard app from another module???
>  
> I can get my pythoncard app up and running but only when directly 
> using the module the app is defined in........I am coming close to the 
> deadline of an application and I can restart it without using 
> pythoncard...But I would really prefer not to....So any help I can get 
> asap would be greatly appreciated

Mike, there are three basic approaches you *might* take, and I'm not 
sure which one you are trying (far less which one to recommend).

When you say "start and close a Pythoncard app from another module", I'm 
not sure if you mean "a separate app" of whether you're trying to do 
both within a single application executable.

So this is a kind of generic response to the question - if you can fill 
in more detail of what you need (or want) I can try to be more specific. 
The reason this is difficult is that both wx and pygame like to have 
control of the event loop - so there are likely to be conflicts between them

The three approaches I can see to this overall idea are:

1. A wxPython application, which uses a pygame (SDL) window.
This is perhaps the most complex - there is some discussion of it on 
http://wiki.wxpython.org/index.cgi/IntegratingPyGame
It uses threads and explicit control over the pygame event loop.

2. a dual-mode application (may be easy, may be impossible)
I can't find any examples of other people having tried this - so it may 
be impossible.

But it might be possible to have an overall application in which you 
never have both pygame GUI and wx GUI active. The app would need to 
start one up (say wxPython) - than when it had done everything it needed 
to do, it could simply exit to the main app - which could start up the 
pygame GUI; it in turn would exit and the main app would (if 
appropriate) start the wxPython GUI up again.

I did a simple test of the wxPython part of this - starting and 
re-starting the wxPython event loop, and it appears to work.

Take any of the basic PythonCard applications from the sample directory, 
and you will find at the end of the source something like:

>
> if __name__ == '__main__':
>     app = model.Application(Boids)
>     app.MainLoop()

I simply changed this to


if __name__ == '__main__':
    while 1:
        print "round the main loop again"
        app = model.Application(Boids)
        app.MainLoop()

and the when I exited the PythonCard program, it would again print out 
the message and restart the GUI.

So this gives me some hope it could be done; I don't have pygame 
installed (and can't find a Python2.3 installer for it), so I wasn't 
able to test whether or not you can start / end / restart pygame as easily.

3. Easy, simple, recommended.
Just make them two separate applications.
Have the user run the PythonCard application, gather any data you need, etc.
Then when she clicks on the button, you start another completely 
separate app to run the pygame app. (using os.execl() or similar).
When ready to switch back from the pygame app, do the same thing to 
re-run the initial PythonCard app

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.361 / Virus Database: 267.12.4/146 - Release Date: 21/10/2005

[Pythoncard-users] Pygame / Pythoncard / system tray Icon

[Mike P. <pi...@sh...>]

I want to use a python card GUI to get information from users and save it t=
o
a file then when a button is clicked close the pythonCard gui and start an
application running in pygame.....But I also want the ability from the
pygame application to close the pygame application and reopen the PythonCar=
d
app.....Im having trouble figuring out pythoncard because of the lack of
documentation
 ..... How would I start and close a pythoncard app from another module???
 I can get my pythoncard app up and running but only when directly using th=
e
module the app is defined in........I am coming close to the deadline of an
application and I can restart it without using pythoncard...But I would
really prefer not to....So any help I can get asap would be greatly
appreciated

RE: [Pythoncard-users] Plotting in PythonCard

[Smith, F. <F....@te...>]

VGhlIGFwcGxpY2F0aW9uIEkgYW0gdGhpbmtpbmcgYWJvdXQgaXMgZm9yIGEgZ2VuZXJhbCBidXQg
c2ltcGxlIGdyYXBoaWNzIGVkaXRvciBhbmQgcGxvdCBsYXlvdXQgZWRpdG9yLiBLaW5kIG9mIGxp
a2UgdGhlIHdheSB0aGF0IFBDIFJlc291cmNlIGVkaXRvciB3b3JrcyAtIGJ1dCBjb25zdHJhaW5l
ZCB0byB3b3JraW5nIGluZGl2aWR1YWwgcGxvdHMuDQogDQpJIHdvcmsgaW4gc2F0ZWxsaXRlIG9w
ZXJhdGlvbnMgYW5kIGVtYmVkZGVkIHBsb3R0aW5nIHdpdGhpbiBhIGRpc3BsYXkgaXMgdmVyeSBw
b3B1bGFyLg0KIA0KRnJhbmsgDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9t
OiBCbyBHcmVlbiBbbWFpbHRvOmJvZ3JlZW5Ac3ltcGF0aWNvLmNhXSANCglTZW50OiBGcmkgMTAv
MjEvMjAwNSA0OjE3IFBNIA0KCVRvOiBweXRob25jYXJkLXVzZXJzIA0KCUNjOiANCglTdWJqZWN0
OiBSZTogW1B5dGhvbmNhcmQtdXNlcnNdIFBsb3R0aW5nIGluIFB5dGhvbkNhcmQNCgkNCgkNCg0K
CUknbSB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhpcyB0b3BpYywgYXMgdGhlIFB5dGhvbmNhcmQgYXBw
IEknbSBwcm90b3R5cGluZyAod2hpY2ggaW52b2x2ZXMgc29tZSBzdGF0cykgY291bGQgZXZlbnR1
YWxseSBtYWtlIHVzZSBvZiBzb21lIHByZXR0eSBncmFwaHMuIEknbSBmYW1pbGlhciB3aXRoIFIg
KGFuIG9wZW4gc291cmNlIHN0YXRzIGxhbmd1YWdlIGJhc2VkIG9uIFMpLCBidXQgbm90IHRoZSBv
dGhlcnMuIEFzaWRlIGZyb206DQoJDQoJZnJvbSBzY2lweSBpbXBvcnQgKg0KCQ0KCXdoYXQgYXJl
IHRoZSByZWFzb25zIGZvciBlbWJlZGRpbmcgdGhvc2UgY2FwYWJpbGl0aWVzIGludG8gUHl0aG9u
Y2FyZD8gVGhlIG9ubHkgb25lIEkgY2FuIHRoaW5rIG9mIG9mZiBoYW5kIGlzIGNvbnRyb2xsaW5n
IHdoZXJlIHRoZSBwbG90IGFwcGVhcnMgd3J0IHRoZSBhcHBsaWNhdGlvbiAoaS5lLiBhIGNoaWxk
IHdpbmRvdywgdGFiLCBldGMuKS4gQXJlIHRoZXJlIG90aGVyIHJlYXNvbnM/DQoJQm8NCgkNCgkN
CglTbWl0aCwgRnJhbmsgd3JvdGU6IA0KDQoJCUdyZWV0aW5ncyBhbGwg4oCmLiBJdCdzIGEgYml0
IHF1aWV0IG9uIHRoZSBsaXN0IHRvZGF5ISANCgkJICANCgkJSGFzIGFueW9uZSBnaXZlbiBhbnkg
dGhvdWdodCB0byBhZGRpbmcgb3IgZW1iZWRkaW5nIHBsb3R0aW5nIGNhcGFiaWxpdGllcyB3aXRo
aW4gUHl0aG9uQ2FyZD8gQSBjb3VwbGUgb2YgeWVhcnMgYWdvIHRoZXJlIHdhcyBzb21lIHRob3Vn
aHQgb2YgYWRkaW5nIGEgY29tcG9uZW50IGJhc2VkIG9uIHd4UHlQbG90LiBVbmZvcnR1bmF0ZWx5
LCBhbmQgcGxlYXNlIHNvbWVvbmUgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcsIHd4UHlQbG90IGRv
ZXNuJ3Qgc3VwcG9ydCB4LWF4aXMgdGltZSBhbmQgZGF0ZSB0aWNrcyB3aGljaCBpcyBvbmUgb2Yg
c3BlY2lmaWMgY2FwYWJpbGl0aWVzIEknbSBsb29raW5nIGZvci4gSSdtIG1vcmUgaW50ZXJlc3Rl
ZCBpbiBTY2lQeS9NYXRwbG90bGliIGludGVncmF0aW9uIC0gSSBiZWxpZXZlIHRoYXQgc3VjaCBh
IG1hcnJpYWdlIHdvdWxkIHJlc3VsdCBpbiBhIHZlcnkgcG93ZXJmdWwgZGV2ZWxvcG1lbnQgdG9v
bC4gVGhlIGFyY2hpdmUgaGFzIHRoZSBmb2xsb3dpbmcgZnJvbSBLZXZpbiAoYmFzZWQgb24gYW4g
ZXhjaGFuZ2Ugb2YgaWRlYXMgd2l0aCB0aGUgU2NpUHkgZGV2ZWxvcG1lbnQgdGVhbSkgZnJvbSB3
YXkgYmFjayBpbiAyMDAxIGJ1dCBpdCBkb2Vzbid0IGFwcGVhciB0byBoYXZlIGdlbmVyYXRlZCBt
dWNoIGludGVyZXN0IG9yIGRpc2N1c3Npb24uIFBlcmhhcHMgbWVtYmVycyBmZWVsIHRoYXQgYWRk
aW5nIGNhcGFiaWxpdGllcyBnb2VzIGJleW9uZCB0aGUgc2NvcGUgYW5kIHNwaXJpdCBvZiBQeXRo
b25DYXJkLg0KDQoJCUZyYW5rIA0KDQoJCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KCQlJ
IGRpc2NvdmVyZWQgU2NpUHkgaHR0cDovL3d3dy5zY2lweS5vcmcvIDxodHRwOi8vd3d3LnNjaXB5
Lm9yZy8+ICB0d28gZGF5cyBhZ28uIE9yaWdpbmFsbHksIEkgd2FzIGludGVyZXN0ZWQgaW4gZ3Jh
cGhpYyBmb3JtYXQgY29udmVyc2lvbnMsIHN1Y2ggYXMgbnVtZXJpY2FsIGFycmF5cyAoTnVtUHkp
IHRoYXQgd2UgbWlnaHQgbmVlZCB0byBzdXBwb3J0IGluIFB5dGhvbkNhcmQgc2ltaWxhciB0byB0
aGUgc3VwcG9ydCBJIGFkZGVkIGZvciBQSUwuIEkgc3RpbGwgbmVlZCBtb3JlIGZlZWRiYWNrIG9u
IHdoYXQgc2hvdWxkIGJlIHB1dCBpbiB0aGUgUHl0aG9uQ2FyZCBmcmFtZXdvcmsgZm9yIFBJTCBh
bmQgTnVtUHkuIE1lYW53aGlsZSwgSSJ2ZSBiZWVuIGluIGNvbnRhY3Qgd2l0aCBFcmljIEpvbmVz
IG9mIHRoZSBTY2lQeSB0ZWFtIGFuZCBoYXZlIGluc3RhbGxlZCBTY2lQeSBhbmQgcnVuIHRocm91
Z2ggdGhlIHR1dG9yaWFscyBhdDogaHR0cDovL3d3dy5zY2lweS5vcmcvc2l0ZV9jb250ZW50L3R1
dG9yaWFscy9wbG90X3R1dG9yaWFsIDxodHRwOi8vd3d3LnNjaXB5Lm9yZy9zaXRlX2NvbnRlbnQv
dHV0b3JpYWxzL3Bsb3RfdHV0b3JpYWw+ICBTaW5jZSB0aGUgcGx0IG1vZHVsZSBvZiBTY2lQeSBp
cyBiYXNlZCBvbiB3eFB5dGhvbiB5b3UgY2FuIGRyaXZlIHBsdCBmcm9tIHRoZSBQeXRob25DYXJk
IHNoZWxsIChQeUNydXN0KSB3aXRob3V0IG5lZWRpbmcgdGhlIGxpbmU6ID4+PiBpbXBvcnQgZ3Vp
X3RocmVhZCBnbnVwbG90IGFsc28gc2VlbXMgdG8gd29yayBmaW5lLCBidXQgSSBkaWRuInQgdXNl
IGl0IGZvciB2ZXJ5IGxvbmcgc28gdGhlcmUgbWF5IGJlIHNvbWUgd2luZG93IG1hbmFnZXIgY29u
ZmxpY3RzIGJldHdlZW4gZ251cGxvdCBhbmQgd3hQeXRob24uIEFzIGEgc2ltcGxlIGV4ZXJjaXNl
IEkgbW9kaWZpZWQgbWluaW1hbC5weSB0byBzaW1wbGlmeSBkYXRhIGlucHV0LCBhIHNjcmVlbiBz
aG90IGlzIGF0dGFjaGVkLiBUaGlzIHdpbGwgcHJvYmFibHkgYmUgZXhwYW5kZWQgYW5kIGJlY29t
ZSBhbm90aGVyIHNhbXBsZSBmb3IgUHl0aG9uQ2FyZDsgdGhlIHNhbXBsZSB3aWxsIHJlcXVpcmUg
U2NpUHkgd2hpY2ggaW5jbHVkZXMvcmVxdWlyZXMgTnVtUHkuIFRoZSBzaG9ydCBzdG9yeSBpcyB0
aGF0IFB5dGhvbkNhcmQgYW5kIFNjaVB5IHNlZW0gbGlrZSBhIGdvb2QgbWF0Y2guIFRoZSBxdWVz
dGlvbiBiZWNvbWVzIHdoYXQgbGV2ZWwgb2YgaW50ZWdyYXRpb24gYW5kIG92ZXJsYXAgc2hvdWxk
IHdlIGhhdmUgYmV0d2VlbiB0aGUgdHdvIHByb2plY3RzLiBJIGRvbiJ0IGtub3cgbXVjaCBhYm91
dCB0aGUgcmVxdWlyZW1lbnRzIGZvciAic2NpZW50aWZpYyBjb21wdXRpbmciIHNvIHJpZ2h0IG5v
dyBJIm0gYXQgdGhlIHN0YWdlIG9mIGFza2luZyBuZXdiaWUgcXVlc3Rpb25zIGFib3V0IHdoYXQg
c2NpZW50aWZpYyB1c2VycyBuZWVkIGluIGEgR1VJIGZyYW1ld29yayBhbmQgZW52aXJvbm1lbnQu
IEkgdGhvdWdodCBFcmljInMgcmVzcG9uc2UgYmVsb3cgd2FzIHdvcnRoIGZvcndhcmRpbmcgdG8g
dGhlIGxpc3QgaW4gY2FzZSBvdGhlciBwZW9wbGUgaGF2ZSBzdWdnZXN0aW9ucyBvbiBob3cgUHl0
aG9uQ2FyZCBjYW4gYmUgYSB1c2VmdWwgdG9vbCBpbiBzY2llbmNlLiBJZiB5b3UicmUgb24gdGhl
IFB5dGhvbkNhcmQgbGlzdCBhcmUgaW50ZXJlc3RlZCBpbiB0aGlzIHRvcGljLCBwbGVhc2Ugc3Bl
YWsgdXAuDQoNCgkJS2EgDQoJCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCQlGcm9tOiBl
cmljIGpvbmVzIFttYWlsdG86ZXJpY0Blbi4uLiA8bWFpbHRvOmVyaWNAZW4uLi4+IF0gDQoJCVNl
bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDExLCAyMDAxIDEwOjUzIEFNIA0KCQlUbzogS2V2aW4gQWx0
aXMgDQoJCVN1YmplY3Q6IFJlOiBzb21lIG90aGVyIHF1ZXN0aW9ucyBvbiBzY2lweSANCgkJSSBu
b3RpY2VkIFNjaUdyYXBoaWNhIHRvZGF5IG9uIHRoZSBTRiBQeXRob24gbGlzdC4gaHR0cDovL3Nv
dXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9zY2lncmFwaGljYS8gPGh0dHA6Ly9zb3VyY2Vmb3JnZS5u
ZXQvcHJvamVjdHMvc2NpZ3JhcGhpY2EvPiAgIEl0IG9ubHkgd29ya3Mgb24gTGludXgsIGJ1dCBJ
IGd1ZXNzIHRoaXMgaXMgYSAiY29tcGV0aXRvciIgb2Ygc29ydHM/IE5vdCByZWFsbHkgYSBjb21w
ZXRpdG9yIC0tIFNjaVB5IGhhcyBhIGh1Z2UgYW1vdW50IG9mIE51bWVyaWNhbCBjYWxjdWxhdGlv
biBzdHVmZiB0aGF0IGlzIG9ydGhvZ29uYWwgdG8gU2NpR3JhcGhpY2EicyBlZmZvcnQuIFRoZXkg
YXJlIHJlYWxseSBhYm91dCBtYWtpbmcgaXQgZWFzeSB0byBidWlsZCBwcmV0dHkgcGxvdHMuIEki
bSB2ZXJ5IGluIHRoYXQgcHJvamVjdCBhcyB0aGV5IGxvb2sgdG8gaGF2ZSB0YWtlbiB0aGUgZ3Jh
cGhpY3MgYSB2ZXJ5IGxvbmcgd2F5LiBGdXJ0aGVyLCB0aGV5IGFyZSBwbGFubmluZyBvbiBicmVh
a2luZyB0aGluZ3Mgb3V0IHRvIG1ha2UgdGhlbSBhY2Nlc2libGUgZnJvbSBQeXRob24gY29tbWFu
ZCBsaW5lIGluIHRoZSBuZXh0IHZlcnNpb24gd2hpY2ggbWVhbnMgdGhleSBjYW4gYmUgdXNlZCBy
aWdodCBhbG9uZyB3aXRoIFNjaVB5LiBUaGUgYmlnIHByb2JsZW0gd2l0aCBTY2lHcmFwaGljYSBp
cyBpdHMgYmFzZWQgb24gR1RLLiBHVEsgbG9va3MgYmFkIG9uIFdpbmRvd3MsIGlzbiJ0IGVhc3kg
dG8gaW5zdGFsbCwgYW5kIGlzbiJ0IHN0YWJsZS4gV2luZG93cyBpcyBhIG1ham9yIHBsYXRmb3Jt
IGFuZCBTY2lQeSBoYXMgdG8gc3VwcG9ydCBpdCBhcyB3ZWxsIGFzLCBvciBldmVuIGJldHRlciB0
aGFuIExpbnV4LCB0byBiZSB2aWFibGUuIEFmdGVyIGFsbCwgTGludXggcGVvcGxlIGFyZSB1c2Vk
IHRvIGZpZGRsaW5nIHdpdGggdGhpbmdzIHRvIGdldCB0aGVtIHRvIHdvcmsuIFdpbmRvd3MgcGVv
cGxlIGFyZW4idC4gVGhhdCBtZWFucyBHVEsgaXNuInQgYSB2aWFibGUgb3B0aW9uIGluIG15IHZp
ZXcuIE9uIHRoZSBvdGhlciBoYW5kLCBJIGhhdmUgd29uZGVyZWQgaG93IGhhcmQgaXQgaXMgdG8g
c3dpdGNoIHRoaXMgZ2VuZXJhbCBmcmFtZXdvcmsgb3ZlciB0byB3eFB5dGhvbiBvciBldmVuIHRy
eSB0byBzZXQgaXQgdXAgc28gaXQgaXMgYmFja2VuZCBpbmRlcGVuZGVudC4gSSBoYXZlIGJlZW4g
dGFsa2luZyB3aXRoIHRoZSBndXlzIGF0IHRoZSBTcGFjZSBUZWxlc2NvcGUgSW5zdGl0dXRlICh0
aGV5IHJ1biBIdWJibGUpLCBhbmQgdGhleSBhcmUgYWxzbyB2ZXJ5IGludGVyZXN0ZWQgaW4gZ3Jh
cGhpY3Mgc3R1ZmYuIFdlIGhhdmUgcGl0Y2hlZCBhcm91bmQgdGhpcyBpZGVhIHF1aXRlIGEgYml0
IGluIHRoZSBsYXN0IGZldyB3ZWVrcywgYnV0IGhhdmVuInQgZm9ybWFsaXplZCBhIHNldCBvZiBz
cGVjcyBvciBhIGdhbWUgcGxhbiB5ZXQgd2l0aCByZWdhcmRzIHRvIHRoaXMuIFdlIGFyZSBhbHNv
IGxvb2tpbmcgaGFyZCBhdCB1c2luZyBWVEsgKHd3dy5raXR3YXJlLmNvbSA8ZmlsZTovL3d3dy5r
aXR3YXJlLmNvbT4gKSBmb3IgYWxsIDNEIHN0dWZmLiBUaGVyZSBhcmUgYmVuZWZpdHMgYW5kIGRy
YXdiYWNrcyB0byB0aGlzIHRoYXQgYXJlIHN0aWxsIHVuZGVyIGNvbnNpZGVyYXRpb24uID4gV2hh
dCBhcmUgb3RoZXIgY29tcGFyYWJsZSBwYWNrYWdlcywgYW55dGhpbmcgZHJpdmVuIGJ5IFB5dGhv
biBvciB0aGF0IFB5dGhvbiA+IGludGVyZmFjZXMgdG8/IEkibSBqdXN0IHRyeWluZyB0byB1bmRl
cnN0YW5kIHRoZSBib3VuZHMgb2YgdGhlIHByb2JsZW0gdGhhdCA+IG5lZWRzIHRvIGJlIGFkZHJl
c3NlZC4gSSBkb24idCB0aGluayBTY2lQeSByZWFsbHkgaGFzIGEgY29tcGV0aXRvci4gVGhlIFNj
aWVudGlmaWMgUHl0aG9uIHByb2plY3QgYnkgS29ucmFkIEhpbnNlbiBpcyBzaW1pbGFyLCBidXQg
aXMgc2xpZ2h0bHkgbW9yZSBmb2N1c2VkIG9uIGNvbXB1dGF0aW9uYWwgY2hlbWlzdHJ5LiBUaGUg
bW9zdCBzaW1pbGFyIHBhY2thZ2UgdG8gU2NpUHkgd291bGQgYmUgTWF0bGFiIChvciBPY3RhdmUg
aW4gdGhlIE9wZW4gU291cmNlIHZlcnNpb24pLiBOYXRpb25hbCBJbnN0cnVtZW50cyBoYXMgYSBs
ZXNzIHVzZWQgb25lIGNhbGxlZCBIaVEuIFRoZXJlIGlzIGFsc28gSURMLCBNYXRoZW1hdGljYSwg
TWFwbGUsIGV0Yy4gd2hpY2ggc2VydmUgYSBzaW1pbGFyIHB1cnBvc2UuIFRoZSBnZW5lcmFsIGdv
YWwgb2YgU2NpUHkgaXMgdG8gbWFrZSBweXRob24gYSB2aWFibGUgYWx0ZXJuYXRpdmUgdG8gdGhl
c2UgdG9vbHMgYW5kIHRoZW4gbGV2ZXJhZ2UgdGhlIHBvd2VyIG9mIFB5dGhvbiB0byB0YWtlIGl0
IGJleW9uZCB0aGVtLiBJZiB5b3UgaGF2ZSBhY2Nlc3MgdG8gTWF0bGFiLCB5b3UgbWlnaHQgdHJ5
IGl0IG91dC4gT2N0YXZlIGlzIGxlc3MgdXNlZnVsLCBidXQgc3RpbGwgYSByZWFzb25hYmxlIHRo
aW5nIHRvIGxvb2sgYXQuIEkidmUgYWxzbyBoZWFyZCBvZiBhIGxhbmd1YWdlIGNhbGxlZCBSIHRo
YXQgaXMgT1MgdGhhdCBtaWdodCBzZXJ2ZSBzaW1pbGFyIHB1cnBvc2VzLiBTbyBTY2lQeSBwcm9w
ZXIgSSBndWVzcyBmb2N1c2VzIG9uIHR3byB0aGluZ3M6IHNjaWVudGlmaWMgbGlicmFyaWVzIGFu
ZCB2aXN1YWxpemluZyBkYXRhLiBXZSB3YW50IHRvIG1ha2UgaXQgZWFzeSB0byBkbyBzY2llbnRp
ZmljIHN0dWZmIGluIFB5dGhvbiBhcyB3ZWxsIGFzIG1ha2Ugc3VyZSB0aGF0IHRoZSB0b29scyBv
ciBhbGdvcml0aG1zL3NjcmlwdHMgZGV2ZWxvcGVkIHdpdGggU2NpUHkgY2FuIGJlIGRyb3BwZWQg
aW50byBsYXJnZXIgYXBwcyB3aXRoIG1pbmltYWwgZnVzcy4gVGhpbmdzIGxpa2UgdHVydGxlIG1p
Z2h0IGFjdHVhbGx5IGhhdmUgYSBwbGFjZSBpbiB0aGUgdmlzdWFsaXphdGlvbiBzZWN0aW9uLiBU
aGUgR1VJIGJ1aWxkaW5nIGVuZCwgYXQgbGVhc3QgcmlnaHQgbm93LCBpcyBzdHVmZiB3ZSJkIGxp
a2UgdG8gYm9ycm93IGZyb20geW91IGd1eXMgdGhhdCBrbm93IHdoYXQgaXMgZ29pbmcgb24gaW4g
dGhhdCBhcmVuYSBvZiBQeXRob24uIExhdGVyLCB3ZSBtaWdodCBoYXZlIGEgZnVsbCBibG93biBH
VUkgd2l0aCBhbGwgdGhpcyBzdHVmZiBhdmFpbGFibGUgdG9nZXRoZXIgdGhvdWdoLiBJIm0gdmVy
eSBnbGFkIHlvdXIgcGxheWluZyB3aXRoIFNjaVB5IGJlY2F1c2UgY29tYmluaW5nIFNjaVB5IHdp
dGggUHl0aG9uQ2FyZCBpcyAqZXhhY3RseSogd2hhdCBpcyBzbyBwb3dlcmZ1bCBhYm91dCBidWls
ZGluZyBpdCBpbiBQeXRob24gLS0gYW5kIEkibSBjb3VudGluZyBvbiB5b3UgZXQgYWwuIHRvIHRo
aW5rIG9mIHRoaW5ncyB3ZSBuZXZlciBoYWQuIDopIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBTRi5OZXQgZW1haWwgaXMg
c3BvbnNvcmVkIGJ5OiBQb3dlciBBcmNoaXRlY3R1cmUgUmVzb3VyY2UgQ2VudGVyOiBGcmVlIGNv
bnRlbnQsIGRvd25sb2FkcywgZGlzY3Vzc2lvbnMsIGFuZCBtb3JlLiBodHRwOi8vc29sdXRpb25z
Lm5ld3Nmb3JnZS5jb20vaWJtYXJjaC50bXBsIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fIFB5dGhvbmNhcmQtdXNlcnMgbWFpbGluZyBsaXN0IFB5dGhvbmNh
cmQtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2Uu
bmV0L2xpc3RzL2xpc3RpbmZvL3B5dGhvbmNhcmQtdXNlcnMNCg==

Re: [Pythoncard-users] Plotting in PythonCard

[Bo G. <bo...@sy...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
I'm very interested in this topic, as the Pythoncard app I'm
prototyping (which involves some stats) could eventually make use of
some pretty graphs. I'm familiar with R (an open source stats language
based on S), but not the others. Aside from:<br>
<br>
from scipy import *<br>
<br>
what are the reasons for embedding those capabilities into Pythoncard?
The only one I can think of off hand is controlling where the plot
appears wrt the application (i.e. a child window, tab, etc.). Are there
other reasons?<br>
Bo<br>
<br>
<br>
Smith, Frank wrote:
<blockquote
 cite="mid...@em...rp"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="MS Exchange Server version 6.0.6249.1">
  <title>Plotting in PythonCard</title>
<!-- Converted from text/rtf format -->
  <p><font face="Times New Roman">Greetings all &#8230;. It's a bit quiet on
the list today!</font>
  <br>
  <font face="Times New Roman">&nbsp;</font>
  <br>
  <font face="Times New Roman">Has anyone given any thought to adding
or embedding plotting capabilities within PythonCard? A couple of years
ago there was some thought of adding a component based on wxPyPlot.
Unfortunately, and please someone correct me if I'm wrong, wxPyPlot
doesn't support x-axis time and date ticks which is one of specific
capabilities I'm looking for. I'm more interested in SciPy/Matplotlib
integration - I believe that such a marriage would result in a very
powerful development tool. The archive has the following from Kevin
(based on an exchange of ideas with the SciPy development team) from
way back in 2001 but it doesn't appear to have generated much interest
or discussion. Perhaps members feel that adding capabilities goes
beyond the scope and spirit of PythonCard.</font></p>
  <p><font face="Times New Roman">Frank</font>
  </p>
  <p><font face="Times New Roman">--------------------------</font>
  <br>
  <font face="Times New Roman">I discovered SciPy </font><a
 href="http://www.scipy.org/"><u><font color="#0000ff"
 face="Times New Roman">http://www.scipy.org/</font></u></a><font
 face="Times New Roman"> two days ago. Originally, I was interested in
graphic format conversions, such as numerical arrays (NumPy) that we
might need to support in PythonCard similar to the support I added for
PIL. I still need more feedback on what should be put in the PythonCard
framework for PIL and NumPy. Meanwhile, I"ve been in contact with Eric
Jones of the SciPy team and have installed SciPy and run through the
tutorials at: </font><a
 href="http://www.scipy.org/site_content/tutorials/plot_tutorial"><u><font
 color="#0000ff" face="Times New Roman">http://www.scipy.org/site_content/tutorials/plot_tutorial</font></u></a><font
 face="Times New Roman"> Since the plt module of SciPy is based on
wxPython you can drive plt from the PythonCard shell (PyCrust) without
needing the line: &gt;&gt;&gt; import gui_thread gnuplot also seems to
work fine, but I didn"t use it for very long so there may be some
window manager conflicts between gnuplot and wxPython. As a simple
exercise I modified minimal.py to simplify data input, a screen shot is
attached. This will probably be expanded and become another sample for
PythonCard; the sample will require SciPy which includes/requires
NumPy. The short story is that PythonCard and SciPy seem like a good
match. The question becomes what level of integration and overlap
should we have between the two projects. I don"t know much about the
requirements for "scientific computing" so right now I"m at the stage
of asking newbie questions about what scientific users need in a GUI
framework and environment. I thought Eric"s response below was worth
forwarding to the list in case other people have suggestions on how
PythonCard can be a useful tool in science. If you"re on the PythonCard
list are interested in this topic, please speak up.</font></p>
  <p><font face="Times New Roman">Ka</font>
  <br>
  <font face="Times New Roman">-----Original Message----- </font>
  <br>
  <font face="Times New Roman">From: eric jones [</font><a
 href="mailto:eric@en..."><u><font color="#0000ff"
 face="Times New Roman">mailto:eric@en...</font></u></a><font
 face="Times New Roman">]</font>
  <br>
  <font face="Times New Roman">Sent: Thursday, October 11, 2001 10:53
AM </font>
  <br>
  <font face="Times New Roman">To: Kevin Altis </font>
  <br>
  <font face="Times New Roman">Subject: Re: some other questions on
scipy </font>
  <br>
  <font face="Times New Roman">I noticed SciGraphica today on the SF
Python list. </font><a
 href="http://sourceforge.net/projects/scigraphica/"><u><font
 color="#0000ff" face="Times New Roman">http://sourceforge.net/projects/scigraphica/</font></u></a><font
 face="Times New Roman">&nbsp; It only works on Linux, but I guess this is a
"competitor" of sorts? Not really a competitor -- SciPy has a huge
amount of Numerical calculation stuff that is orthogonal to
SciGraphica"s effort. They are really about making it easy to build
pretty plots. I"m very in that project as they look to have taken the
graphics a very long way. Further, they are planning on breaking things
out to make them accesible from Python command line in the next version
which means they can be used right along with SciPy. The big problem
with SciGraphica is its based on GTK. GTK looks bad on Windows, isn"t
easy to install, and isn"t stable. Windows is a major platform and
SciPy has to support it as well as, or even better than Linux, to be
viable. After all, Linux people are used to fiddling with things to get
them to work. Windows people aren"t. That means GTK isn"t a viable
option in my view. On the other hand, I have wondered how hard it is to
switch this general framework over to wxPython or even try to set it up
so it is backend independent. I have been talking with the guys at the
Space Telescope Institute (they run Hubble), and they are also very
interested in graphics stuff. We have pitched around this idea quite a
bit in the last few weeks, but haven"t formalized a set of specs or a
game plan yet with regards to this. We are also looking hard at using
VTK (</font><a moz-do-not-send="true" href="file://www.kitware.com"><u><font
 color="#0000ff" face="Times New Roman">www.kitware.com</font></u></a><font
 face="Times New Roman">) for all 3D stuff. There are benefits and
drawbacks to this that are still under consideration. &gt; What are
other comparable packages, anything driven by Python or that Python
&gt; interfaces to? I"m just trying to understand the bounds of the
problem that &gt; needs to be addressed. I don"t think SciPy really has
a competitor. The Scientific Python project by Konrad Hinsen is
similar, but is slightly more focused on computational chemistry. The
most similar package to SciPy would be Matlab (or Octave in the Open
Source version). National Instruments has a less used one called HiQ.
There is also IDL, Mathematica, Maple, etc. which serve a similar
purpose. The general goal of SciPy is to make python a viable
alternative to these tools and then leverage the power of Python to
take it beyond them. If you have access to Matlab, you might try it
out. Octave is less useful, but still a reasonable thing to look at.
I"ve also heard of a language called R that is OS that might serve
similar purposes. So SciPy proper I guess focuses on two things:
scientific libraries and visualizing data. We want to make it easy to
do scientific stuff in Python as well as make sure that the tools or
algorithms/scripts developed with SciPy can be dropped into larger apps
with minimal fuss. Things like turtle might actually have a place in
the visualization section. The GUI building end, at least right now, is
stuff we"d like to borrow from you guys that know what is going on in
that arena of Python. Later, we might have a full blown GUI with all
this stuff available together though. I"m very glad your playing with
SciPy because combining SciPy with PythonCard is *exactly* what is so
powerful about building it in Python -- and I"m counting on you et al.
to think of things we never had. :) </font></p>
</blockquote>
<br>
</body>
</html>

[Pythoncard-users] Plotting in PythonCard

[Smith, F. <F....@te...>]

Greetings all .... It's a bit quiet on the list today!
=20
Has anyone given any thought to adding or embedding plotting
capabilities within PythonCard? A couple of years ago there was some
thought of adding a component based on wxPyPlot. Unfortunately, and
please someone correct me if I'm wrong, wxPyPlot doesn't support x-axis
time and date ticks which is one of specific capabilities I'm looking
for. I'm more interested in SciPy/Matplotlib integration - I believe
that such a marriage would result in a very powerful development tool.
The archive has the following from Kevin (based on an exchange of ideas
with the SciPy development team) from way back in 2001 but it doesn't
appear to have generated much interest or discussion. Perhaps members
feel that adding capabilities goes beyond the scope and spirit of
PythonCard.

Frank

--------------------------
I discovered SciPy http://www.scipy.org/ two days ago. Originally, I was
interested in graphic format conversions, such as numerical arrays
(NumPy) that we might need to support in PythonCard similar to the
support I added for PIL. I still need more feedback on what should be
put in the PythonCard framework for PIL and NumPy. Meanwhile, I"ve been
in contact with Eric Jones of the SciPy team and have installed SciPy
and run through the tutorials at:
http://www.scipy.org/site_content/tutorials/plot_tutorial Since the plt
module of SciPy is based on wxPython you can drive plt from the
PythonCard shell (PyCrust) without needing the line: >>> import
gui_thread gnuplot also seems to work fine, but I didn"t use it for very
long so there may be some window manager conflicts between gnuplot and
wxPython. As a simple exercise I modified minimal.py to simplify data
input, a screen shot is attached. This will probably be expanded and
become another sample for PythonCard; the sample will require SciPy
which includes/requires NumPy. The short story is that PythonCard and
SciPy seem like a good match. The question becomes what level of
integration and overlap should we have between the two projects. I don"t
know much about the requirements for "scientific computing" so right now
I"m at the stage of asking newbie questions about what scientific users
need in a GUI framework and environment. I thought Eric"s response below
was worth forwarding to the list in case other people have suggestions
on how PythonCard can be a useful tool in science. If you"re on the
PythonCard list are interested in this topic, please speak up.
Ka
-----Original Message-----=20
From: eric jones [mailto:eric@en...]
Sent: Thursday, October 11, 2001 10:53 AM=20
To: Kevin Altis=20
Subject: Re: some other questions on scipy=20
I noticed SciGraphica today on the SF Python list.
http://sourceforge.net/projects/scigraphica/  It only works on Linux,
but I guess this is a "competitor" of sorts? Not really a competitor --
SciPy has a huge amount of Numerical calculation stuff that is
orthogonal to SciGraphica"s effort. They are really about making it easy
to build pretty plots. I"m very in that project as they look to have
taken the graphics a very long way. Further, they are planning on
breaking things out to make them accesible from Python command line in
the next version which means they can be used right along with SciPy.
The big problem with SciGraphica is its based on GTK. GTK looks bad on
Windows, isn"t easy to install, and isn"t stable. Windows is a major
platform and SciPy has to support it as well as, or even better than
Linux, to be viable. After all, Linux people are used to fiddling with
things to get them to work. Windows people aren"t. That means GTK isn"t
a viable option in my view. On the other hand, I have wondered how hard
it is to switch this general framework over to wxPython or even try to
set it up so it is backend independent. I have been talking with the
guys at the Space Telescope Institute (they run Hubble), and they are
also very interested in graphics stuff. We have pitched around this idea
quite a bit in the last few weeks, but haven"t formalized a set of specs
or a game plan yet with regards to this. We are also looking hard at
using VTK (www.kitware.com) for all 3D stuff. There are benefits and
drawbacks to this that are still under consideration. > What are other
comparable packages, anything driven by Python or that Python >
interfaces to? I"m just trying to understand the bounds of the problem
that > needs to be addressed. I don"t think SciPy really has a
competitor. The Scientific Python project by Konrad Hinsen is similar,
but is slightly more focused on computational chemistry. The most
similar package to SciPy would be Matlab (or Octave in the Open Source
version). National Instruments has a less used one called HiQ. There is
also IDL, Mathematica, Maple, etc. which serve a similar purpose. The
general goal of SciPy is to make python a viable alternative to these
tools and then leverage the power of Python to take it beyond them. If
you have access to Matlab, you might try it out. Octave is less useful,
but still a reasonable thing to look at. I"ve also heard of a language
called R that is OS that might serve similar purposes. So SciPy proper I
guess focuses on two things: scientific libraries and visualizing data.
We want to make it easy to do scientific stuff in Python as well as make
sure that the tools or algorithms/scripts developed with SciPy can be
dropped into larger apps with minimal fuss. Things like turtle might
actually have a place in the visualization section. The GUI building
end, at least right now, is stuff we"d like to borrow from you guys that
know what is going on in that arena of Python. Later, we might have a
full blown GUI with all this stuff available together though. I"m very
glad your playing with SciPy because combining SciPy with PythonCard is
*exactly* what is so powerful about building it in Python -- and I"m
counting on you et al. to think of things we never had. :)=20

Re: [Pythoncard-users] "tail"ing a file

[Alex T. <al...@tw...>]

Cory Riddell wrote:

>I used PythonCard to create a simple gui front end to a program that
>dumps all of its output to a log file. What's the best way to show
>that log file in a text control? I'd like it to be continuously
>updated, just like the Unix tail command.
>
>Any advice?
>
>  
>
There's probably a better way (or any number of better ways :-), but ....

you can do it with a simple timer that reads from the file and appends 
to the text control will do it
(That's assuming you don't mind the text control growing to keep all the 
content - if you don't want that you'll need to do a bit more to trim 
data off the front ....)

I tried a very simple example, where there was just a TextArea, and the 
code just had

>     def on_initialize(self, event):
>         # if you have any initialization
>         # including sizer setup, do it here
>         self.f = open("log.txt")
>         self.tmr = timer.Timer(self.components.Log, -1)
>         self.tmr.start(1000)
>         pass
>
>     def on_Log_timer(self, event):
>         t = self.f.read()
>         if t == "": return
>         self.components.Log.AppendText(t)
>         return

this works for files being extended by saving from Emacs, and from "cat 
 > log.txt" in Cygwin - but you should obviously check it with one of 
your log files while it is being extended.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.14/127 - Release Date: 10/10/2005

Re: [Pythoncard-users] Installing from source code

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

Andrew L. Gould wrote:
> How do I install PythonCard from source code?  I didn't see a Makefile,
> so I assume it's not the usual "make; make install" routine.
> 
> I'm running FreeBSD 5.4.
> 
> Thanks,
> 
> Andrew
> 

Unpack the .tar.gz file and then at the command prompt use the usual 
Python routine;

$ python setup.py install

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

[Pythoncard-users] "tail"ing a file

[Cory R. <cgr...@gm...>]

I used PythonCard to create a simple gui front end to a program that
dumps all of its output to a log file. What's the best way to show
that log file in a text control? I'd like it to be continuously
updated, just like the Unix tail command.

Any advice?

Cory

[Pythoncard-users] "tail"ing a file

[Cory R. <cgr...@gm...>]

I used PythonCard to create a simple gui front end to a program that
dumps all of its output to a log file. What's the best way to show
that log file in a text control? I'd like it to be continuously
updated, just like the Unix tail command.

Any advice?

Cory

Re: [Pythoncard-users] Re: Pythoncard mental block

[Alex T. <al...@tw...>]

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date: 06/10/2005
=

[Pythoncard-users] [ANN] Dabo 0.4.2 released!

[Ed L. <ed...@le...>]

     We are pleased to announce the 0.4.2 release of Dabo, the 3-tier  
application framework for Python.

     The primary focus of our work for this release has been a  
tightening up of the various properties of many of the UI controls to  
create a more consistent interface. Since these controls were  
developed one at a time as needed, they had some subtle but  
significant differences in the way they worked. This release  
addresses a lot of those concerns.

     We've also added auto-binding of methods to events. For example,  
if you want to have your code react to MouseEnter event, all you need  
to do is add a method named onMouseEnter(), and Dabo will bind it to  
that event. Thanks to the PythonCard folks for this idea!

     Work on the Report Writer continues to proceed; it now supports  
groups and report variables. These improvements have been integrated  
it into the wizard-generated apps, too.

     Needless to say, there have also been a few bug fixes. A list of  
all the changes follows my sig. You can grab the latest, as always,  
from http://dabodev.com/download.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dabo-0.4.2 (2005-10-07) (Revision 1418):
Added PrimaryBizobj property to dForm, which can replace calls to  
getPrimaryBizobj().

Added Accepted property to dOkCancelDialog, which gets set  
automatically if the
user pressed "OK".

Added AutoSQL, UserSQL, CurrentSQL, LastSQL properties to dCursor and  
dBizobj.
When time to requery, the SQL will come from UserSQL if set, or  
AutoSQL will
be regenerated.

Fixed a bug that kept changes to a new record from getting committed.

Added DefaultValues property to bizobj.

Added ListSelection and ListDeselection events to dListControl. Added  
properties
MultipleSelect, HitIndex, LastSelectedIndex, HeaderVisible,  
HorizontalRules,
and VerticalRules. Changed the behavior of both dListControl and  
dListBox so that merely selecting an item doesn't raise the Hit  
event; instead, it raises a ListSelection event, and if another item  
had been previously selected, it raises a ListDeselection event. Hit  
is only raised from double-clicking on an item, or by pressing Enter.

Added new property to dTextBox: StrictDateEntry. Changed the code for
interpreting dates entered by the user to allow for some less explicit
formats (YYYYMMDD, YYMMDD, and MMDD). If StrictDateEntry is False (the
default), these other formats will be used when interpreting dates
entered by the user.

Added field-level validation to the framework.

Improved support for decimal.Decimal, both at the database level and in
dTextBox.

Added new auto event binding, which automatically binds events based  
on any
defined callback functions. For example, if you have a method  
onMouseEnter()
defined, the dEvents.MouseEnter will automatically be bound to that  
method.
Inspired by PythonCard.

Added RegID property to forms, that allows for object registration
with the form. Not all objects require RegIDs, but if they have one,
they must be unique among all objects in a form. A reference to that
object can then be gotten from any other object by calling
'self.Form.getObjectByRegID(<regid>)'.

Linked RegID to the auto event binding, so that if a form has a method
of onHit_cmdOK(), and has a button with a RegID of 'cmdOK', the
cmdOk's Hit will get bound to the form's callback, automatically.

Improved dGrid and dColumn. Many properties added, and you are now in  
much
finer control over the display of grid column headers, grid cell  
attributes,
grid cell editors and renderers, and the grid itself.

Began work of allowing case-insensitive property values for  
properties that
take string values, and for properties that take a limited number of  
values
where the first letter is unique, you can set the property by just  
using the
first letter. dTextBox.Alignment = "c" sets the property to "Center",  
for
example.

Modified dBizobj, dCursorMixin, and dBackend so that the user can  
specify
the Unicode Encoding to use. Changed the default encoding from  
latin-1 to
utf-8.

Added feature to optionally draw sizer outlines on any form that uses  
dSizers.
This is currently accessible via an option in the View menu when the  
base
menu bar is in use, or you can turn it on/off programatically.

Grids now remember the column that is sorted, and resort when next  
instantiated.

Added support in dReportWriter for report groups and report  
variables, and
dynamic band heights (based on the height of contained objects).  
Added showExpr,
which is an expression that evaluates at runtime and if true, shows  
the object
in the report, and not if false.

Improved the automatic print preview report format in datanav. It now:

     + prints column headers

     + mirrors the font size, column width, cell vertical and horizontal
       alignment, and column height of the grid

     + mirrors the font size, header height, vertical and horizontal
       alignment of the grid headers

     + automatically reorients to landscape if the detail flows  
beyond the width
       of portrait

     + stops printing more columns if doing so would result in  
overflowing the
       right margin

Key bindings are now case-insensitive.

Improved docstrings and API documentation.

[Pythoncard-users] Re: Pythoncard mental block

[<gre...@gm...>]

The Python-Card guys are really helpful, <
pyt...@li...>, you may have to register on
sourceforge to get on their list.

In the meantime I went ahead and cc'd them on this. Python-Card guys, make
sure to cc Steven as he may not be on the list.

-Greg


On 10/7/05, Steven D'Aprano <st...@re...> wrote:
>
> On Fri, 07 Oct 2005 10:25:24 -0700, jlocc wrote:
>
> > Hi!!
> >
> > I am working on a school project and I decided to use PythonCard and
> > wxPython for my GUI development. I need a password window that will
> > block unwanted users from the system. I got the pop-up password
> > question to work...
>
> I haven't seen any replies to this, so even though I don't actually
> use Pythoncard I'll take a wild shot in the dark.
>
>
> > def on_openBackground(self, event):
> >
> > result =3D dialog.textEntryDialog(self,
> > 'System',
> > 'Please enter your password: ',
> > '')
> >
> > .....but I don't exactly remember how to check if the entered password
> > is correct. Say I hard code the password to be 'hello', then how would =
I
> > check if this was the input or if it wasn't???
>
> Start with looking at result and seeing what is in it. If it is the input
> string, then just say
>
> if result =3D=3D 'hello':
> # do whatever you need to
> else:
> # put up a dialog saying 'Password does not match!'
>
> But I'm guessing from the syntax that the dialog instance itself is store=
d
> in result, so perhaps you need to look at some attribute of result:
>
> if result.userInput =3D=3D "hello": # or something like that?
>
> Lastly, I might not have used Pythoncard, but years ago I used to use
> Hypercard rather a lot. In Hypercard, the password dialog would use a
> one-way hash function to encrypt the typed response into a large integer
> value. I assume Pythoncard is designed to do the same thing as Hypercard.
>
> So, in rusty Hypercard syntax with Python-style comments:
>
> # retrieve the numeric value of the password
> put field "hidden password" into userpassword
> # put up a dialog asking the user to enter a password
> ask password "Please enter your password:"
> if the result is "" then:
> # the user clicked Cancel, so just abort or go away or something
> go home
> else if the result is userpassword:
> # we have a match!
> go to card "Secret card"
> else:
> # password doesn't match
> go to card "Password failure"
>
>
> Hope this is of some help to you, and I haven't led you too far astray.
>
>
> --
> Steven.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>



--
Gregory Pi=F1ero
Chief Innovation Officer
Blended Technologies
(www.blendedtechnologies.com <http://www.blendedtechnologies.com>)

[Pythoncard-users] Installing from source code

[Andrew L. G. <al...@da...>]

How do I install PythonCard from source code?  I didn't see a Makefile,
so I assume it's not the usual "make; make install" routine.

I'm running FreeBSD 5.4.

Thanks,

Andrew

[Pythoncard-users] py2exe Single File mode

[<gre...@gm...>]

Has anyone had any luck running py2exe .6x + in single file mode on a
pythoncard application?

I tried it just now and it didn't bundle my .rsrc file into the executable.
I'll do some more research but I was just curious if anyone had already
figured out how to do this.

Thanks,

Greg

--
Gregory Pi=F1ero
Chief Innovation Officer
Blended Technologies
(www.blendedtechnologies.com <http://www.blendedtechnologies.com>)

[Pythoncard-users] PythonCard on FreeBSD?

[Andrew L. G. <al...@da...>]

Has anyone installed PythonCard on FreeBSD?  If so, would you describe
the installation steps?

Thanks,

Andrew Gould