pythoncard-devel Mailing List for PythonCard (Page 5)

On Thursday 06 Apr 2006 13:26, Phil Edwards wrote:
>
> I've signed myself up to the pyInstaller mailing list so hopefully I'll be
> able to get it working sooner rather than later. It looks like the people
I've just uploaded another snapshot of the code to my website:
http://www.linux2000.com/downloads/standaloneBuilder-0.1.2-18.tar.gz
This adds support for pyInstaller (McMillan Installer replacement) and now has 
an option in the preferences to allow you to select whether to build using 
py2exe or pyInstaller. I've fixed sufficient bugs that standaloneBuilder is 
now perfectly capable of building itself into a standalone application! :-)
I'm planning to now go on a further bug hunt and fix a number of things which 
are still annoying me about the way the program runs under Windows. 
Hopefully, this means that the 0.1.3 snapshot will be of sufficient quality 
to be considered a 'release candidate' and then we can look at bundling the 
0.1.4 or 0.1.5 version to become part of PythonCard-0.9 later in the year.
Bug reports and/or general comments welcome either to here or direct to me by 
e-mail. Enjoy!
-- 
Regards
Phil Edwards
Brighton, UK

On Thursday 06 Apr 2006 12:06, Alex Tweedly wrote:
>
> I'm trying to put together a new release for 0.8.2 (I've spent the last
> few days tearing my hair trying to figure out why cvs access was no
> longer working for me - "What did I change??" - when suddenly today it
> just started working again - so either I'm changing something with *no*
> clue about it, or there's something going on external to my laptop).
>
I just updated my CVS copy with no problems, SF does sometimes just fall off 
the edge of the world for no reason, it's unlikely to be anything you've 
broken...
Drop me an e-mail when the new release is ready and I can get cracking on a 
new RPM for Mandrake.
> I'd suggest leaving the changes out until after this release, just for
> conservatism's sake - but if there's a good reason to put it in, and you
> reckon it's stable enough, let me know so I can wait for it ....
>
Nope, definitely leave it out of 0.8.2. I'm already using some of the features 
that are only in CVS e.g. platform-specific resource files, so it makes sense 
to wait until after 0.8.2 goes out.
I've signed myself up to the pyInstaller mailing list so hopefully I'll be 
able to get it working sooner rather than later. It looks like the people 
that took over the McMillan Installer codebase decided to change the build 
system completely, so there are still some residual 'issues' to be dealt 
with. I find myself hanging by my fingertips part way up the learning curve 
that is Win32 Software Development. :-)
-- 
Regards
Phil Edwards
Brighton, UK

Phil Edwards wrote:
>Progress update...
>
>standaloneBuilder now works with py2exe as the build mechanism. I've squashed 
>a number of bugs in the process of getting this to work. I've uploaded a 
>snapshot of the code to my website if anyone wants to play with it:
>
>http://www.linux2000.com/pm.html
>
>I'm continuing to work on also supporting pyInstaller, but this is proving to 
>be slightly more problematical than expected, due to the differences between 
>pyInstaller-1.1 and the McMillan Installer5b5 codebase it was based upon.
>
>Happy to check the snapshot into CVS if anybody wants me to, just holler. 
>Otherwise, I'll wait until I've got both build mechanisms working then amend 
>the prefs to allow the user to choose between them.
>
> 
>
I'm trying to put together a new release for 0.8.2 (I've spent the last 
few days tearing my hair trying to figure out why cvs access was no 
longer working for me - "What did I change??" - when suddenly today it 
just started working again - so either I'm changing something with *no* 
clue about it, or there's something going on external to my laptop).
I'd suggest leaving the changes out until after this release, just for 
conservatism's sake - but if there's a good reason to put it in, and you 
reckon it's stable enough, let me know so I can wait for it ....
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.5/302 - Release Date: 05/04/2006

Progress update...
standaloneBuilder now works with py2exe as the build mechanism. I've squashed 
a number of bugs in the process of getting this to work. I've uploaded a 
snapshot of the code to my website if anyone wants to play with it:
http://www.linux2000.com/pm.html
I'm continuing to work on also supporting pyInstaller, but this is proving to 
be slightly more problematical than expected, due to the differences between 
pyInstaller-1.1 and the McMillan Installer5b5 codebase it was based upon.
Happy to check the snapshot into CVS if anybody wants me to, just holler. 
Otherwise, I'll wait until I've got both build mechanisms working then amend 
the prefs to allow the user to choose between them.
-- 
Regards
Phil Edwards
Brighton, UK

Hi All:
Spurred on by a bunch of e-mails I've received in the last couple of weeks, 
I've started looking at the standaloneBuilder code again.
One of the things that stymied me for a while was the fact that Gordon 
McMillan was no longer maintaining his Installer package, which 
standaloneBuilder relies on to build Windows executables. My initial thought 
on this was to change the code to use py2exe instead. I've spent the last few 
days getting my head round that and I think I'm happy enough now with how it 
works.
It turns out that the McMillan Installer is officially a dead project, but it 
has been resurrected in the form of pyInstaller, details at:
http://pyinstaller.hpcf.upr.edu/cgi-bin/trac.cgi
I'm now in the position that I have the choice on which way to go with this - 
update the code to work with pyInstaller, or re-write some of it to use 
py2exe instead.
It's still my intention to get this working and donate the whole lot to 
PythonCard, so I was wondering if those subscribed to this list have any 
feelings one way or another about which build tool deserves to receive our 
support?
Of course, if I was any good at Python, I'd be able to make the program 
auto-detect the build system and configure itself accordingly! :-)
-- 
Regards
Phil Edwards
Brighton, UK

Adapting these 2002 instructions
http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/1048235
I've added cvs to a windows machine and now fail when I try to get
pythoncard
E:\python>cvs -d:pserver:ano...@cv...:/cvsroot/pythoncard
login
(Logging in to ano...@cv...)
CVS password:(simply pressing Enter)
cvs [login aborted]: unrecognized auth response from cvs.sourceforge.net:
M PserverBackend::PserverBackend() Connect (Connection refused)
On 3/10/06, Kevin Altis <al...@se...> wrote:
>
> A few days ago Andy made the following change to the
> resourceOutput.py module.
>
> (snip)

A few days ago Andy made the following change to the 
resourceOutput.py module.
*** resourceOutput.py	27 Oct 2005 22:58:00 -0000	1.33
--- resourceOutput.py	3 Mar 2006 10:07:21 -0000	1.34
***************
*** 95,100 ****
 #print key, value, type(value)
 if isinstance(value, (str, unicode)):
! if isinstance(value, unicode):
! value = value.encode('ascii', 'ignore')
 # need to escape strings
 #pprint.pprint(value)
--- 95,100 ----
 #print key, value, type(value)
 if isinstance(value, (str, unicode)):
! # if isinstance(value, unicode):
! # value = value.encode('ascii', 'ignore')
 # need to escape strings
 #pprint.pprint(value)
I don't remember all the issues we have with regards to unicode but I 
know we need more testing. The hack which Andy commented out means 
that if someone is running a unicode version of wxPython, all strings 
that come from a wxPython widget will be saved to the .rsrc.py file 
as a unicode string instead of a plain ascii string:
'text':u'TextField1'
instead of
'text':'TextField1'
In order to support unicode that is probably the right answer, but we 
need some testing now. I saved a simplistic .rsrc.py file via the 
resourceEditor using a unicode build of wxPython and then switched to 
an ansi build by changing the wx.pth file in site-packages and 
confirmed that for the simple case an ansi version of wxPython 
doesn't cause PythonCard to break when it tries to load a 7-bit ascii 
string. However, we need some tests where the unicode string(s) in 
the .rsrc.py file don't translate to 7-bit ascii so we can fail 
gracefully or convert in a sensible manner.
Doing a search for \:u\' using findfiles returned only the 
standaloneBuilder resource files as having a unicode string but the 
text is just 7-bit ascii. If anyone can make some test .rsrc.py files 
that we can use to break PythonCard and fix issues that would be great.
ka

Kevin Altis wrote:
> If you want to change or add something for 0.8.2 please do so soon. I 
> should be able to put together a build in the next couple of weeks. I 
> will be updating all my systems to use the latest wxPython 2.6.2 build 
> except for the Tiger system when it arrives. The docs that I updated 
> to 0.8.1 will be changed to say 0.8.2 so they make it into the build 
> and main site.
>
> When the release is done I'll ask people on the list to pay particular 
> attention to using the tabcodeEditor and multiresourceEditor with the 
> idea that those will become the PythonCard standard tools in the next 
> release. Of course, we'll have to update the doc screenshots and text 
> appropriately, but I'm sure Alex will enjoy the extra work ;-) The 
> existing tools won't go away, but we may need to shuffle some names 
> around. This is probably a good time to switch to calling 
> multiresourceEditor "layoutEditor" instead.
>
> We can make that name change prior to 0.8.2 if that seems like a good 
> idea.
>
Seems to me like a good idea, and I'll be happy to update all the 
walkthroughs for the new tools. (Should we keep the old walkthroughs 
since the old tools will still be there ?)
It means renaming files, which I seem to remember being tricky in CVS - 
so if you wanted to do the actual rename, that would be fine. I could 
then do any edits within layoutEditor.py to reflect its new name.
btw - I'd like to hear your (and indeed anyone's) preferences about the 
"Vary" versus "auto-naming" choice for the layout editor (see my email 
on Jan 4th for more details).
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.15/223 - Release Date: 06/01/2006

If you want to change or add something for 0.8.2 please do so soon. I 
should be able to put together a build in the next couple of weeks. I 
will be updating all my systems to use the latest wxPython 2.6.2 build 
except for the Tiger system when it arrives. The docs that I updated to 
0.8.1 will be changed to say 0.8.2 so they make it into the build and 
main site.
When the release is done I'll ask people on the list to pay particular 
attention to using the tabcodeEditor and multiresourceEditor with the 
idea that those will become the PythonCard standard tools in the next 
release. Of course, we'll have to update the doc screenshots and text 
appropriately, but I'm sure Alex will enjoy the extra work ;-) The 
existing tools won't go away, but we may need to shuffle some names 
around. This is probably a good time to switch to calling 
multiresourceEditor "layoutEditor" instead.
We can make that name change prior to 0.8.2 if that seems like a good 
idea.
ka

It looks like I may get a new Intel-based iMac next week so I'll have 
both Tiger and Panther systems. Given the built-in Python and wxPython 
combo, for 0.8.2 maybe the Tiger install instructions will just be 
shortened to the part about installing PythonCard and testing that it 
works. Do we still need the Python add-ons like PythonLauncher or are 
those also included? If someone wants to rev the docs I checked into 
cvs that would be great, otherwise I'll try and get to it toward the 
end of next week or whenever I get my new box.
ka

Kevin Altis wrote:
> Robin is planning on a new release this week. The latest test build info 
> is below.
> 
> Since our releases are supposed to be tracking 2.6.x that means 0.8.2 
> should be changed to require wxPython 2.6.x as a minimum. That would 
> mean the default version of wxPython 2.5.3.1 on Tiger would no longer be 
> adequate and I suspect a lot of current 0.8.1 users would be forced to 
> upgrade wxPython as well. I'm thinking that what we might do instead is 
> leave the version check as-is but change the install instructions for 
> Python 2.4.2 and wxPython 2.6.2.1. The next release, say PythonCard 0.9 
> we can bump the required version to 2.6.
> 
> What do you think we should do for this release?
> 
> ka
> 
> Begin forwarded message:
[snip]
> 
> 
+1. Let's not break this release for people on Mac OSX but give plenty 
of warning that the next release will require a manual install of the 
appropriate wxPython version.
Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/217 - Release Date: 30/12/2005

> Kevin Altis wrote:
> 
> >
> > Thanks Alex. readme.txt should be adequate for both of the new apps. 
> > Do you think multiresourceEditor should have a shortcut in 0.8.2 or 
> > wait another release?
Alex Tweedly replied:
> I think it could have one now - I have no outstanding bugs I'm aware of, 
> and although I couldn't claim to have "tested it thoroughly" on Python 
> 2.4 / wxPython 2.6.1, I have given it a fair work-out over the last 
> couple of days and seen no problems. (That is, of course, ignoring 
> all the raise / lower issues ..... which I don't think are any different 
> in the multiresourceEditor)
> 
> (I did discover one problem with the tabcodeEditor - report coming 
> shortly unless I stumble into understanding it myself ....)
MultiResourceEditor has been very robust for me. I've used it regularly
for the past few months. It's not perfect--for instance, I wish the Vary 
checkbox
defaulted to "off" and was renamed to something more obvious 
"Auto-Naming".
But's that just my preference, not a bug. There are probably bugs I 
haven't 
noticed, of course, since I only use 14 out of the 25 widgets available.
I haven't used the old Resource Editor in a long time. MultiResourceEditor 
is
just too useful for me to consider going back. It's great to be
able to see all the properties for a widget displayed simultaneously,
and for that matter it's also frequently useful to be able to select
multiple widgets simultaneously. 
The old Resource Editor also had a number of frustrating glitches in 
relation
to moving and resizing objects. Alex fixed those issues for 
MultiResourceEditor.
Overall, I think the MultiResourceEditor puts a better face on PythonCard
and is less likely to scare off newbies.
 

On Jan 3, 2006, at 10:14 AM, bra...@om... wrote:
>
> Will requiring wx 2.6 give you freedom to make significant =20
> improvements to PythonCard?
> Does allowing wx2.5.3 hold us back in some significant way? =A0It =
seems =20
> like the requirement
> would introduce a high barrier to entry for beginners on the Mac side, =
=20
> since wx doesn't
> seem to have a good installer for Tiger. Maybe the wx folks will fix =20=
> that issue...
wxPython 2.6.x is supposed to be a stable API so code we do against =20
that shouldn't break in the future as long as people use a 2.6.x =20
release. In wxWidgets, the releases with odd-numbered second digits =20
(2.3.x, 2.5.x, 2.7.x) are considered unstable API releases and can =20
change APIs as well as behavior. The even-numbered releases (2.2.x, =20
2.4.x, 2.6.x) are supposed to be stable, which is why PythonCard 1.0 is =20=
targeted for wxPython 2.6.x.
In practice, wxPython tends to get some new features, API or behavior =20=
changes each release, regardless of whether it is an even-numbered =20
release or not, but 2.6.x is pretty stable and will be the standard for =20=
quite a while. Read the changes to see specifics for the last couple of =20=
releases:
http://starship.python.net/crew/robind/wxPython/daily/20060102/=20
CHANGES.html
For PythonCard, where most of our framework and API issues tend to boil =20=
down to issues with the underlying wxPython/wxWidgets and specific =20
platform, we need to limit the releases we support just so we have a =20
hope of being able to support the code. But making sure everyone is at =20=
least using a reasonable version of wxPython always means there will be =20=
less support problems as everyone has the same bug fixes.
The only reason I didn't want to just automatically push the 0.8.2 =20
requirement to 2.6.2 is that I'm hoping everyone using 0.8.1 will =20
upgrade quickly and we can get more testing before a 0.9 release which =20=
shouldn't be that far away.
Whatever the next big release is before 1.0 I'm pretty certain that =20
will be when we say absolutely no more changes to the framework and =20
resource files will be done that might break code written after that =20
point. For example, if we're going to support tab order separate from =20=
display order, that change has to be incorporated in such a way that =20
older programs still tab as expected without having whatever the new =20
info would be. We definitely will not require wxPython 2.7.x for =20
PythonCard 1.x even though Robin will be working on that pretty soon.
ka
> pyt...@li... wrote on 01/03/2006 =20
> 12:00:52 PM:
>
> > Robin is planning on a new release this week. The latest test build =
=20
> =A0
> > info is below.
> >
> > Since our releases are supposed to be tracking 2.6.x that means =20
> 0.8.2 =A0
> > should be changed to require wxPython 2.6.x as a minimum. That =20
> would =A0
> > mean the default version of wxPython 2.5.3.1 on Tiger would no =20
> longer =A0
> > be adequate and I suspect a lot of current 0.8.1 users would be =20
> forced =A0
> > to upgrade wxPython as well. I'm thinking that what we might do =20
> instead =A0
> > is leave the version check as-is but change the install =20
> instructions =A0
> > for Python 2.4.2 and wxPython 2.6.2.1. The next release, say =20
> PythonCard =A0
> > 0.9 we can bump the required version to 2.6.
> >
> > What do you think we should do for this release?
> >=

Will requiring wx 2.6 give you freedom to make significant improvements to 
PythonCard?
Does allowing wx2.5.3 hold us back in some significant way? It seems like 
the requirement
would introduce a high barrier to entry for beginners on the Mac side, 
since wx doesn't
seem to have a good installer for Tiger. Maybe the wx folks will fix that 
issue...
pyt...@li... wrote on 01/03/2006 12:00:52 
PM:
> Robin is planning on a new release this week. The latest test build 
> info is below.
> 
> Since our releases are supposed to be tracking 2.6.x that means 0.8.2 
> should be changed to require wxPython 2.6.x as a minimum. That would 
> mean the default version of wxPython 2.5.3.1 on Tiger would no longer 
> be adequate and I suspect a lot of current 0.8.1 users would be forced 
> to upgrade wxPython as well. I'm thinking that what we might do instead 
> is leave the version check as-is but change the install instructions 
> for Python 2.4.2 and wxPython 2.6.2.1. The next release, say PythonCard 
> 0.9 we can bump the required version to 2.6.
> 
> What do you think we should do for this release?
> 

Robin is planning on a new release this week. The latest test build 
info is below.
Since our releases are supposed to be tracking 2.6.x that means 0.8.2 
should be changed to require wxPython 2.6.x as a minimum. That would 
mean the default version of wxPython 2.5.3.1 on Tiger would no longer 
be adequate and I suspect a lot of current 0.8.1 users would be forced 
to upgrade wxPython as well. I'm thinking that what we might do instead 
is leave the version check as-is but change the install instructions 
for Python 2.4.2 and wxPython 2.6.2.1. The next release, say PythonCard 
0.9 we can bump the required version to 2.6.
What do you think we should do for this release?
ka
Begin forwarded message:
> From: "Robin Dunn" <ro...@al...>
> Date: January 2, 2006 1:08:20 PM PST
> To: wxP...@li...
> Subject: [wxPython-dev] 2.6.2.1 release soon
> Reply-To: wxP...@li...
>
> Hi all,
>
> I'm going to try and get a 2.6.2.1 release done this week. If there 
> are any more fixes, patches, enhancements, etc. that you want to have 
> included, now is the time to get them to me.
>
> There will be another preview build done today for testing.
>
> -- 
> Robin Dunn
> Software Craftsman
> http://wxPython.org Java give you jitters? Relax with wxPython!
>
> From: "R'bot" <rb...@wx...>
> Date: January 3, 2006 1:11:23 AM PST
> To: wxP...@li...
> Subject: [wxPython-dev] 20060102 test build uploaded
> Reply-To: wxP...@li...
>
> Hi,
>
> A new test build of wxPython has been uploaded to starship.
>
> Version: 2.6.2.1pre.20060102
> URL: 
> http://starship.python.net/crew/robind/wxPython/daily/20060102
> Changes: 
> http://starship.python.net/crew/robind/wxPython/daily/20060102/ 
> CHANGES.html
>
> Have fun!
> R'bot
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxP...@li...
> For additional commands, e-mail: wxP...@li...

I moved the dumpDocs formerly in the widgets.py sample into a new 
module called documentation.py. The logic is essentially the same, but 
the helper methods are now helper functions so they can be used from 
any application. To test documenting the background class I just ran 
minimal.py with the shell since it has no additional class methods of 
its own:
 >>> from PythonCard import documentation
 >>> documentation.dumpDocs(self)
This will create an HTML file similar to the ones for the components, 
but specific to the background object passed in. I need to do a bit 
more tweaking, but something similar can then be done for any 
combination of background and components in any application, making it 
easy to document your own applications as well as just generate a 
specific component doc for something that might not be in widgets.py at 
the moment.
We still have the problem of the HTML being pretty ugly, but at least 
we're making some progress ;-p
One thing you might notice is that method aliases do get documented 
properly from wxPython provided doc strings and so on. For example, 
Background close is defined as:
 close = wx.Frame.Close
so its args are (*args, **kwargs) and the doc string is:
"Close(self, bool force=False) -> bool This function simply generates 
a EVT_CLOSE event whose handler usually tries to close the window. It 
doesn't close the window itself, however. If force is False (the 
default) then the window's close handler will be allowed to veto the 
destruction of the window."
Generating component docs from widgets.py should still work the way it 
used to. If I managed to break something let me know.
At one point Robin had made modifications to one of the Python 
documentation tools. I've posted a question on wxPython-dev to find out 
the status of that and see if we might try it out for ourselves as well 
to see if it would make for a better reference doc tool.
ka

Kevin Altis wrote:
>
> Thanks Alex. readme.txt should be adequate for both of the new apps. 
> Do you think multiresourceEditor should have a shortcut in 0.8.2 or 
> wait another release?
>
I think it could have one now - I have no outstanding bugs I'm aware of, 
and although I couldn't claim to have "tested it thoroughly" on Python 
2.4 / wxPython 2.6.1, I have given it a fair work-out over the last 
couple of days and seen no problems. (That is, of course, ignoring 
all the raise / lower issues ..... which I don't think are any different 
in the multiresourceEditor)
(I did discover one problem with the tabcodeEditor - report coming 
shortly unless I stumble into understanding it myself ....)
-- 
Alex Tweedly http://www.tweedly.net
-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29/12/2005

On Dec 27, 2005, at 2:43 PM, Andy Todd wrote:
> bra...@om... wrote:
>> Kevin Altis wrote on 12/27/2005 01:54:59 PM:
>> > I'm still running Panther on my PowerBook and given my aversion to
>> > changing things that seem to work fine I probably won't upgrade 
>> until I
>> > get a new machine next year. That means I don't have an easy way to
>> > write install instructions for Tiger, which we definitely need. I 
>> went
>> > ahead and added duplicates of the current panther install 
>> instructions
>> > to cvs macosx_panther_installation.html,
>> > macosx_tiger_installation.html. Any Tiger install instructions are
>> > probably going to need to incorporate the info at:
>> >
>> > http://undefined.org/python/#TigerPython23Compat
>> >
>> > Can anyone with a Tiger system tweak the 
>> macosx_tiger_installation.html
>> > document so we can add that to the main site. If it needs to use 
>> Python
>> > 2.4.x and a later version of wxPython that is fine. I'll push this
>> > request to the users list if none of us have access to Tiger.
>> >
>> I'm using PythonCard with wx 2.6.1 and Python 2.3.5 on Tiger, but I 
>> had
>> an error during the wx binary install. I've seen that same error on 
>> every
>> Tiger system I've tried.
>> What I did was install TigerPython23Compat.pkg and then run the binary
>> wx installer for Panther. After running the binary install, an error
>> message appears in the GUI stating "There was an error during the 
>> install.
>> Please try again."
>> Trying again doesn't make the error message go away.
>> I don't know what's generating that error message, but wx seems to 
>> work
>> anyway. It still has some visual bugs, but I don't think that has 
>> anything
>> to do with Tiger--I seen the same visual bugs under Panther. These 
>> visual
>> glitches are associated with wx 2.6.x and don't happen under 2.5.3.
>> (PythonCard TextField widgets don't display properly when populated
>> during on_initialize -- the text is left scrolled out of view).
>> Tiger does bundle wxPython 2.5.3 unicode, so if that version is 
>> acceptable
>> some users may be able to skip installing wx. Since PythonCard seems
>> to have less visual glitches under 2.5.3, maybe we should just 
>> recommend
>> using the bundled wx on the instructions page. That would considerably
>> simplify the instructions.
>> On the other hand, some folks may want to use Python 2.4.x. That will
>> probably entail installing a separate copy of wx....
>
> On my shiny new Powerbook everything appears to be working fine from a 
> fresh CVS checkout.
>
> I can confirm that I'm using the Apple supplied versions of Python 
> (2.3.5) and wxPython (2.5.3.1).
>
> I haven't tried installing wxPython 2.6 so can't corroborate Brad's 
> issues with strange error messages.
>
> Regards,
> Andy
> -- 
> ----------------------------------------------------------------------- 
> ---------
> From the desk of Andrew J Todd esq - http://www.halfcooked.com/
>
So maybe what we should do is point out in the instructions just using 
the supplied 2.3.5 and 2.5.3.1 versions and then an install wxPython 
2.6.2.x (when available) and Python 2.4.x. I can't see PythonCard 1.0 
requiring Python 2.4 features but we will definitely want to support 
wxPython 2.6.2.x once it is available.
ka

bra...@om... wrote:
> 
> Kevin Altis wrote on 12/27/2005 01:54:59 PM:
> 
> > I'm still running Panther on my PowerBook and given my aversion to
> > changing things that seem to work fine I probably won't upgrade until I
> > get a new machine next year. That means I don't have an easy way to
> > write install instructions for Tiger, which we definitely need. I went
> > ahead and added duplicates of the current panther install instructions
> > to cvs macosx_panther_installation.html,
> > macosx_tiger_installation.html. Any Tiger install instructions are
> > probably going to need to incorporate the info at:
> >
> > http://undefined.org/python/#TigerPython23Compat
> >
> > Can anyone with a Tiger system tweak the macosx_tiger_installation.html
> > document so we can add that to the main site. If it needs to use Python
> > 2.4.x and a later version of wxPython that is fine. I'll push this
> > request to the users list if none of us have access to Tiger.
> >
> 
> 
> I'm using PythonCard with wx 2.6.1 and Python 2.3.5 on Tiger, but I had
> an error during the wx binary install. I've seen that same error on every
> Tiger system I've tried.
> 
> What I did was install TigerPython23Compat.pkg and then run the binary
> wx installer for Panther. After running the binary install, an error
> message appears in the GUI stating "There was an error during the install.
> Please try again."
> 
> Trying again doesn't make the error message go away.
> 
> I don't know what's generating that error message, but wx seems to work
> anyway. It still has some visual bugs, but I don't think that has anything
> to do with Tiger--I seen the same visual bugs under Panther. These visual
> glitches are associated with wx 2.6.x and don't happen under 2.5.3.
> (PythonCard TextField widgets don't display properly when populated
> during on_initialize -- the text is left scrolled out of view).
> 
> Tiger does bundle wxPython 2.5.3 unicode, so if that version is acceptable
> some users may be able to skip installing wx. Since PythonCard seems
> to have less visual glitches under 2.5.3, maybe we should just recommend
> using the bundled wx on the instructions page. That would considerably
> simplify the instructions.
> 
> On the other hand, some folks may want to use Python 2.4.x. That will
> probably entail installing a separate copy of wx....
On my shiny new Powerbook everything appears to be working fine from a 
fresh CVS checkout.
I can confirm that I'm using the Apple supplied versions of Python 
(2.3.5) and wxPython (2.5.3.1).
I haven't tried installing wxPython 2.6 so can't corroborate Brad's 
issues with strange error messages.
Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

Kevin Altis wrote on 12/27/2005 01:54:59 PM:
> I'm still running Panther on my PowerBook and given my aversion to 
> changing things that seem to work fine I probably won't upgrade until I 
> get a new machine next year. That means I don't have an easy way to 
> write install instructions for Tiger, which we definitely need. I went 
> ahead and added duplicates of the current panther install instructions 
> to cvs macosx_panther_installation.html, 
> macosx_tiger_installation.html. Any Tiger install instructions are 
> probably going to need to incorporate the info at:
> 
> http://undefined.org/python/#TigerPython23Compat
> 
> Can anyone with a Tiger system tweak the macosx_tiger_installation.html 
> document so we can add that to the main site. If it needs to use Python 
> 2.4.x and a later version of wxPython that is fine. I'll push this 
> request to the users list if none of us have access to Tiger.
> 
I'm using PythonCard with wx 2.6.1 and Python 2.3.5 on Tiger, but I had
an error during the wx binary install. I've seen that same error on every
Tiger system I've tried.
What I did was install TigerPython23Compat.pkg and then run the binary
wx installer for Panther. After running the binary install, an error
message appears in the GUI stating "There was an error during the install.
Please try again." 
Trying again doesn't make the error message go away.
I don't know what's generating that error message, but wx seems to work
anyway. It still has some visual bugs, but I don't think that has anything
to do with Tiger--I seen the same visual bugs under Panther. These visual
glitches are associated with wx 2.6.x and don't happen under 2.5.3.
(PythonCard TextField widgets don't display properly when populated
during on_initialize -- the text is left scrolled out of view).
Tiger does bundle wxPython 2.5.3 unicode, so if that version is acceptable
some users may be able to skip installing wx. Since PythonCard seems
to have less visual glitches under 2.5.3, maybe we should just recommend
using the bundled wx on the instructions page. That would considerably
simplify the instructions.
On the other hand, some folks may want to use Python 2.4.x. That will
probably entail installing a separate copy of wx....

I'm still running Panther on my PowerBook and given my aversion to 
changing things that seem to work fine I probably won't upgrade until I 
get a new machine next year. That means I don't have an easy way to 
write install instructions for Tiger, which we definitely need. I went 
ahead and added duplicates of the current panther install instructions 
to cvs macosx_panther_installation.html, 
macosx_tiger_installation.html. Any Tiger install instructions are 
probably going to need to incorporate the info at:
http://undefined.org/python/#TigerPython23Compat
Can anyone with a Tiger system tweak the macosx_tiger_installation.html 
document so we can add that to the main site. If it needs to use Python 
2.4.x and a later version of wxPython that is fine. I'll push this 
request to the users list if none of us have access to Tiger.
ka

The bad news is that Robin replied to my thread on wxPython-dev, saying
"Since the official policy is that overlapping widgets is not supported 
then I doubt anything will be done for fear of breaking something else. 
 I expect that this behavior will be left as platform default or 
'undefined' by wx."
"Just FYI, on wx.GTK2 the last created is always on top, and 
Raise/Lower don't seem to do anything with the button widgets. :-("
The last created item always being on top is what the Mac does too, if 
GTK1 does the same thing, then it is Windows that is the oddball on 
creation order.
I have no idea whether the resourceEditor in cvs behaves correctly with 
GTK1 or GTK2 builds of wxPython. I found that a bug report I had 
submitted is still open, which makes me think that we are sort of 
screwed on GTK2.
http://sourceforge.net/tracker/? 
func=detail&aid=1024777&group_id=9863&atid=109863
If anyone can confirm one way or another that would be great. My simple 
wxPython test program for overlaps is included below along with my 
workaround for making the Mac behave like Windows when the widget is 
created.
ka
---
import wx
print wx.VERSION
class MyApp(wx.App):
 def OnInit(self):
 frame = wx.Frame(None, -1, "minimal", size=(200, 200))
 panel = wx.Panel(frame, -1)
 self.panel = panel
 frame.Show(True)
 # creation order overlaps 'Three' on top of "Two'
 # on top of 'One' on Mac wxPython 2.6.1
 # creation order overlaps 'One' on top of "Two'
 # on top of 'Three' on Win2K wxPython 2.6.2
 # not tested under Linux
 self.btn1 = wx.Button(panel, -1, 'One', (5, 30))
 if wx.Platform == '__WXMAC__':
 self.btn1.Lower()
 self.btn2 = wx.Button(panel, -1, 'Two', (35, 40))
 if wx.Platform == '__WXMAC__':
 self.btn2.Lower()
 self.btn3 = wx.Button(panel, -1, 'Three', (65, 50))
 if wx.Platform == '__WXMAC__':
 self.btn3.Lower()
 btnRaise = wx.Button(panel, -1, 'Reverse Overlap', (50, 100))
 wx.EVT_BUTTON(self, btnRaise.GetId(), self.on_mouseClick)
 self.SetTopWindow(frame)
 return True
 def on_mouseClick(self, event):
 self.btn2.Raise()
 self.btn3.Raise()
app = MyApp(0)
app.MainLoop()

There is a fitToComponents convenience method in model.py that 
currently is only used by dialogs sample, so needs more testing in 
other samples with static layouts that have this spacing problem. This 
does seem to work in the dialogs sample on Windows and the Mac. The 
comment and code I wrote last year is at the end of this message. I'm 
thinking that I should just go ahead and add a fitToComponents call in 
other samples for the next release like this one:
 def on_initialize(self, event):
 self.fitToComponents(None, 5)
If we can verify it is working fine then it can be incorporated into 
the resource file and done automatically for applications that don't 
explicitly turn it off, which would typically be apps with their own 
sizer code. Any other ideas? If this isn't working on GTK1 or GTK2, 
etc. let me know.
ka
---
 # KEA 2004年09月24日
 # experiment to see if we could fit the panel
 # to the boundaries of the components with a little
 # padding to get around the problem of a static layout
 # having too much vertical space on GTK and Mac or not
 # enough vertical space on Windows if the layout was designed
 # for GTK or Mac...
 # the idea is that this would become an option in the resource
 # that could be called automatically
 # but I'm just testing now to see if it actually produces good 
results
 def fitToComponents(self, widthPadding=None, heightPadding=5):
 print "self.size:", self.size
 print "self.panel.size:", self.panel.size
 width = 0
 height = 0
 # height = self.panel.size
 for c in self.components.itervalues():
 print " ", c.name, c.position, c.size
 x, y = c.position
 w, h = c.size
 width = max(x + w, width)
 height = max(y + h, height)
 print "width, height", width, height
 newWidth, newHeight = self.panel.size
 if widthPadding is not None:
 newWidth = width + widthPadding
 if heightPadding is not None:
 newHeight = height + heightPadding
 print "newWidth, newHeight", newWidth, newHeight
 self.panel.SetSize((newWidth, newHeight))
 self.SetClientSize((newWidth, newHeight))