pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] Plans

[Tony M. <tma...@tr...>]

Pythoncard is one of the best products I have used. My question is 
there any plans to have develop interfaces that can run on the web like 
java maybe using jython?

Re: [Pythoncard-users] Fwd: [wxPython-users] ANN: Dabo Licensing Change

[John F. <jfa...@yo...>]

On Sunday 07 November 2004 10:03, Kevin Altis wrote:
> Dabo is no longer licensed under the GPL. If you're interested in
> possible integration between Dabo and PythonCard and/or database
> solutions done with Python I encourage you to take a look.
>
> I probably won't look very closely at it until December since most of
> November will be burned up for me with videogames and other pastimes.
>
> ka
>
It's true it's no longer GPL - they made it easier...  Still free!
John

Re: [Pythoncard-users] Re: PythonCard and Unicode

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

On Nov 2, 2004, at 3:19 PM, Kevin Altis wrote:

> On Nov 2, 2004, at 2:57 PM, Pat Smith wrote:
>
>> Hi
>> I'm starting work on an application and I'd like to use PythonCard,
>> but I was wondering whether or not it currently supports unicode,
>> because in my tests, it does not.
>> I have wxPython's unicode build installed in windows, and unicode is
>> displayed properly in the wxPython Demo.  However, when I attempt to
>> build a resource file with unicode, it complains about ascii
>> conversion.
>>
>> Any help you could offer would be greatly appreciated.
>>
>> Thanks.
>> Patrick Smith
>
> http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1036993&group_id=19015&atid=119015
>
> Right now, there is specific code in resourceOutput.py that is  
> converting Unicode text to ascii. If those lines are commented out, I  
> think you'll be able to save Unicode strings to the resource file, but  
> what I don't know is whether some of those values saved will cause  
> PythonCard to gag when the resource files are loaded; probably not,  
> but I have no test cases to check. What you might try first, is  
> manually changing the 'text' or 'label' or other attributes where you  
> want to use Unicode strings and see if those load okay.
>
> There are at least two issues that need to be figured out with regards  
> to Unicode and PythonCard. One, is what attributes should support  
> Unicode strings. More importantly, if you have a resource file with  
> Unicode strings or use Unicode strings in your source and try and run  
> it on a non-Unicode build of wxPython, should PythonCard attempt to do  
> any conversions to ascii or just let an exception be thrown? This is  
> potentially a messy issue, but due to some limitations and bugs in the  
> wxPython builds, especially on Win9x, it isn't possible for us to just  
> require everyone to always run a wxPython Unicode build.
>
> What would be helpful, is to get some examples of real PythonCard  
> programs using Unicode in source and resource and then I would have  
> something to experiment with using both types of wxPython builds. All  
> files should be zipped and sent to me directly.
>
> ka

This wiki page is relevent to anyone interested in this issue.

http://wiki.wxpython.org/index.cgi/UnicodeBuild

I'm also going to change tests for StringType to StringTypes in the  
framework, samples, and tools. So far, that looks like it will only  
impact multicolumnlist.py and the MultiColumnList sample, but there  
might be some tests for str elsewhere as well. Hopefully, that will  
make the code more Unicode-friendly once the explicit ascii checks are  
dealt with as well.

http://docs.python.org/lib/module-types.html

"""
StringTypes
A sequence containing StringType and UnicodeType used to facilitate  
easier checking for any string object. Using this is more portable than  
using a sequence of the two string types constructed elsewhere since it  
only contains UnicodeType if it has been built in the running version  
of Python. For example: isinstance(s, types.StringTypes).  New in  
version 2.2.
"""

ka

[Pythoncard-users] Fwd: [wxPython-users] ANN: Dabo Licensing Change

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

Dabo is no longer licensed under the GPL. If you're interested in 
possible integration between Dabo and PythonCard and/or database 
solutions done with Python I encourage you to take a look.

I probably won't look very closely at it until December since most of 
November will be burned up for me with videogames and other pastimes.

ka

Begin forwarded message:

> From: "Ed Leafe" <ed...@le...>
> Date: November 5, 2004 8:47:13 AM PST
> To: pyt...@py..., wxP...@li...
> Subject: [wxPython-users] ANN: Dabo Licensing Change
> Reply-To: wxP...@li...
>
> 	Dabo (http://dabodev.com), the up-and-coming database application 
> development framework, is now available under the liberal MIT license 
> (http://www.opensource.org/licenses/mit-license.html).
>
> 	Formerly, Dabo was dual-licensed, under either GPL or a commercial 
> license, following the licensing model of MySQL. We decided that this 
> was too difficult to manage, and was discouraging some people from 
> seeing what Dabo was all about.
>
> 	Dabo is a 3-tier, cross-platform application development framework, 
> written in Python atop the wxPython GUI toolkit. It works seamlessly 
> with MySQL and Firebird databases, with PostgreSQL support in the 
> works.
>
>      ___/
>     /
>    __/
>   /
>  ____/
>  Ed Leafe
>  http://leafe.com/
>  http://dabodev.com/

[Pythoncard-users] Re: PythonCard and Unicode

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

On Nov 2, 2004, at 2:57 PM, Pat Smith wrote:

> Hi
> I'm starting work on an application and I'd like to use PythonCard,
> but I was wondering whether or not it currently supports unicode,
> because in my tests, it does not.
> I have wxPython's unicode build installed in windows, and unicode is
> displayed properly in the wxPython Demo.  However, when I attempt to
> build a resource file with unicode, it complains about ascii
> conversion.
>
> Any help you could offer would be greatly appreciated.
>
> Thanks.
> Patrick Smith

http://sourceforge.net/tracker/index.php? 
func=detail&aid=1036993&group_id=19015&atid=119015

Right now, there is specific code in resourceOutput.py that is  
converting Unicode text to ascii. If those lines are commented out, I  
think you'll be able to save Unicode strings to the resource file, but  
what I don't know is whether some of those values saved will cause  
PythonCard to gag when the resource files are loaded; probably not, but  
I have no test cases to check. What you might try first, is manually  
changing the 'text' or 'label' or other attributes where you want to  
use Unicode strings and see if those load okay.

There are at least two issues that need to be figured out with regards  
to Unicode and PythonCard. One, is what attributes should support  
Unicode strings. More importantly, if you have a resource file with  
Unicode strings or use Unicode strings in your source and try and run  
it on a non-Unicode build of wxPython, should PythonCard attempt to do  
any conversions to ascii or just let an exception be thrown? This is  
potentially a messy issue, but due to some limitations and bugs in the  
wxPython builds, especially on Win9x, it isn't possible for us to just  
require everyone to always run a wxPython Unicode build.

What would be helpful, is to get some examples of real PythonCard  
programs using Unicode in source and resource and then I would have  
something to experiment with using both types of wxPython builds. All  
files should be zipped and sent to me directly.

ka

Re: [Pythoncard-users] stay on top window question

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

On Nov 2, 2004, at 5:43 AM, Jacob Westfall wrote:

> Hi,
> 	I'm new to pythoncard and wxpython in general.  For my first app, 
> I've got a parent window and a child window working well according to 
> the tutorials.  However, the child window, which reports status 
> messages from the parent window, keeps losing focus and dropping 
> behind the main window.  I've checked in the wxpython docs and there 
> is the option to STAY_ON_TOP.  However, my question is how to get this 
> behaviour added to my child window in pythoncard?  Thanks,

There isn't a solution to this in the current release or what is 
checked into cvs. PythonCard doesn't have an optional attributes field 
for specifying alternative style flags. Your options are to subclass 
model.Background for your child window and change __init__ to use the 
style flags you want. Since you'll basically be copying and pasting the 
Background __init__ method, that isn't too bad.

Another solution might be to put your status messages in a statusBar on 
your main window, just use a plain wxPython window for your child 
window assuming the layout isn't very complex. If the status window is 
always on top and always visible, maybe that should be your main window 
for the app, and what is currently your main window a child window?

ka

[Pythoncard-users] stay on top window question

[Jacob W. <ja...@jp...>]

Hi,
	I'm new to pythoncard and wxpython in general.  For my first app, I've got a parent window and a child window working well according to the tutorials.  However, the child window, which reports status messages from the parent window, keeps losing focus and dropping behind the main window.  I've checked in the wxpython docs and there is the option to STAY_ON_TOP.  However, my question is how to get this behaviour added to my child window in pythoncard?  Thanks,

-- 
ja...@jp...
--

Re: [Pythoncard-users] PythonCard conference plans for next year

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

Kevin Altis wrote:
> This message is probably a bit premature, but I was thinking about=20
> travel and Python conferences for next year, so I thought I would share=
=20
> my plans. Since I expect PythonCard 1.0 to be finished this winter, onc=
e=20
> wxPython 2.6 is released, I thought next year would be a good time to d=
o=20
> some PythonCard promotion and training. What I'm planning to do is=20
> submit PythonCard talks and tutorials to PyCon and Python UK and OSCON.=
=20
> My proposals will probably be intros, so if anyone wants to make=20
> submissions that touch on more advanced topics, specific tools, or=20
> applications they've built with PythonCard, I expect those would also=20
> make for interesting talks. I wouldn't mind seeing some submissions for=
=20
> intros to Python and GUI programming that just happen to use PythonCard=
=20
> as the learning platform. ;-)
>=20
> Even if my submissions aren't accepted, I will attend the conferences=20
> and if there is interest, I'll also do a PythonCard BOF and/or coding=20
> sprint. I've added a wiki page in case you plan to attend some of the=20
> Python conferences next year and you want to add your name.
>=20
> http://wiki.wxpython.org/index.cgi/PythonCardConferences
>=20
> PyCon 2005 - March 23-25, 2005, George Washington University, DC (same=20
> location as last two years)
> Sprints will be taking place on the weekend after the conference, on=20
> March 26 and 27.
>=20
> Python UK Conference - April 20-23, 2005, Randolph Hotel, Oxford
> http://www.accu.org/conference/
> The Python track hasn't been officially announced, but there will be on=
e=20
> and the word should go out in the few weeks.
> I hope to do some vacation travel in the UK as well.
>=20
> EuroPython - June 27 - July 1, 2005, G=F6teborg, Sweden
> http://www.europython.org/
> I haven't made a decision about EuroPython yet.
>=20
> OSCON 2005 - date and location unannounced
>=20
> West Coast Python conference - unknown
> This year we had VanPy in Vancouver, BC after OSCON and I won't be=20
> surprised if there is a repeat of VanPy in 2005 or perhaps a conference=
=20
> that combines SciPy and more general topics, sort of a West Coast PyCon.
>=20
> ka
>=20

Better late than never ;-) A couple of other conferences that people may=20
like to attend/present at;

http://www.osdc.com.au/ - The Australian Open Source Developer's=20
Conference. We are a bit late for submitting a talk for this year's=20
event but I'm informed that something similar will run next year as well.

http://conf.linux.org.au/ - linux.conf.au is *the* Linux and open source=20
conference down under.

I'm out of holiday (and funds) to make either of these but other people=20
may want to check them out.

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

[Pythoncard-users] PythonCard newbie and focus

[Liam C. <cy...@gm...>]

Hello there,

Just found this wonderful thing called Pythoncard, and currently
blundering my way through it, and I'm having a bit of a dilemma with a
couple of things in the following -

def on_DLButton_mouseClick(self, event):
      self.statusWindow=model.childWindow(self, status.StatusBox)
      returnedlist=cmreports.main()
      if returnedlist == "noNew":
            self.statusWindow.components.StaticText1.text="La"
       elif...
       elif....

So, when the button is clicked a wee message box pops up and is  
updated by the elif tree.

What I'm finding is that  when the button is clicked, it pops up the
statusWindow, but it's dark grey, as opposed to the default grey.
After the cmreports.main() function has run, the elif tree updates the
statusWindow fine.

I've tried initializing the child Window in on_initialize, and then
Window.Show()ing it after the button is clicked, but it does the same
thing.

I've noticed that the button remains depressed until the cmreports
function has ended, so I gather it's to do with that. (The function
takes awhile to run on a 56k connection.)

Is there any way to force the statusWindow to refresh and take focus?
Or can I make the button pop straight back up?

I am running Python 2.3, with PythonCard 1.2 (I think?) on an winXP system.

If this is more of a  wxPython problem, I apologise.

Thanks for your time,

Liam Clarke

'There is only one basic human right, and that is to do as you damn well please.
And with it comes the only basic human duty, to take the consequences.

[Pythoncard-users] TextField lenght limit

[Benedetti L. <lbe...@ti...>]

Hi,

I use PythonCard Prototipe and/or PythonCard whit success, but I don't know
how to limit input length in the TextField elements.

 

How can I do????

 

Thx

 

PS: Sorry for my English!!!!!!!!!!!!! :-P

 

Luca

Re: [Pythoncard-users] Trouble with walkthrough 3

[<m.e...@at...>]

Thank you very much.  Your kindness is appreciated.

Mark

-------------- Original message from Alex Tweedly <al...@tw...>: -------------- 


> At 05:37 27/10/2004 +0000, m.e...@at... wrote: 
> 
> >In attempting to get through walkthrough 3 I have run into a bit of a 
> >wall. It appears that the on_openBackground methods in the counter module 
> >and the child module never execute. Has the name changed? Do I need to 
> >add code to specifically execute these event methods? I would appreciate 
> >any guidance. Here is the Counter code: 
> 
> Sorry, the walkthroughs haven't yet been updated to match Pythoncard 0.8 
> and upwards. 
> 
> on_openBackground has changed its name to on_initialize 
> 
> This (and some other useful info) can be found in 
> Pythoncard/docs/migration_guide.html 
> 
> The samples directory includes an updated version of the Counter example. 
> 
> -- Alex. 

Re: [Pythoncard-users] Trouble with walkthrough 3

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

At 05:37 27/10/2004 +0000, m.e...@at... wrote:

>In attempting to get through walkthrough 3 I have run into a bit of a 
>wall.  It appears that the on_openBackground methods in the counter module 
>and the child module never execute.  Has the name changed?  Do I need to 
>add code to specifically execute these event methods?  I would appreciate 
>any guidance.  Here is the Counter code:

Sorry, the walkthroughs haven't yet been updated to match Pythoncard 0.8 
and upwards.

on_openBackground has changed its name to on_initialize

This (and some other useful info) can be found in 
Pythoncard/docs/migration_guide.html

The samples directory includes an updated version of  the Counter example.

-- Alex.

[Pythoncard-users] Trouble with walkthrough 3

[<m.e...@at...>]

In attempting to get through walkthrough 3 I have run into a bit of a wall.  It appears that the on_openBackground methods in the counter module and the child module never execute.  Has the name changed?  Do I need to add code to specifically execute these event methods?  I would appreciate any guidance.  Here is the Counter code:

# Second PythonCard program following walkthrough 3

from PythonCard import model
import child

class Counter(model.Background):
    def on_openBackground(self, event):
        self.childWindow = model.childWindow(self, child.Child)
        # override resource position
        self.childWindow.SetPostion((200,5))
        self.childWindow.Show()
        
    # Counter modification methods
    def incrCtr(self):
        startValue = int(self.components.field1.text)
        endValue = startValue + 1
        self.components.field1.text = str(endValue)
        self.childWindow.components.field1.text = str(endValue)
        
    def decrCtr(self):
        startValue = int(self.components.field1.text)
        endValue = startValue - 1
        self.components.field1.text = str(endValue)
        self.childWindow.components.field1.text = str(endValue)
        
    def rstCtr(self):
        self.components.field1.text = "42"
        
    # Event Handlers
    def on_counterMenuIncr_select(self, event):
        self.incrCtr()
                
    def on_counterMenuDecr_select(self, event):
        self.decrCtr()
        
    def on_counterMenuRst_select(self, event):
        self.rstCtr()
        
    def on_incrBtn_mouseClick(self, event):
        self.incrCtr()
        
    def on_decBtn_mouseClick(self, event):
        self.decrCtr()
        
    def on_rstBtn_mouseClick(self, event):
        self.rstCtr()
        
if __name__ == '__main__':
    app = model.Application(Counter)
    app.MainLoop()

The child module:

"""
__version__ = "$Revision: 1.10 $"
__date__ = "$Date: 2004/04/24 22:13:31 $"
"""

from PythonCard import model

class Child(model.Background):
    
    def on_openBackground(self, event):
        self.parent = self.GetParent()
        
    def on_btnReset_mouseClick(self, event):
        self.parent.components.field1.text = "0"
        
    def doExit(self):
        self.parent.components.field1.text = "99"
        
    def on_close(self, event):
        self.doExit()
        self.Show(0)
        
    def on_menuFileExit_select(self, event):
        self.Close()
        
if __name__ == '__main__':
    app = model.Application(Child)
    app.MainLoop()

When I execute Counter and press the increment button I get the following traceback:

Traceback (most recent call last):
  File "C:\Program Files\Python23\lib\site-packages\PythonCard\widget.py", line
402, in _dispatch
    handler(background, aWxEvent)
  File "C:\Program Files\Python23\Lib\site-packages\PythonCard\samples\myCounter
\myCounter.py", line 44, in on_incrBtn_mouseClick
    self.incrCtr()
  File "C:\Program Files\Python23\Lib\site-packages\PythonCard\samples\myCounter
\myCounter.py", line 22, in incrCtr
    self.childWindow.components.field1.text = str(endValue)
AttributeError: 'Counter' object has no attribute 'childWindow'

It looks like childWindow is not defined because the method that defines it didn't execute.  If it had, i would have expected it to work or traceback on the references to the attribute in that method.  

Mark

Re: [Pythoncard-users] Old .rsrc files to 0.8 .rsrc files

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

At 14:27 26/10/2004 +0000, Brian Debuire wrote:

>Hello everyone,
>
>I am having a problem, and i know the solution was ported in the list time 
>ago, but here it is again, how can I transform my old Python Card 
>Prototype apps to new Python Card 0.8 apps ???
>
>I tried to open an old .rsrc file with the 0.8 release and nothing happens.

Full details in Pythoncard/docs/migration_guide.txt

quick answer  -  use a text editor to change  "stack" to "application" in 
the resource file.

But you need to look at the migration guide for other changes anyway.

-- Alex.

[Pythoncard-users] Old .rsrc files to 0.8 .rsrc files

[Brian D. <deb...@ho...>]

<html><div style='background-color:'><DIV class=RTE>Hello everyone,</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>I am having a problem, and i know the solution was ported in the list time ago, but here it is again, how can I transform my old Python Card Prototype apps to new Python Card 0.8 apps ???</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>I tried to open an old .rsrc file with the 0.8 release and nothing happens.</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>I will apreciate any help here.</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>Brian</DIV></div><br clear=all><hr>FREE pop-up blocking with the new MSN Toolbar <a href="http://g.msn.com/8HMAEN/2752??PS=47575" target="_top">MSN Toolbar</a> Get it now!</html>

[Pythoncard-users] Fwd: SourceForge.net PR-Web Upgrade Notice.

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

This may impact work that various developers and admin types need to do 
on the PythonCard SF web site, cvs access, etc.

ka

Begin forwarded message:

> From: "SourceForge.net Team" <no...@so...>
> Date: October 25, 2004 10:41:16 AM PDT
> To: al...@se...
> Subject: SourceForge.net PR-Web Upgrade Notice.
>
> Hello,
> You are receiving this email because you are an Admin of a project
> on SourceForge.net.   (Note: These update emails are very low
> volume, approximately twice a year).
>
> The SourceForge.net team is pleased to announce the long-awaited
> upgrade to our project web service.  SourceForge.net staff are
> currently in the process of completing hardware procurement and
> system build-out.  The official date for this upgrade has not yet
> been set; once our hardware build-out has been completed, the
> date will be announced on the SourceForge.net Site Status page.
> https://sourceforge.net/docs/A04/
>
> This upgrade consists of a significant hardware upgrade and
> Operating System upgrade.  Due to the large upgrades involved here,
> it may be necessary to upgrade your scripts.
>
>
> Old configuration:
>
>   Debian Potato
>   Linux kernel 2.4.x
>   GNU libc 2.2.1
>   Apache 1.3.26
>   Perl 5.005_03
>   PHP 4.1.2
>   Python 1.5.2
>   Tcl 8.0
>
> New configuration:
>
>   Fedora Linux: Fedora Core 2
>   Linux kernel 2.6.x
>   GNU libc 2.3.3
>   Apache 2.0.51
>   Perl 5.8.3
>   PHP 4.3.8
>   Python 2.3.3
>   Tcl 8.4.5
>
>
> Additional upgrades may be performed after this initial upgrade is
> completed; any follow-up changes will be announced via the
> Site Status page.
>
> A host roughly matching the configuration of the new project web
> servers is being placed within the Compile Farm on 2004-10-22.
> Additional information regarding the Compile Farm may be found
> at: https://sourceforge.net/docs/E02/
>
> Questions or concerns regarding this upgrade may be directed to
> SourceForge.net staff by submitting a Support Request as per:
> https://sourceforge.net/docs/C01/#support_site
>
> Thank you,
>
> SourceForge.net staff
>
> .
>

[Pythoncard-users] testNotebook didn't make it into release 0.8.1

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

I forgot to update the MANIFEST.in file to include the testNotebook  
sample, so it didn't make it into release 0.8.1. You can download the  
files from the anonymous cvs server.

http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCard/samples/ 
testNotebook/

Since that is a bit of a pain to download each and every file I went  
ahead and made a zip and put it on the SF server as well.

http://prdownloads.sourceforge.net/pythoncard/testNotebook.zip?download

ka

[Pythoncard-users] REMINDER: NorthWest(USA) Python Sprint #2 - October 23,24

[Brian D. <bri...@gm...>]

This is just a quick reminder that the NW python sprint is this weekend! 
See http://seapig.org/NorthwestPythonSprint  for all the details. 

Take care,
-Brian

PS - apologies to PORPIG and VANPYZ for this being the first
announcement, I wasn't able to get subscribed to either list a few
weeks ago. :(

===================================================
SeaPIG (the Seattle Python Interest Group) is excited to announce the

                           NORTHWEST PYTHON SPRINT #2
                              October 23-24, 2004
                           Bellevue, Washington, USA
                    http://seapig.org/NorthwestPythonSprint

The cost is FREE, thanks to our host Construx Software.  There will be a
large, comfortable room seating 50+ people at tables, wireless and wired
Internet access, and a projector for demonstrations.  We have the room
reserved for Saturday and Sunday, but feel free to drop in whenever you
can make it.

Kevin Altis will be giving a short intro to PythonCard
(http://pythoncard.sourceforge.net/) and coaching a sprint.

From his blog:
    I'll be giving a presentation on PythonCard Saturday morning as well
as helping people work on their own PythonCard projects, fix bugs, and
make additions to the framework and tools. Which projects we tackle will
depend on how many people show up and what interests them the most.
(http://altis.pycs.net/2004/09/30.html)

We have plenty of space, so feel free to sign up to coach other projects
or just bring your own and look for a partner.

What is a sprint?  A sprint is a group of people who gather for a day or
more to work on a common software project.  The members choose
individual tasks and usually work solo or in pairs in the same room,
then get together periodically to compare notes.  We'll follow the model
that has worked successfully at the past several Python conferences:
several groups working on different projects in the same room.  Past
sprints have done development work on the Python core, Twisted,
Docutils, Webware, Zope, Chandler, etc.  Most projects have a variety of
tasks that need to be done -- coding modules, designing test suites,
squashing bugs, writing user documentation and developer documentation,
brainstorming design strategies, planning promotional activities, etc --
so there's something for every skill level.  You'll need to bring a
laptop, or if you don't have one you can pair with somebody who does.

If you'd like to coach a sprint, sign up to attend,  propose a lightning
talk or demonstration, or just get more information, see our wiki page:

    http://seapig.org/NorthwestPythonSprint

or contact:

    sea...@li...
    or
    Brian Dorsey <brian at dorseys.org>, 206-619-6975
    Mike Orr <mso at oz.net>, 206-240-4250

Construx is located at 11820 Northup Way #E200, Bellevue WA 98005.  It's
eight miles from downtown Seattle; twenty from Sea-Tac Airport.
(http://seapig.org/ConstruxMeetingLocation)

Carpools and homestays are available if you contact us in advance.

Re: [Pythoncard-users] Background name change issue

[<bri...@sy...>]

I find "background" to be totally appropriate.  When I first saw "Edit >
Background Info..."
in the Resource Editor I immediately understood the meaning.

[Pythoncard-users] Background name change issue

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

Originally, the Background class was named after the idea of a 
HyperCard background, which is a container shared by one or more cards 
containing common layout objects and code shared by all cards on the 
background. Since PythonCard doesn't currently follow the HyperCard 
stack, background, and card metaphor and won't as far as release 1.0 is 
concerned, there has been debate on and off about changing the name of 
the class to something more common like Window or Form.

Technically, the Background class is a top-level wx.Frame which 
contains a wx.Panel and may also have a menu bar, tool bar, and status 
bar. The PageBackground class added in release 0.8.1 is a wx.Panel, 
which contains another wx.Panel; the extra panel might be dropped, it 
is there now to guarantee that both Background and PageBackground 
semantics are the same as far as user-code is concerned.

Because of the standardized use of a child Panel in the Background, it 
would probably be confusing to refer to the Background as a Frame. 
Window might be okay, but the term is fairly generic and could be 
confused with the wx.Window base class. Form might be okay, except that 
it seems like a better fit for what Panel is in wxPython (i.e. no menu 
bar or status bar).

Anyway, the main reason I'm tempted to just leave the name alone for 
PythonCard 1.0 is that every single sample, tool, resource file, docs, 
and much of the framework refer to Background and we've been using that 
terminology for the last three years on the mailing list. Since I 
expect there to be very few changes to the core framework and API 
before PythonCard 1.0 is released, changing such a fundamental name 
seems like a bad idea since it impacts hundreds of files. OTOH, if we 
decide to make any changes to the resource file, like using an 
underscore instead of a dot (e.g. minimal_rsrc.py), making the resource 
directly importable, etc. then if there is going to be a name change, 
it would be nice to take care of both issues at once for a 0.9 release.

As always, I would like to get some feedback, either pro or con, before 
putting this issue to bed. Remember, that the key issue with doing a 
PythonCard 1.0 release is that the framework API will be frozen, so 
that any subsequent 1.x releases will only be able to add classes, 
methods, named method args with default values, or other features that 
won't break code written for 1.0. It is very important to resolve 
fundamental problems with PythonCard in the next month or so to make 
PythonCard 1.0 as solid as possible and usable for a long time.

Any fundamental changes to PythonCard that would break older 1.x code 
will be pushed to the PythonCard 2.0 development branch. I expect that 
the current notion of containers, the Background name, etc. will be 
reworked when we get to that point.

ka

[Pythoncard-users] Announce: PythonCard 0.8.1

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

PythonCard is a GUI construction kit for building cross-platform  
desktop applications on Windows, Mac OS X, and Linux.

Release 0.8.1 includes over 50 sample applications and tools to help  
users build applications in Python, including codeEditor, findfiles,  
and resourceEditor (layout editor). A list of changes since release 0.8  
is at the end of this message. New samples include floatCanvasTest,  
flock, gravity, testNotebook, testSplitter. There is also an  
experimental reStructuredText and HTML editor in the codeEditor  
directory called restEditor.py.

The tools/oneEditor directory contains a new version of the codeEditor,  
named tabcodeEditor.py that supports tabbed editor panes and the  
resource file popups from codeEditorR; once the code is more mature, it  
will replace the current codeEditor. Alex Tweedly did most of the  
conversion, so kudos to him. The big plan is to support editing from  
within the resourceEditor, which is why the directory also contains the  
resourceEditor files.

PythonCard requires Python 2.3 or later and wxPython 2.5.2.8 or later.

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

Please be sure to look at the migration_guide.txt file in the docs  
directory if you are upgrading from a previous release. Since the  
package name has changed, you can continue to use the older  
PythonCardPrototype package simultaneously with the new PythonCard  
package, but you must upgrade to wxPython 2.5.2.8.


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

The installation instructions and walkthroughs are available on the  
main documentation page:
http://pythoncard.sourceforge.net/documentation.html

For a list of most of the samples that have been built with PythonCard  
and screenshots of them in action go to:
http://pythoncard.sourceforge.net/samples/samples.html

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

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

Additional Notes:
Remember to backup or just delete your old PythonCard directory before  
installing a new version, so that the old files aren't still in the  
package directory. If you installed a previous version of PythonCard on  
Windows using the binary installer, then you should be able to remove  
the old package via the Add/Remove Programs Control Panel.

The distutils installer will put the framework, components, docs,  
samples, and tools in Lib\site-packages or your Python directory  
(typically C:\Python23). Of course, on Linux and Mac OS X that path  
will be slightly different and have forward slashes.

Windows users should get a PythonCard menu in the Start->Programs menu  
with links to the documentation, samples, codeEditor, findfiles, and  
resourceEditor.

The tools and most of the samples will now keep their config and data  
file info in the "pythoncard_config" directory created by the  
framework. On Unix, the directory will be ~/pythoncard_config. On  
Windows, the directory varies as described in the following post:

http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/1496793

So, if you run a PythonCard app with any of the runtime tools and  
select "Save Configuration" from the "Debug" menu, the window positions  
and sizes of your runtime windows (Shell, Message Watcher, etc.) will  
be saved in "pythoncard_config/pythoncard_config.txt" not the  
PythonCard directory. Likewise, when you change the text style used by  
the codeEditor via the "Styles..." menu item under the "Format" menu,  
the modification will be saved in "pythoncard_config/stc-styles.cfg"

ka
---
Kevin Altis
al...@se...
http://altis.pycs.net/


changelog.txt changes since release 0.8

SPECIAL NOTE: at least as of wxPython 2.5.2.8 you must still
use a GTK1 build of wxWidgets/wxPython on Linux in order for
component dragging to work in the resourceEditor. You can track
the following bug report to be notified when this issue is fixed.
http://sourceforge.net/tracker/? 
func=detail&aid=1024777&group_id=9863&atid=109863

Release 0.8.1 2004-10-19
added fileMode, fillColor, logicalCopyMode attributes to BitmapCanvas
   removed setFillMode, setFillColor, setCopyMode methods
the resourceEditor property editor now updates attributes automatically
   but you can still click the Update button (this is mostly useful
   on the Mac when editing text)
resourceEditor (resourceOutput module) no longer saves background
   position in resource files
added work-in-progress version of tabbed code editor (tools/oneEditor)
renamed ver to VERSION_STRING in __version__.py and added VERSION tuple
added horizontalScrollbar flag to TextArea component
added appendText ScrollLines workaround to TextArea component on Windows
added lexicon and pattern files downloading to life sample
added time alias to util.py to use time.time() on Windows, time.clock()  
on *nix
added gravity sample
minimum requirement changed to wxPython 2.5.2.8
added passwordTextEntryDialog and multilineTextEntryDialog to dialog.py
many minor bug fixes
reworked dialogs sample interface
added Show Grid Lines option to resourceEditor
added cursor key support in resourceEditor for moving components
added FloatCanvas component and sample
added Notebook component, PageBackground, and testNotebook sample
added relativePath to util.py
added colorFromString to util.py
added main_is_frozen workaround for bundlebuilder standalones on Mac
added csv support to dbBrowser sample

Re: [Pythoncard-users] if you want to help test release 0.8.1...

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

On Oct 8, 2004, at 1:06 PM, Kevin Altis wrote:

> Unless people bring up some bugs that need immediate fixing, the code 
> that is currently in cvs will probably get turned into release 0.8.1 
> around the end of next week. It looks like wxPython 2.5.3.x won't get 
> released for at least 2-3 weeks and I want to get 0.8.1 out before the 
> PythonCard sprint in Bellevue (Seattle) on Oct. 23-34. Release 0.8.1 
> will work with wxPython 2.5.2.8 or later.
>
> The tabbed codeEditor that Alex is working on is a bit new to replace 
> the existing codeEditor, so the old single window version will still 
> be in 0.8.1, though we may include the tabbed version and initial 
> resourceEditor integration experiments in another directory so more 
> people can play with the code.
>
> If you are working from cvs, I would appreciate reports of problems 
> ASAP.
>
> Thanks,
>
> ka
>

The release will be done tomorrow, I'm giving anonymous cvs a day to 
catch-up with the developer cvs repository.

ka

Re: [Pythoncard-users] Thinking about Filemaker replacement

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

beware, middle posting below... ;-)

On Oct 15, 2004, at 8:29 AM, John Miller wrote:

> I'm glad you brought up this thread again because I had been wanting 
> to mention DABO:
>
> http://dabodev.com/
>
> This aims to be an open source Filemaker/FoxPro visual IDE 
> replacement. From their site:
>
> """
> Dabo is a 3-tier, cross-platform application development framework, 
> written in Python atop the wxPython GUI toolkit.
>
> Dabo's authors, Ed Leafe and Paul McNett, have strong backgrounds in 
> database application development using the awesome and underrated 
> Microsoft Visual FoxPro development environment.
>
> While Visual FoxPro shines at developing data-centric applications, it 
> has one limitation that cannot be ignored: it only runs on Microsoft 
> Windows, and Ed and Paul both have clients that want their 
> applications to run on Linux and Macintosh. We are sure we are not 
> alone in this regard: it is a multi-platform world with more diverse 
> needs than one vendor can fulfill.
> """
>
> I'm wondering if there could be any useful cross-pollination between 
> DABO and PythonCard?
>
> John Miller

Almost certainly. I've exchanged some email with Paul and talked to him 
at OSCON. However, I told him that until they change their license to 
something other than the GPL I won't even look at the code or think 
about incorporating it into parts of PythonCard since I have no 
intention of having PythonCard succumb to the GPL.

http://dabodev.com/licensing

I'll be happy to take a look and collaborate once the license is 
changed. Paul is of course welcome to contribute to this discussion and 
PythonCard as long as GPL code doesn't get rolled into the project.

ka


> On Oct 14, 2004, nor...@on... wrote:
>
>> I make an apology first. After an initial burst of activity, I  
>> haven't
>> been doing much in actually using PythonCard. This doesn't mean my
>> interest has not been fired. However, my initial interest was my quest
>> to see if a Filemaker replacement might be possible.
>>
>> What I have been doing is looking around in the open source community
>> for the various components that might contribute to such an 
>> enterprise.
>>
>> Database engine:
>> I have messed around with Firebird and it seems OK. Then I noticed 
>> that
>> sqlite - that I had been avoiding - is not too fussy about storage 
>> types
>> and requires no pre-definition of data size. This would appear to 
>> offer
>> a potential fit to the way Filemaker operates on data. The problem 
>> with
>> sqlite - at least I think it is a problem - is that it is does not
>> follow the client/server model. However, for the smallish companies 
>> that
>> dominate the Filemaker client base, sqlite may service requests 
>> rapidly
>> enough for this not to be a problem.
>>
>> What may be being worked on is a front end queuing mechanism that will
>> serve requests to sqlite. It appears that sqlite might evolve towards 
>> a
>> client/server model.
>>
>> Sqlite is moving to version 3. This gives a choice of specifying data
>> types or not which makes it an even better match for how Filemaker
>> represents data.
>>
>> A reporting tool:
>> Kevin Altiss found the excellent discussion on Filemaker replacement 
>> on
>> slashdot. One comment in this thread made me realise how important an
>> area Filemaker's reporting is. That thread also led me to DataVision
>> (http://datavision.sourceforge.net/) which I haven't tried but looks a
>> very promising report tool that would be much more powerful and 
>> flexible
>> than that of Filemaker.
>>
>> Extracting/converting data from Filemaker:
>> pyFilemaker seems to extract as much as FM is willing to give. An
>> interesting project in PythonCard would be to attempt to generate a
>> default database front end from this information. This would only be
>> bare bones compared with how the Filemaker front end would look, but
>> often, having a place to start is enough to get one going.
>>
>> Well, this is not an exhaustive list of what would need to be done 
>> but I
>> thought it worth giving this report as the initial discussion seemed 
>> to
>> generate interest.
>>
>>
>> I must add in conclusion that I am enjoying learning Python and have
>> produced a tool I use every day in relation to Filemaker. It is called
>> 'xpdfBatch.py' (or xpdfBatch.exe) and produces this output when 
>> invoked
>> from the command line with the '-h' option:
>>
>> xpdBatch.py - extracts text from pdf files in current folder.
>>              Depends on pdftotext from Glyph & Cog, LLC:
>>                  http://www.foolabs.com/xpdf/
>>
>>     Usage: with no arguments processes pdf files not already done
>>            If argument is:
>>            a pdf file: (must be quoted if containing spaces) process
>> that file
>>            'all': (without the quotes) process all pdf files. Any 
>> '.txt'
>> files
>>            existing will be overwritten.
>>            -h: show this help
>>
>> I use it as Filemaker prints scripts only as pdf.
>> Haven't tested it on the Mac yet but will.
>>
>> I have been very impressed by the patience and helpfulness of this
>> community,
>>
>> Norman

Re: [Pythoncard-users] Thinking about Filemaker replacement

[Rasjid W. <ra...@op...>]

On Friday 15 October 2004 06:22, normanwinn wrote:
> A reporting tool:
> Kevin Altiss found the excellent discussion on Filemaker replacement on
> slashdot. One comment in this thread made me realise how important an
> area Filemaker's reporting is. That thread also led me to DataVision
> (http://datavision.sourceforge.net/) which I haven't tried but looks a
> very promising report tool that would be much more powerful and flexible
> than that of Filemaker.

Have you come across "Report Manager"?

http://reportman.sourceforge.net/

I have not had a chance to test it, but it seems to be a reporting tool that 
may also be of use.

Cheers,

Rasjid.

-- 
Rasjid Wilcox
Canberra, Australia (UTC +10 hrs)
http://www.openminddev.net

Re: [Pythoncard-users] Thinking about Filemaker replacement

[John M. <jm...@um...>]

I'm glad you brought up this thread again because I had been wanting to 
mention DABO:

http://dabodev.com/

This aims to be an open source Filemaker/FoxPro visual IDE replacement. 
 From their site:

"""
Dabo is a 3-tier, cross-platform application development framework, 
written in Python atop the wxPython GUI toolkit.

Dabo's authors, Ed Leafe and Paul McNett, have strong backgrounds in 
database application development using the awesome and underrated 
Microsoft Visual FoxPro development environment.

While Visual FoxPro shines at developing data-centric applications, it 
has one limitation that cannot be ignored: it only runs on Microsoft 
Windows, and Ed and Paul both have clients that want their applications 
to run on Linux and Macintosh. We are sure we are not alone in this 
regard: it is a multi-platform world with more diverse needs than one 
vendor can fulfill.
"""

I'm wondering if there could be any useful cross-pollination between 
DABO and PythonCard?

John Miller

On Oct 14, 2004, nor...@on... wrote:

> I make an apology first. After an initial burst of activity, I  haven't
> been doing much in actually using PythonCard. This doesn't mean my
> interest has not been fired. However, my initial interest was my quest
> to see if a Filemaker replacement might be possible.
>
> What I have been doing is looking around in the open source community
> for the various components that might contribute to such an enterprise.
>
> Database engine:
> I have messed around with Firebird and it seems OK. Then I noticed that
> sqlite - that I had been avoiding - is not too fussy about storage 
> types
> and requires no pre-definition of data size. This would appear to offer
> a potential fit to the way Filemaker operates on data. The problem with
> sqlite - at least I think it is a problem - is that it is does not
> follow the client/server model. However, for the smallish companies 
> that
> dominate the Filemaker client base, sqlite may service requests rapidly
> enough for this not to be a problem.
>
> What may be being worked on is a front end queuing mechanism that will
> serve requests to sqlite. It appears that sqlite might evolve towards a
> client/server model.
>
> Sqlite is moving to version 3. This gives a choice of specifying data
> types or not which makes it an even better match for how Filemaker
> represents data.
>
> A reporting tool:
> Kevin Altiss found the excellent discussion on Filemaker replacement on
> slashdot. One comment in this thread made me realise how important an
> area Filemaker's reporting is. That thread also led me to DataVision
> (http://datavision.sourceforge.net/) which I haven't tried but looks a
> very promising report tool that would be much more powerful and 
> flexible
> than that of Filemaker.
>
> Extracting/converting data from Filemaker:
> pyFilemaker seems to extract as much as FM is willing to give. An
> interesting project in PythonCard would be to attempt to generate a
> default database front end from this information. This would only be
> bare bones compared with how the Filemaker front end would look, but
> often, having a place to start is enough to get one going.
>
> Well, this is not an exhaustive list of what would need to be done but 
> I
> thought it worth giving this report as the initial discussion seemed to
> generate interest.
>
>
> I must add in conclusion that I am enjoying learning Python and have
> produced a tool I use every day in relation to Filemaker. It is called
> 'xpdfBatch.py' (or xpdfBatch.exe) and produces this output when invoked
> from the command line with the '-h' option:
>
> xpdBatch.py - extracts text from pdf files in current folder.
>              Depends on pdftotext from Glyph & Cog, LLC:
>                  http://www.foolabs.com/xpdf/
>
>     Usage: with no arguments processes pdf files not already done
>            If argument is:
>            a pdf file: (must be quoted if containing spaces) process
> that file
>            'all': (without the quotes) process all pdf files. Any 
> '.txt'
> files
>            existing will be overwritten.
>            -h: show this help
>
> I use it as Filemaker prints scripts only as pdf.
> Haven't tested it on the Mac yet but will.
>
> I have been very impressed by the patience and helpfulness of this
> community,
>
> Norman