Menu
▾
▴
pythoncard-devel — PythonCard Developers List
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
(21) |
May
(24) |
Jun
|
Jul
(16) |
Aug
(28) |
Sep
(5) |
Oct
(4) |
Nov
(2) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(9) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
(24) |
Jun
(5) |
Jul
(2) |
Aug
(3) |
Sep
(4) |
Oct
(8) |
Nov
(37) |
Dec
(25) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(1) |
Dec
(2) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Phil E. <ph...@li...> - 2006-04-11 14:49:19
|
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 |
|
From: Phil E. <ph...@li...> - 2006-04-06 12:26:39
|
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 |
|
From: Alex T. <al...@tw...> - 2006-04-06 11:06:34
|
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 |
|
From: Phil E. <ph...@li...> - 2006-04-05 14:51:23
|
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 |
|
From: Phil E. <ph...@li...> - 2006-03-22 17:49:55
|
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 |
|
From: Brian M. <mrb...@gm...> - 2006-03-11 20:28:30
|
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) |
|
From: Kevin A. <al...@se...> - 2006-03-10 21:16:07
|
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
|
|
From: PayPal <se...@pa...> - 2006-02-25 20:06:28
|
|
|
From: Alex T. <al...@tw...> - 2006-01-13 02:27:31
|
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 |
|
From: Kevin A. <al...@se...> - 2006-01-12 21:35:07
|
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 |
|
From: Kevin A. <al...@se...> - 2006-01-12 21:24:33
|
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 |
|
From: Andy T. <an...@ha...> - 2006-01-07 22:10:02
|
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/ |
|
From: Alex T. <al...@tw...> - 2006-01-04 02:17:04
|
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 |
|
From: <bra...@om...> - 2006-01-03 22:38:16
|
> 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. |
|
From: Kevin A. <al...@se...> - 2006-01-03 19:17:38
|
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? > >= |
|
From: <bra...@om...> - 2006-01-03 18:16:05
|
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? > |
|
From: Kevin A. <al...@se...> - 2006-01-03 18:00:58
|
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... |
|
From: Kevin A. <al...@se...> - 2005-12-29 21:02:42
|
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
|
|
From: Alex T. <al...@tw...> - 2005-12-29 17:14:57
|
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 |
|
From: Kevin A. <al...@se...> - 2005-12-27 22:47:32
|
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 |
|
From: Andy T. <an...@ha...> - 2005-12-27 22:43:32
|
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/ |
|
From: <bra...@om...> - 2005-12-27 20:52:52
|
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.... |
|
From: Kevin A. <al...@se...> - 2005-12-27 19:55:09
|
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 |
|
From: Kevin A. <al...@se...> - 2005-12-27 19:33:57
|
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()
|
|
From: Kevin A. <al...@se...> - 2005-12-27 19:15:44
|
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))
|
37 messages has been excluded from this view by a project administrator.
