Getting ready for 2.4.2.x

wxWindows 2.4.2 was released over the weekend and so I am preparing for a wxPython release too. So if you have any patches or such pending please try and get them to me today if possible. (Sorry for the short notice, up until Friday it was thought that maybe the 2.5.1 release would be done last weekend and then 2.4.2 in another week or two, but it got switched around.)

Not a whole lot has changed on the wxPython side of things, other than a new version of Scintilla, but there have been a number of bug fixes in wxWindows.

I've had a number of requests for the Windows Installer to not require admin priviledges in order to install wxPython. I'm not quite sure how to approach this so I thought I would ask you guys your opinions. The only thing that currently requires admin is installing or updating the MS C and C++ runtime library DLLs (MSVCRT, MSVCIRT, and MSVCP60) in the windows system dir. Way back in the dawn of time I read something that said that problems could arise if those were not installed in the system dir, but I see now that some apps (including Python if the option is selected in the installer) install those DLLs in the app dir. So which of the following approaches should I take? (These are in increasing order of complexity)

1. Always install/update those DLLs into the Python dir.

2. Check if the user has admin priviledges and install/update to the system dir if they do and to the Python dir otherwise.

3. Check if Python was installed with or without admin priviledges and then install/update the DLLs appropriately.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Robin Dunn wrote:

wxWindows 2.4.2 was released over the weekend and so I am preparing for
a wxPython release too. So if you have any patches or such pending
please try and get them to me today if possible.

Robin,

Would you like a FloatCanvas demo? I think I fixed all the issues you
brought up the last time you considered including it. I could do a
little testing and probably get it to you by the end of today.

Otherwise, maybe for 2.5

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Chris Barker wrote:

Would you like a FloatCanvas demo? I think I fixed all the issues you
brought up the last time you considered including it. I could do a
little testing and probably get it to you by the end of today.

Sure, that would be great.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

1. Always install/update those DLLs into the Python dir.

2. Check if the user has admin priviledges and install/update to the
system dir if they do and to the Python dir otherwise.

3. Check if Python was installed with or without admin priviledges and
then install/update the DLLs appropriately.

I vote for (3) because it is consistent with the way that Python itself does
it.

Jeff Grimmett wrote:

1. Always install/update those DLLs into the Python dir.

2. Check if the user has admin priviledges and install/update to the
system dir if they do and to the Python dir otherwise.

3. Check if Python was installed with or without admin priviledges and
then install/update the DLLs appropriately.

I vote for (3) because it is consistent with the way that Python itself does
it.

Thanks. This is the way I have done it, but it is a little hoaky in that it just checks for the presence of msvcrt.dll in the python dir.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Jeff Grimmett wrote:
>
>>1. Always install/update those DLLs into the Python dir.
>>
>>2. Check if the user has admin priviledges and install/update to the
>>system dir if they do and to the Python dir otherwise.
>>
>>3. Check if Python was installed with or without admin priviledges and
>>then install/update the DLLs appropriately.
>
>
> I vote for (3) because it is consistent with the way that
Python itself does
> it.

Thanks. This is the way I have done it, but it is a little hoaky in
that it just checks for the presence of msvcrt.dll in the python dir.

Actually, I misread that ... I was assuming you were going the way that
Python installs, which is to give the user the *option* to do so but to not
assume anything. THAT would be my preference but it looks like that's not
an option.

I don't know anything about the installer you use but if you can attempt to
create a hey in the HKEY_LOCAL_MACHINE registry and it succeeds, then the
user (probably) has admin privs.

Granted the view's really good here in the cheap seats :slight_smile:

Hi Robin,

Sorry, this thought just crossed my mind while discussing wxPackageManager on Pythonmac - Has wxPythonMac switched to using release versions of the libraries rather than debug versions? I think we should switch to the release versions for 2.4.x releases, and work with debug on the 2.5.x series. (Trying to trim down wxPython size on Mac to make a more convincing argument of adding it + wxPackageManager into the distro.) What do you think?

Thanks,

Kevin

···

On Tuesday, September 23, 2003, at 11:13 AM, Robin Dunn wrote:

wxWindows 2.4.2 was released over the weekend and so I am preparing for a wxPython release too. So if you have any patches or such pending please try and get them to me today if possible. (Sorry for the short notice, up until Friday it was thought that maybe the 2.5.1 release would be done last weekend and then 2.4.2 in another week or two, but it got switched around.)

Not a whole lot has changed on the wxPython side of things, other than a new version of Scintilla, but there have been a number of bug fixes in wxWindows.

I've had a number of requests for the Windows Installer to not require admin priviledges in order to install wxPython. I'm not quite sure how to approach this so I thought I would ask you guys your opinions. The only thing that currently requires admin is installing or updating the MS C and C++ runtime library DLLs (MSVCRT, MSVCIRT, and MSVCP60) in the windows system dir. Way back in the dawn of time I read something that said that problems could arise if those were not installed in the system dir, but I see now that some apps (including Python if the option is selected in the installer) install those DLLs in the app dir. So which of the following approaches should I take? (These are in increasing order of complexity)

1. Always install/update those DLLs into the Python dir.

2. Check if the user has admin priviledges and install/update to the system dir if they do and to the Python dir otherwise.

3. Check if Python was installed with or without admin priviledges and then install/update the DLLs appropriately.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org

Chris Barker wrote:

Robin Dunn wrote:

wxWindows 2.4.2 was released over the weekend and so I am preparing for
a wxPython release too. So if you have any patches or such pending
please try and get them to me today if possible.

Robin,

Would you like a FloatCanvas demo? I think I fixed all the issues you
brought up the last time you considered including it. I could do a
little testing and probably get it to you by the end of today.

Hi Chris,

Since I didn't hear from you I went ahead and added the current FloatCanvas from:

ftp://ftp.orr.noaa.gov/From_ORR/HMRD/FromChris/FloatCanvas.zip.

I've made a few tweaks for better integration with the demo, for the float --> int warnings, and such. So if you have additional changes then please send them as CVS diffs as described at the bottom of:

http://wxpython.org/codeguidelines.php

Thanks!

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Robin Dunn wrote:

Since I didn't hear from you I went ahead and added the current
FloatCanvas from:

ftp://ftp.orr.noaa.gov/From_ORR/HMRD/FromChris/FloatCanvas.zip.

I've made a few tweaks for better integration with the demo, for the
float --> int warnings, and such. So if you have additional changes
then please send them as CVS diffs as described at the bottom of:

http://wxpython.org/codeguidelines.php

thanks, Robin, I got caught up in another project. ARe you happy wiht
what you ahve now? If so, I am, I havn't changed much since that
version. If there is anything else you want for it, or want changed, I
might be able to do it if you tell me soon (before 5:00pm today, Pacific
time). Otherwise, it'll be nice to see it in the distro.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Kevin Ollivier wrote:

Hi Robin,

Sorry, this thought just crossed my mind while discussing wxPackageManager on Pythonmac - Has wxPythonMac switched to using release versions of the libraries rather than debug versions? I think we should switch to the release versions for 2.4.x releases, and work with debug on the 2.5.x series. (Trying to trim down wxPython size on Mac to make a more convincing argument of adding it + wxPackageManager into the distro.) What do you think?

I don't think that it is going to make that much difference in size. Let me explain: There are a few different "debug" options for building wxWindows. Most have to do with debug info for the debugger, but there is also the option to define the __WXDEBUG__ flag which activates the runtime checks and asserts in the code which get turned into wxPyAssertionError exceptions by wxPython.

wxWindows' configure option --enable-debug will turn on all debugging options and also the __WXDEBUG__ flag, and that is usually what I use for development.

However for the distribution builds I use --enable-optimise (adds -O2 or similar for compiler optimizations) and --enable-debug_flag (adds -D__WXDEBUG__) so there there should be no debugger type/line info taking up space. (Although distutils may hav ebeen adding -g for the wxPython builds. The Python install I am currently using does not.) The only extra space will be __WXDEBUG__ stuff in the C++ code and it really shouldn't be very much compared to the rest of the library.

That said, I'm going to try leaving off the __WXDEBUG__ for the wxPythonOSX 2.4.2.1 build that I'll be letting you guys play with later today. I really hate losing the code for generating wxPyAssertionError because otherwise if you do something wrong you'll be more likely to get a crash instead of the exception. But I did notice a significant boost in startup time without it, and a little bit of improvement elsewhere as well. There is almost no speed difference on the other platforms and so I didn't think to try it on OSX until today. I guess I should look at doing a change in 2.5 that uses a different flag for activating the runtime-checks but that leaves other __WXDEBUG__ code turned off.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hi Robin,

Cool, thanks!

Not sure why the wxMac code would get bogged down more than other ports, but I think the speed boost will be important to help get it accepted for Mac development against it's lickable competitor PyObjC. :wink: I think the important thing is to try and shake the impression that wxPython is a second-class citizen on Mac and can't compete with the 'native' tools. When I play with the new version, I'm going to review the demo to see if I can find any places where I can cause a crash to occur. I've learned a bit more about how wxMac works over my various adventures so I may even be able to submit a patch or two. Hopefully in the end you won't miss that assert dialog so much. =)

I'm also going to look at what would be needed to get Mac apps to register apple+Q to quit the application on OS X, and the shortcut for Preferences as well. It gets registered in the File menu, but not in the System menu like it should be.

Lastly, I'll also look at a wxMozilla installer for this new version, as I have managed to - for real this time - remove the moving and sizing glitches that plagued the Mac port. Turns out I needed to override some MacSuper virtual methods as well as MacRedraw. Let me know when I can begin having fun... :wink:

Thanks,

Kevin

···

On Friday, September 26, 2003, at 12:56 PM, Robin Dunn wrote:

Kevin Ollivier wrote:

Hi Robin,
Sorry, this thought just crossed my mind while discussing wxPackageManager on Pythonmac - Has wxPythonMac switched to using release versions of the libraries rather than debug versions? I think we should switch to the release versions for 2.4.x releases, and work with debug on the 2.5.x series. (Trying to trim down wxPython size on Mac to make a more convincing argument of adding it + wxPackageManager into the distro.) What do you think?

I don't think that it is going to make that much difference in size. Let me explain: There are a few different "debug" options for building wxWindows. Most have to do with debug info for the debugger, but there is also the option to define the __WXDEBUG__ flag which activates the runtime checks and asserts in the code which get turned into wxPyAssertionError exceptions by wxPython.

wxWindows' configure option --enable-debug will turn on all debugging options and also the __WXDEBUG__ flag, and that is usually what I use for development.

However for the distribution builds I use --enable-optimise (adds -O2 or similar for compiler optimizations) and --enable-debug_flag (adds -D__WXDEBUG__) so there there should be no debugger type/line info taking up space. (Although distutils may hav ebeen adding -g for the wxPython builds. The Python install I am currently using does not.) The only extra space will be __WXDEBUG__ stuff in the C++ code and it really shouldn't be very much compared to the rest of the library.

That said, I'm going to try leaving off the __WXDEBUG__ for the wxPythonOSX 2.4.2.1 build that I'll be letting you guys play with later today. I really hate losing the code for generating wxPyAssertionError because otherwise if you do something wrong you'll be more likely to get a crash instead of the exception. But I did notice a significant boost in startup time without it, and a little bit of improvement elsewhere as well. There is almost no speed difference on the other platforms and so I didn't think to try it on OSX until today. I guess I should look at doing a change in 2.5 that uses a different flag for activating the runtime-checks but that leaves other __WXDEBUG__ code turned off.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org

Kevin Ollivier wrote:

I'm also going to look at what would be needed to get Mac apps to register apple+Q to quit the application on OS X, and the shortcut for Preferences as well. It gets registered in the File menu, but not in the System menu like it should be.

IIRC, they are updated if the app is in its own bundle, but it doesn't work if you are just running with pythonw (so you are using Python.app's bundle and menu.)

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Kevin Ollivier wrote:

I'm also going to look at what would be needed to get Mac apps to register apple+Q to quit the application on OS X, and the shortcut for Preferences as well. It gets registered in the File menu, but not in the System menu like it should be.

IIRC, they are updated if the app is in its own bundle, but it doesn't work if you are just running with pythonw (so you are using Python.app's bundle and menu.)

YDRC (you do remember correctly =). Playing with the new release now. =)

Thanks,

Kevin

···

On Friday, September 26, 2003, at 05:11 PM, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org