|
|
|
Ed Musgrove-2
|
Please find attached fixFinalDisapWindow.patch, it is an update to the
patch I sent this morning--use this one. One tiny behavior change was made--when cascading and marching windows eventually automatically reduced in size to an unacceptable level, I chose to use the user's most recently stored prefs values (if available) instead of the defaultWindow value for the new window's size and location. I also did a lot of housecleaning--I was calling the same function to get unchanging data every pass through nested for-loops. I moved all of them out of the loops. I also switched to "break" instead of manually trying to set the loop counter out-of-bounds--much cleaner and I had had problems with the calculations being off-by-one yesterday). --Ed ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Martyn Shaw-2
|
Hi Ed
I have not had time to look at your patch in detail, and I don't have more than one monitor to test on. However you certainly seem to have put a lot of great thoughts into it and I have a strong feeling that it's 'better than we have'. If 'we' didn't review the code but committed it anyway (not that I intend to), what are the associated risks to the release of 2.0? Will people be able to upgrade without any retrograde behaviour? Thanks Martyn Ed Musgrove wrote: > Please find attached fixFinalDisapWindow.patch, it is an update to the > patch I sent this morning--use this one. > > One tiny behavior change was made--when cascading and marching windows > eventually automatically reduced in size to an unacceptable level, I chose > to use the user's most recently stored prefs values (if available) instead > of the defaultWindow value for the new window's size and location. > > I also did a lot of housecleaning--I was calling the same function to get > unchanging data every pass through nested for-loops. I moved all of them out > of the loops. I also switched to "break" instead of manually trying to set > the loop counter out-of-bounds--much cleaner and I had had problems with the > calculations being off-by-one yesterday). > > --Ed > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > > > ------------------------------------------------------------------------ > > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Ed Musgrove-2
|
> -----Original Message-----
> From: Martyn Shaw [mailto:[hidden email]] > Sent: Thursday, October 22, 2009 3:42 PM > To: [hidden email] > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > Hi Ed > > I have not had time to look at your patch in detail, and I don't have more than > one monitor to test on. However you certainly seem to have put a lot of > great thoughts into it and I have a strong feeling that it's 'better than we > have'. If 'we' didn't review the code but committed it anyway (not that I > intend to), what are the associated risks to the release of 2.0? Will people be > able to upgrade without any retrograde behaviour? > > Thanks > Martyn [Ed:] This endeavor started out to repair a bug which presented as Audacity launching with no visible window and no way of making a window visible. After examining the only known condition which reliably repeated the bug I identified a few other situations which would result in a similar situation. As with many bugs, the only way to activate the bug was convoluted. Eventually, I decided that the presentation of this bug was due to opening the main project window at a location and size which was not on the user's current screen(s). There were at least two methods which would result in this. The "final" patch made it impossible (I hope) for this to happen anew. The "fix final" patch has redundancy which checks to ensure that no window is ever opened offscreen. It is still possible to create the problem by running stable 1.2.6 which might save those values to the registry (though I use which are picked up by 1.3.9) the "final" patch was not able to deal with that; the "fix final" patch does. The rest is all eye candy and will, at worst, be thought of as ugly GUI. Unfortunately, the eye candy relies on known buggy code in wxWidgets. Recent posts by wxWidgets developers make me believe that they are currently addressing these issues. The patch I present should work all right even given the known bugs in wxWidgets, if those bugs are repaired, my GUI code might even be a little tidier looking. We're only talking about a few pixels here and there in window placement or sizing. The only real concern I have is that the patch has not been tested (to the best of my knowledge) on Mac where the known wxWidgets bugs reside. > > > Ed Musgrove wrote: > > Please find attached fixFinalDisapWindow.patch, it is an update to > > the patch I sent this morning--use this one. > > > > One tiny behavior change was made--when cascading and marching > windows > > eventually automatically reduced in size to an unacceptable level, I > > chose to use the user's most recently stored prefs values (if > > available) instead of the defaultWindow value for the new window's size > and location. > > > > I also did a lot of housecleaning--I was calling the same function to > > get unchanging data every pass through nested for-loops. I moved all > > of them out of the loops. I also switched to "break" instead of > > manually trying to set the loop counter out-of-bounds--much cleaner > > and I had had problems with the calculations being off-by-one > > > > --Ed > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > ---------------------------------------------------------------------- > > -------- Come build with us! The BlackBerry(R) Developer Conference in > > SF, CA is the only developer event you need to attend this year. > > Jumpstart your developing skills, take BlackBerry mobile applications > > to market and stay ahead of the curve. Join us from November 9 - 12, > > 2009. Register now! > > http://p.sf.net/sfu/devconference > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > audacity-devel mailing list > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the > only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel --Ed ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Gale (Audacity Team)
|
In reply to this post
by Ed Musgrove-2
| From "Ed Musgrove" <[hidden email]> | Wed, 21 Oct 2009 20:32:58 -0700 | Subject: [Audacity-devel] [re] final Disapearing Window patch > Please find attached fixFinalDisapWindow.patch, it is an update to > the patch I sent this morning--use this one. > One tiny behavior change was made--when cascading and marching windows > eventually automatically reduced in size to an unacceptable level, I chose > to use the user's most recently stored prefs values (if available) instead > of the defaultWindow value for the new window's size and location. Tested on and available here for Windows if anyone needs it: http://www.gaclrecords.org.uk/audacity-win-unicode-1.3.10-alpha.zip No problems with 800x600 this time, except when the first window did not start at left edge, I still think using the space to left of the original window might be handy. At the non-default size and location I tried, I just got sets of three windows piled on top of each other. But not a big point. One thing that did not work for me at either 800x600 or 1024x768 was starting from the default window size/location. When the last acceptable window size was reached by the marching windows, the next window always had the title bar off screen to the top. You didn't say anything about my question "what progress did you make Ed with the problem when you reach the limit for the number of windows that Audacity can handle?" While we're at this, can we do anything about moving the Taskbar from the bottom to the left or top after exiting Audacity, so masking some of the window at default location ? The Audacity Title Bar is covered when the Taskbar is at the top (with my tallish Taskbar anyway). Thanks Gale ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Ed Musgrove-2
|
> -----Original Message-----
window
> From: Gale Andrews [mailto:[hidden email]] > Sent: Friday, October 23, 2009 1:25 AM > To: [hidden email] > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > > | From "Ed Musgrove" <[hidden email]> Wed, 21 Oct 2009 > | 20:32:58 -0700 > | Subject: [Audacity-devel] [re] final Disapearing Window patch > > Please find attached fixFinalDisapWindow.patch, it is an update to > > the patch I sent this morning--use this one. > > One tiny behavior change was made--when cascading and marching > windows > > eventually automatically reduced in size to an unacceptable level, I > > chose to use the user's most recently stored prefs values (if > > available) instead of the defaultWindow value for the new window's size > and location. > > Tested on and available here for Windows if anyone needs it: > http://www.gaclrecords.org.uk/audacity-win-unicode-1.3.10-alpha.zip > > No problems with 800x600 this time, except when the first window did not > start at left edge, I still think using the space to left of the original > might be handy. At the non-default size and location I tried, I just got sets of > three windows piled on top of each other. But not a big point. > [Ed:] Could you send me some screenshots off list please? > One thing that did not work for me at either 800x600 or 1024x768 was starting > from the default window size/location. When the last acceptable window > size was reached by the marching windows, the next window always had the > title bar off screen to the top. > [Ed:] Ditto screenshots? > > You didn't say anything about my question "what progress did you make Ed > with the problem when you reach the limit for the number of windows that > Audacity can handle?" > [Ed:] I realize that this problem was identified during the course of investigating the "Disappearing Window" bug. It is not related. If you would like to create a new bug I would suggest starting a new thread and entering it in the formal database (it might be a good test case for the new database interface which was talked about earlier). Potential bug: When a large number of project windows open Audacity becomes unresponsive. > While we're at this, can we do anything about moving the Taskbar from the > bottom to the left or top after exiting Audacity, so masking some of the > window at default location ? The Audacity Title Bar is covered when the > Taskbar is at the top (with my tallish Taskbar anyway). > [Ed:] I am hoping that my code dealing with this bug can be committed before 2.0. At this point I have gone way beyond dealing with the bug. Testing all of the new cases of behavior on all the various operating systems Audacity supports in all the given monitor situations is probably impossible. I am fairly comfortable with the situation on Vista and at least one version of Linux. Until we can get the current code committed and in the hands of the users of the nightly builds and thus get some feedback I hesitate to add more features or refinements. Additionally, wxWidgets is known to be problematical in dealing with the Mac toolbar (at the top of the screen), with taskbars that are not at the bottom of the screen and with taskbars that are not as small as possible. Recently, there has been a thread on the wxWidgets forum discussing these issues. There is also a bug report dealing with a specific symptom endemic to this issue; it is marked "patched". I therefore conclude that we should hold off trying to perform workarounds to deal with these symptoms. > > Thanks > > > Gale > > > > > > > > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel --Ed ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Gale (Audacity Team)
|
| From "Ed Musgrove" <[hidden email]> | Fri, 23 Oct 2009 16:39:11 -0700 | Subject: [Audacity-devel] [re] final Disapearing Window patch > > -----Original Message----- > > From: Gale Andrews [mailto:[hidden email]] > > Sent: Friday, October 23, 2009 1:25 AM > > To: [hidden email] > > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > | From "Ed Musgrove" <[hidden email]> Wed, 21 Oct 2009 > > | 20:32:58 -0700 > > | Subject: [Audacity-devel] [re] final Disapearing Window patch > > > Please find attached fixFinalDisapWindow.patch, it is an update to > > > the patch I sent this morning--use this one. > > > One tiny behavior change was made--when cascading and marching > > windows > > > eventually automatically reduced in size to an unacceptable level, I > > > chose to use the user's most recently stored prefs values (if > > > available) instead of the defaultWindow value for the new window's size > > and location. > > > > Tested on and available here for Windows if anyone needs it: > > http://www.gaclrecords.org.uk/audacity-win-unicode-1.3.10-alpha.zip > > > > No problems with 800x600 this time, except when the first window did not > > start at left edge, I still think using the space to left of the original > window > > might be handy. At the non-default size and location I tried, I just got > sets of > > three windows piled on top of each other. But not a big point. > > > [Ed:] > Could you send me some screenshots off list please? > > > > One thing that did not work for me at either 800x600 or 1024x768 was > starting > > from the default window size/location. When the last acceptable window > > size was reached by the marching windows, the next window always had the > > title bar off screen to the top. > > > [Ed:] > Ditto screenshots? Sent you separate e-mail with details and image links. Completely replicable issue for me. Gale ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Martyn Shaw-2
|
In reply to this post
by Ed Musgrove-2
Hi Ed
I had a good look through your patch and tried it. It all looked well so I committed it. Thanks for your efforts Martyn Ed Musgrove wrote: >> -----Original Message----- >> From: Martyn Shaw [mailto:[hidden email]] >> Sent: Thursday, October 22, 2009 3:42 PM >> To: [hidden email] >> Subject: Re: [Audacity-devel] [re] final Disapearing Window patch >> >> Hi Ed >> >> I have not had time to look at your patch in detail, and I don't have more > than >> one monitor to test on. However you certainly seem to have put a lot of >> great thoughts into it and I have a strong feeling that it's 'better than > we >> have'. If 'we' didn't review the code but committed it anyway (not that I >> intend to), what are the associated risks to the release of 2.0? Will > people be >> able to upgrade without any retrograde behaviour? >> >> Thanks >> Martyn > [Ed:] > This endeavor started out to repair a bug which presented as Audacity > launching with no visible window and no way of making a window visible. > After examining the only known condition which reliably repeated the bug I > identified a few other situations which would result in a similar situation. > As with many bugs, the only way to activate the bug was convoluted. > Eventually, I decided that the presentation of this bug was due to opening > the main project window at a location and size which was not on the user's > current screen(s). There were at least two methods which would result in > this. The "final" patch made it impossible (I hope) for this to happen anew. > The "fix final" patch has redundancy which checks to ensure that no window > is ever opened offscreen. It is still possible to create the problem by > running stable 1.2.6 which might save those values to the registry (though I > use which are picked up by 1.3.9) the "final" patch was not able to deal > with that; the "fix final" patch does. > > The rest is all eye candy and will, at worst, be thought of as ugly GUI. > Unfortunately, the eye candy relies on known buggy code in wxWidgets. Recent > posts by wxWidgets developers make me believe that they are currently > addressing these issues. The patch I present should work all right even > given the known bugs in wxWidgets, if those bugs are repaired, my GUI code > might even be a little tidier looking. We're only talking about a few pixels > here and there in window placement or sizing. > > The only real concern I have is that the patch has not been tested (to the > best of my knowledge) on Mac where the known wxWidgets bugs reside. >> >> Ed Musgrove wrote: >>> Please find attached fixFinalDisapWindow.patch, it is an update to >>> the patch I sent this morning--use this one. >>> >>> One tiny behavior change was made--when cascading and marching >> windows >>> eventually automatically reduced in size to an unacceptable level, I >>> chose to use the user's most recently stored prefs values (if >>> available) instead of the defaultWindow value for the new window's size >> and location. >>> I also did a lot of housecleaning--I was calling the same function to >>> get unchanging data every pass through nested for-loops. I moved all >>> of them out of the loops. I also switched to "break" instead of >>> manually trying to set the loop counter out-of-bounds--much cleaner >>> and I had had problems with the calculations being off-by-one > yesterday). >>> --Ed >>> >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> ---------------------------------------------------------------------- >>> -------- Come build with us! The BlackBerry(R) Developer Conference in >>> SF, CA is the only developer event you need to attend this year. >>> Jumpstart your developing skills, take BlackBerry mobile applications >>> to market and stay ahead of the curve. Join us from November 9 - 12, >>> 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> _______________________________________________ >>> audacity-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > ---------------------------------------------------------------------------- > -- >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is > the >> only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> audacity-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > --Ed > > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Gale (Audacity Team)
|
| From Martyn Shaw <[hidden email]> | Sun, 01 Nov 2009 19:31:13 +0000 | Subject: [Audacity-devel] [re] final Disapearing Window patch > Hi Ed > > I had a good look through your patch and tried it. It all looked well > so I committed it. > > > Martyn Hi Ed, Surprisingly, not as good as I was hoping. I didn't have time to retest your patch a further time on XP before Martyn committed it. I can report the following on a fresh checkout on Ubuntu 9.04 800x600: I initialised .cfg, opened a lot of new windows (the first after the end of the right-march was at the default position/size as intended), then closed all but one. This left the first default window and I dragged it to the middle of the screen and reduced height/width almost as far as I could. I exited, but on relaunch Audacity re-opened at the default position, not the new one (.cfg settings were default). I dragged that window to a similar small size in centre of the screen, maximised and exited. On relaunch the window was maximised. When I restored down it went to the small central position subliminally, then jumped back to the "four pixels less than maximised" size/position we used to have before. Repeated all the above with same result. Windows XP 1024x768: this is the fresh checkout I did yesterday with the update for the current commit for this patch. I initialised .cfg, opened a lot of new windows, and the first after the end of the right-march had the title bar off-screen at the top. This is 100% replicable here from a new .cfg. I closed all but one window. This left the first default window and I exited. Audacity restarted in default position (all on screen). I repeated all the marching windows. After close all but the first window, I dragged it to the middle of the screen and reduced height/width almost as far as I could. I exited, and on relaunch Audacity re-opened correctly at the new restored down position. I dragged that window to a similar small size in centre of the screen, maximised and exited. On relaunch the window was maximised. When I restored down it went to the correct last restored down position. I dragged the window back out a little and simulated a careless drag to default position by leaving it a little off screen to the left and top. Restarted Audacity several times but it does not appear (no taskbar icon, 100% CPU). Cfg has: [Window] X=-14 Y=-5 Width=403 Height=652 Maximized=0 Normal_X=-14 Normal_Y=-5 Normal_Width=403 Normal_Height=652 Iconized=0 Initialised cfg, restarted, dragged window to similar off screen position, exit and restart. This time, Audacity relaunched at default position as expected. Gale > Ed Musgrove wrote: > >> -----Original Message----- > >> From: Martyn Shaw [mailto:[hidden email]] > >> Sent: Thursday, October 22, 2009 3:42 PM > >> To: [hidden email] > >> Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > >> > >> Hi Ed > >> > >> I have not had time to look at your patch in detail, and I don't have more > > than > >> one monitor to test on. However you certainly seem to have put a lot of > >> great thoughts into it and I have a strong feeling that it's 'better than > > we > >> have'. If 'we' didn't review the code but committed it anyway (not that I > >> intend to), what are the associated risks to the release of 2.0? Will > > people be > >> able to upgrade without any retrograde behaviour? > >> > >> Thanks > >> Martyn > > [Ed:] > > This endeavor started out to repair a bug which presented as Audacity > > launching with no visible window and no way of making a window visible. > > After examining the only known condition which reliably repeated the bug I > > identified a few other situations which would result in a similar situation. > > As with many bugs, the only way to activate the bug was convoluted. > > Eventually, I decided that the presentation of this bug was due to opening > > the main project window at a location and size which was not on the user's > > current screen(s). There were at least two methods which would result in > > this. The "final" patch made it impossible (I hope) for this to happen anew. > > The "fix final" patch has redundancy which checks to ensure that no window > > is ever opened offscreen. It is still possible to create the problem by > > running stable 1.2.6 which might save those values to the registry (though I > > use which are picked up by 1.3.9) the "final" patch was not able to deal > > with that; the "fix final" patch does. > > > > The rest is all eye candy and will, at worst, be thought of as ugly GUI. > > Unfortunately, the eye candy relies on known buggy code in wxWidgets. Recent > > posts by wxWidgets developers make me believe that they are currently > > addressing these issues. The patch I present should work all right even > > given the known bugs in wxWidgets, if those bugs are repaired, my GUI code > > might even be a little tidier looking. We're only talking about a few pixels > > here and there in window placement or sizing. > > > > The only real concern I have is that the patch has not been tested (to the > > best of my knowledge) on Mac where the known wxWidgets bugs reside. > >> > >> Ed Musgrove wrote: > >>> Please find attached fixFinalDisapWindow.patch, it is an update to > >>> the patch I sent this morning--use this one. > >>> > >>> One tiny behavior change was made--when cascading and marching > >> windows > >>> eventually automatically reduced in size to an unacceptable level, I > >>> chose to use the user's most recently stored prefs values (if > >>> available) instead of the defaultWindow value for the new window's size > >> and location. > >>> I also did a lot of housecleaning--I was calling the same function to > >>> get unchanging data every pass through nested for-loops. I moved all > >>> of them out of the loops. I also switched to "break" instead of > >>> manually trying to set the loop counter out-of-bounds--much cleaner > >>> and I had had problems with the calculations being off-by-one > > yesterday). > >>> --Ed > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> -- > >>> > >>> ---------------------------------------------------------------------- > >>> -------- Come build with us! The BlackBerry(R) Developer Conference in > >>> SF, CA is the only developer event you need to attend this year. > >>> Jumpstart your developing skills, take BlackBerry mobile applications > >>> to market and stay ahead of the curve. Join us from November 9 - 12, > >>> 2009. Register now! > >>> http://p.sf.net/sfu/devconference > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> -- > >>> > >>> _______________________________________________ > >>> audacity-devel mailing list > >>> [hidden email] > >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel > >> > > ---------------------------------------------------------------------------- > > -- > >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is > > the > >> only developer event you need to attend this year. Jumpstart your > >> developing skills, take BlackBerry mobile applications to market and stay > >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! > >> http://p.sf.net/sfu/devconference > >> _______________________________________________ > >> audacity-devel mailing list > >> [hidden email] > >> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > --Ed > > > > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Ed Musgrove-2
|
Let me investigate and report back...
--Ed > -----Original Message----- > From: Gale Andrews [mailto:[hidden email]] > Sent: Monday, November 02, 2009 2:50 AM > To: [hidden email] > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > > | From Martyn Shaw <[hidden email]> Sun, 01 Nov 2009 > | 19:31:13 +0000 > | Subject: [Audacity-devel] [re] final Disapearing Window patch > > Hi Ed > > > > I had a good look through your patch and tried it. It all looked well > > so I committed it. > > > > > > Martyn > > Hi Ed, > > Surprisingly, not as good as I was hoping. I didn't have time to retest > patch a further time on XP before Martyn committed it. > > I can report the following on a fresh checkout on Ubuntu 9.04 800x600: > > I initialised .cfg, opened a lot of new windows (the first after the end of the > right-march was at the default position/size as intended), then closed all but > one. This left the first default window and I dragged it to the middle of the > screen and reduced height/width almost as far as I could. I exited, but on > relaunch Audacity re-opened at the default position, not the new one (.cfg > settings were default). > > I dragged that window to a similar small size in centre of the screen, > maximised and exited. On relaunch the window was maximised. When I > restored down it went to the small central position subliminally, then jumped > back to the "four pixels less than maximised" size/position we used to have > before. > > Repeated all the above with same result. > > > Windows XP 1024x768: this is the fresh checkout I did yesterday with the > update for the current commit for this patch. > > I initialised .cfg, opened a lot of new windows, and the first after the end of > the right-march had the title bar off-screen at the top. > This is 100% replicable here from a new .cfg. I closed all but one window. This > left the first default window and I exited. Audacity restarted in default > position (all on screen). > > I repeated all the marching windows. After close all but the first window, I > dragged it to the middle of the screen and reduced height/width almost as > far as I could. I exited, and on relaunch Audacity re-opened correctly at the > new restored down position. > > I dragged that window to a similar small size in centre of the screen, > maximised and exited. On relaunch the window was maximised. When I > restored down it went to the correct last restored down position. > > I dragged the window back out a little and simulated a careless drag to > default position by leaving it a little off screen to the left and top. Restarted > Audacity several times but it does not appear (no taskbar icon, 100% CPU). > Cfg has: > > [Window] > X=-14 > Y=-5 > Width=403 > Height=652 > Maximized=0 > Normal_X=-14 > Normal_Y=-5 > Normal_Width=403 > Normal_Height=652 > Iconized=0 > > Initialised cfg, restarted, dragged window to similar off screen position, > and restart. This time, Audacity relaunched at default position as expected. > > > > > Gale > > > > > Ed Musgrove wrote: > > >> -----Original Message----- > > >> From: Martyn Shaw [mailto:[hidden email]] > > >> Sent: Thursday, October 22, 2009 3:42 PM > > >> To: [hidden email] > > >> Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > >> > > >> Hi Ed > > >> > > >> I have not had time to look at your patch in detail, and I don't > > >> have more > > > than > > >> one monitor to test on. However you certainly seem to have put a > > >> lot of great thoughts into it and I have a strong feeling that it's > > >> 'better than > > > we > > >> have'. If 'we' didn't review the code but committed it anyway (not > > >> that I intend to), what are the associated risks to the release of > > >> 2.0? Will > > > people be > > >> able to upgrade without any retrograde behaviour? > > >> > > >> Thanks > > >> Martyn > > > [Ed:] > > > This endeavor started out to repair a bug which presented as > > > Audacity launching with no visible window and no way of making a > window visible. > > > After examining the only known condition which reliably repeated the > > > bug I identified a few other situations which would result in a > situation. > > > As with many bugs, the only way to activate the bug was convoluted. > > > Eventually, I decided that the presentation of this bug was due to > > > opening the main project window at a location and size which was not > > > on the user's current screen(s). There were at least two methods > > > which would result in this. The "final" patch made it impossible (I hope) > for this to happen anew. > > > The "fix final" patch has redundancy which checks to ensure that no > > > window is ever opened offscreen. It is still possible to create the > > > problem by running stable 1.2.6 which might save those values to the > > > registry (though I use which are picked up by 1.3.9) the "final" > > > patch was not able to deal with that; the "fix final" patch does. > > > > > > The rest is all eye candy and will, at worst, be thought of as ugly GUI. > > > Unfortunately, the eye candy relies on known buggy code in > > > wxWidgets. Recent posts by wxWidgets developers make me believe > that > > > they are currently addressing these issues. The patch I present > > > should work all right even given the known bugs in wxWidgets, if > > > those bugs are repaired, my GUI code might even be a little tidier > > > looking. We're only talking about a few pixels here and there in window > placement or sizing. > > > > > > The only real concern I have is that the patch has not been tested > > > (to the best of my knowledge) on Mac where the known wxWidgets > bugs reside. > > >> > > >> Ed Musgrove wrote: > > >>> Please find attached fixFinalDisapWindow.patch, it is an update > > >>> to the patch I sent this morning--use this one. > > >>> > > >>> One tiny behavior change was made--when cascading and marching > > >> windows > > >>> eventually automatically reduced in size to an unacceptable level, > > >>> I chose to use the user's most recently stored prefs values (if > > >>> available) instead of the defaultWindow value for the new window's > > >>> size > > >> and location. > > >>> I also did a lot of housecleaning--I was calling the same function > > >>> to get unchanging data every pass through nested for-loops. I > > >>> moved all of them out of the loops. I also switched to "break" > > >>> instead of manually trying to set the loop counter > > >>> out-of-bounds--much cleaner and I had had problems with the > > >>> calculations being off-by-one > > > yesterday). > > >>> --Ed > > >>> > > >>> > > >>> > > >>> ------------------------------------------------------------------ > > >>> ---- > > >>> -- > > >>> > > >>> ------------------------------------------------------------------ > > >>> ---- > > >>> -------- Come build with us! The BlackBerry(R) Developer > > >>> Conference in SF, CA is the only developer event you need to attend > this year. > > >>> Jumpstart your developing skills, take BlackBerry mobile > > >>> applications to market and stay ahead of the curve. Join us from > > >>> November 9 - 12, 2009. Register now! > > >>> http://p.sf.net/sfu/devconference > > >>> > > >>> > > >>> ------------------------------------------------------------------ > > >>> ---- > > >>> -- > > >>> > > >>> _______________________________________________ > > >>> audacity-devel mailing list > > >>> [hidden email] > > >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > >> > > > -------------------------------------------------------------------- > > > -------- > > > -- > > >> Come build with us! The BlackBerry(R) Developer Conference in SF, > > >> CA is > > > the > > >> only developer event you need to attend this year. Jumpstart your > > >> developing skills, take BlackBerry mobile applications to market > > >> and stay ahead of the curve. Join us from November 9 - 12, 2009. > Register now! > > >> http://p.sf.net/sfu/devconference > > >> _______________________________________________ > > >> audacity-devel mailing list > > >> [hidden email] > > >> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > > > --Ed > > > > > > > > > > > > > ---------------------------------------------------------------------- > > -------- Come build with us! The BlackBerry(R) Developer Conference in > > SF, CA is the only developer event you need to attend this year. > > Jumpstart your developing skills, take BlackBerry mobile applications > > to market and stay ahead of the curve. Join us from November 9 - 12, > > 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > audacity-devel mailing list > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the > only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Leland (Audacity Team)
|
In reply to this post
by Ed Musgrove-2
Hi Ed,
I'm working on a loop on the Mac and I was wondering if you could give me a hint as to what the "for (int i...)" and "for (int j...)" loops in GetNextWindowPlacement() are doing? Except for the 3rd one, they all appear to do the same thing. (Be gentle if I missed something obvious.) The 3rd one (the "+-" case) is the one that's causing a loop on the Mac. Consider the following: targetLeft = 14; targetRight = 178; targetTop = -1; targetBottom = 13 These values cause the "+-" case and since j is decremented from "-1", it takes a VERY long time to get to targetBottom. Leland Ed Musgrove wrote: > Please find attached fixFinalDisapWindow.patch, it is an update to the > patch I sent this morning--use this one. > > One tiny behavior change was made--when cascading and marching windows > eventually automatically reduced in size to an unacceptable level, I chose > to use the user's most recently stored prefs values (if available) instead > of the defaultWindow value for the new window's size and location. > > I also did a lot of housecleaning--I was calling the same function to get > unchanging data every pass through nested for-loops. I moved all of them out > of the loops. I also switched to "break" instead of manually trying to set > the loop counter out-of-bounds--much cleaner and I had had problems with the > calculations being off-by-one yesterday). > > --Ed > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > > > ------------------------------------------------------------------------ > > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Ed Musgrove-2
|
Hi Leland!
Unfortunately, I have not been able to get anyone to apply the most current patch (I do not have commit permission and probably have not earned it). Within the last few minutes I downloaded the CVS HEAD then made all of my final changes to that source code. Attached please find GNWP.patch which, when applied, will address the issues you note below. I was taught to insert comments (telling why, not necessarily how) so I have been doing so in the Audacity source code which I modified. I have also been dating in signing any major changes that I made. I have been asked to remove these comments so I've done so for the patch. Could I impose on you to apply this patch? It has been reasonably well beta tested on XP, Vista, Windows 7, Mac (Intel not PPC) and at least one version of Linux. Find attached a text file (source with comments.txt) with the pertinent code, comments left intact. Here are the instructions I have given the beta testers: *Open your audacity.cfg file (I don't know where it is on Linux) delete all but the first line. *Run Audacity. The project window should open in the default position. *Open a new project. This new project window should open slightly to the right and slightly down (cascade-style 25 pixels right and 25 pixels down). Unless the original project window was very wide or tall this new project window should be the same size. *Open a few more new projects. They should continue cascading but when either edge (bottom or right) reach the screen edge the behavior should change. When a new project window's right edge would go off the screen, that new window's width is reduced to keep it on screen. One a new project window's bottom edge would go off the screen, that new window's top edge is moved up so that it is level with the previous project window (marching-style 25 pixels right and 0 pixels down). Eventually, when you've created enough new project windows, the resulting new window would be smaller than the minimum that Audacity allows. At that point the next new project window will be created at the user's stored preferred location but will maintain the height of the previous project window. *Close all but one of the project Windows. *Move and resize that window so that it is obviously different from the default window which opened initially. *Close Audacity. *Restart Audacity. The resulting new project window should open in the same size and location as it was when you just quit Audacity. *Move and resize that window so that it is again obviously different from the default window and from the condition in which it just opened. *Maximize that project window. *Close Audacity. *Restart Audacity. The resulting new project window should open maximized. *Restore down that project window. It should return to the size and location it was in when you close audacity the last time. *Try anything that you can think of to confuse Audacity about window location! A word of warning, at some point Audacity blows up after creating a large number of new projects. The number of new projects that a user may create seems to be highly dependent upon the operating system (XP allows about 24, Vista allows about 36, Mac and Linux allow about 80). If you get to this condition you will need to use the operating system or the debugger to exit the program. --Ed > -----Original Message----- > From: Leland [mailto:[hidden email]] > Sent: Saturday, November 07, 2009 4:51 PM > To: [hidden email] > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > Hi Ed, > > I'm working on a loop on the Mac and I was wondering if you could give me a > hint as to what the "for (int i...)" and "for (int j...)" loops in > GetNextWindowPlacement() are doing? Except for the 3rd one, they all > appear to do the same thing. (Be gentle if I missed something obvious.) > > The 3rd one (the "+-" case) is the one that's causing a loop on the Mac. > Consider the following: > > targetLeft = 14; > targetRight = 178; > targetTop = -1; > targetBottom = 13 > > These values cause the "+-" case and since j is decremented from "-1", it > takes a VERY long time to get to targetBottom. > > Leland > > Ed Musgrove wrote: > > Please find attached fixFinalDisapWindow.patch, it is an update to > > the patch I sent this morning--use this one. > > > > One tiny behavior change was made--when cascading and marching > windows > > eventually automatically reduced in size to an unacceptable level, I > > chose to use the user's most recently stored prefs values (if > > available) instead of the defaultWindow value for the new window's size > and location. > > > > I also did a lot of housecleaning--I was calling the same function to > > get unchanging data every pass through nested for-loops. I moved all > > of them out of the loops. I also switched to "break" instead of > > manually trying to set the loop counter out-of-bounds--much cleaner > > and I had had problems with the calculations being off-by-one > > > > --Ed > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > ---------------------------------------------------------------------- > > -------- Come build with us! The BlackBerry(R) Developer Conference in > > SF, CA is the only developer event you need to attend this year. > > Jumpstart your developing skills, take BlackBerry mobile applications > > to market and stay ahead of the curve. Join us from November 9 - 12, > > 2009. Register now! > > http://p.sf.net/sfu/devconference > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > audacity-devel mailing list > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with Crystal > Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel bool IsWindowAssessable(wxRect *requestedRect) { // define a rectangular region of the window's title bar and determine if any portion // of it is in the desktopand is therefor available to be dragged by the use // this will insure that the new window is always accessible to the user wxMessageBox("iwa"); /*efm5*/ wxDisplay display; wxRect targetTitleRect(requestedRect->GetLeftTop(), requestedRect->GetBottomRight()); targetTitleRect.x += 15; // ignore title bar icon region targetTitleRect.width -= 100; // ignore min max & close icons if (targetTitleRect.width < 165) targetTitleRect.width = 165; // 165 pixels of window width to grab a hold of targetTitleRect.height = 15; // 15 pixels of window height to grab a hold of int targetBottom = targetTitleRect.GetBottom(); int targetRight = targetTitleRect.GetRight(); for (int i = targetTitleRect.GetLeft(); i < targetRight; i++) { for (int j = targetTitleRect.GetTop(); j < targetBottom; j++) { int monitor = display.GetFromPoint(wxPoint(i, j)); if (monitor != wxNOT_FOUND) { return TRUE; } } } return FALSE; } // BG: Calculate where to place the next window (could be the first window) // BG: Does not store X and Y in prefs. This is intentional. void GetNextWindowPlacement(wxRect *nextRect, bool *pMaximized, bool *pIconized) { // This code was heavily modified to deal with iconized // and maximized project windows // Ed Musgrove // 28 September 2009 -- 21 October 2009 int inc = 25; *pMaximized = FALSE; *pIconized = FALSE; wxRect defaultWindowRect; GetDefaultWindowRect(&defaultWindowRect); if (gAudacityProjects.IsEmpty()) { //Read the values from the registry, or use the defaults // In version 1.3 and above, using the registry has been replaced // by a configuration file -- audacity.cfg. Different OSes store // this file in different locations. gPrefs->Read(wxT("/Window/Maximized"), pMaximized); gPrefs->Read(wxT("/Window/Iconized"), pIconized); if (pMaximized || pIconized) { nextRect->SetX(gPrefs->Read(wxT("/Window/Normal_X"), defaultWindowRect.GetX())); nextRect->SetY(gPrefs->Read(wxT("/Window/Normal_Y"), defaultWindowRect.GetY())); nextRect->SetWidth(gPrefs->Read(wxT("/Window/Normal_Width"), defaultWindowRect.GetWidth())); nextRect->SetHeight(gPrefs->Read(wxT("/Window/Normal_Height"), defaultWindowRect.GetHeight())); } else { nextRect->SetX(gPrefs->Read(wxT("/Window/X"), defaultWindowRect.GetX())); nextRect->SetY(gPrefs->Read(wxT("/Window/Y"), defaultWindowRect.GetY())); nextRect->SetWidth(gPrefs->Read(wxT("/Window/Width"), defaultWindowRect.GetWidth())); nextRect->SetHeight(gPrefs->Read(wxT("/Window/Height"), defaultWindowRect.GetHeight())); } if (!IsWindowAssessable(nextRect)) { // the default values are guaranteed to be on the main monitor // completely visible and accessible nextRect->SetX(defaultWindowRect.GetX()); nextRect->SetY(defaultWindowRect.GetY()); nextRect->SetWidth(defaultWindowRect.GetWidth()); nextRect->SetHeight(defaultWindowRect.GetHeight()); } } else { bool validWindowSize = FALSE; AudacityProject * validProject = NULL; size_t numProjects = gAudacityProjects.Count(); for (int i = numProjects; i > 0 ; i--) // read these backwards so that new project locations will increment off the newest project window { if (!gAudacityProjects[i-1]->IsIconized()) { validWindowSize = TRUE; validProject = gAudacityProjects[i-1]; i = 0; } } if (validWindowSize) { *nextRect = validProject->GetRect(); *pMaximized = validProject->IsMaximized(); *pIconized = validProject->IsIconized(); } else { nextRect->SetX(gPrefs->Read(wxT("/Window/Normal_X"), defaultWindowRect.GetX())); nextRect->SetY(gPrefs->Read(wxT("/Window/Normal_Y"), defaultWindowRect.GetY())); nextRect->SetWidth(gPrefs->Read(wxT("/Window/Normal_Width"), defaultWindowRect.GetWidth())); nextRect->SetHeight(gPrefs->Read(wxT("/Window/Normal_Height"), defaultWindowRect.GetHeight())); gPrefs->Read(wxT("/Window/Maximized"), pMaximized); gPrefs->Read(wxT("/Window/Iconized"), pIconized); } //Placement depends on the increments nextRect->SetX(nextRect->GetX() + inc); //nextRect->x += inc; nextRect->SetY(nextRect->GetY() + inc); //nextRect->y += inc; } //Make sure that the Window will be completely visible //Get the size of the screen wxRect screenRect = wxGetClientDisplayRect(); // We do not want to reset the increments unless the top left corner of the new window // gets too near the bottom right hand corner of the screen -- also, make sure the // window fits on the screen // Ed Musgrove // 16 October 2009 //Have we hit the right side of the screen? wxPoint bottomRight = nextRect->GetBottomRight(); if (bottomRight.x > screenRect.GetRight()) { int newWidth = screenRect.GetWidth() - nextRect->GetLeft(); if (newWidth < defaultWindowRect.GetWidth()) { // try to use as much of the user's preferred Project window state as possible nextRect->SetX(gPrefs->Read(wxT("/Window/X"), defaultWindowRect.GetX())); nextRect->SetY(gPrefs->Read(wxT("/Window/Y"), defaultWindowRect.GetY())); nextRect->SetWidth(gPrefs->Read(wxT("/Window/Width"), defaultWindowRect.GetWidth())); } else { nextRect->SetWidth(newWidth); } } bottomRight = nextRect->GetBottomRight(); //Have we hit the bottom of the screen? if (bottomRight.y > screenRect.GetBottom()) { nextRect->y -= inc; //we will need to test again since we have moved the window down bottomRight = nextRect->GetBottomRight(); if (bottomRight.y > screenRect.GetBottom()) { int newheight = screenRect.GetHeight() - nextRect->GetBottom(); nextRect->SetBottom(screenRect.GetBottom()); } } if (!IsWindowAssessable(nextRect)) { // the default values are guaranteed to be on the main monitor // completely visible and accessible nextRect->SetX(defaultWindowRect.GetX()); nextRect->SetY(defaultWindowRect.GetY()); nextRect->SetWidth(defaultWindowRect.GetWidth()); nextRect->SetHeight(defaultWindowRect.GetHeight()); } } ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Leland (Audacity Team)
|
Committed and it does indeed correct the loop. I'm also thinking that
this corrects: P2 (Mac) Hang when scanning for VST effects on fresh install. But, there'll have to be more confirmation. Leland Ed Musgrove wrote: > Hi Leland! > > Unfortunately, I have not been able to get anyone to apply the most current > patch (I do not have commit permission and probably have not earned it). > > Within the last few minutes I downloaded the CVS HEAD then made all of my > final changes to that source code. Attached please find GNWP.patch which, > when applied, will address the issues you note below. > > I was taught to insert comments (telling why, not necessarily how) so I have > been doing so in the Audacity source code which I modified. > I have also been dating in signing any major changes that I made. > I have been asked to remove these comments so I've done so for the patch. > > Could I impose on you to apply this patch? It has been reasonably well beta > tested on XP, Vista, Windows 7, Mac (Intel not PPC) and at least one version > of Linux. > > Find attached a text file (source with comments.txt) with the pertinent > code, comments left intact. > > Here are the instructions I have given the beta testers: > > *Open your audacity.cfg file (I don't know where it is on Linux) delete all > but the first line. > *Run Audacity. > The project window should open in the default position. > *Open a new project. > This new project window should open slightly to the right > and slightly down (cascade-style 25 pixels right and 25 pixels down). > Unless the original project window was very wide or tall > this new project window should be the same size. > *Open a few more new projects. > They should continue cascading but when either edge (bottom > or right) reach the screen edge the behavior should change. > When a new project window's right edge would go off the > screen, that new window's width is reduced to keep it on screen. > One a new project window's bottom edge would go off the > screen, that new window's top edge is moved up so that it is level with the > previous project window (marching-style 25 pixels right and 0 pixels down). > Eventually, when you've created enough new project windows, > the resulting new window would be smaller than the minimum that Audacity > allows. At that point the next new project window will be created at the > user's stored preferred location but will maintain the height of the > previous project window. > *Close all but one of the project Windows. > *Move and resize that window so that it is obviously different from the > default window which opened initially. > *Close Audacity. > *Restart Audacity. > The resulting new project window should open in the same > size and location as it was when you just quit Audacity. > *Move and resize that window so that it is again obviously different from > the default window and from the condition in which it just opened. > *Maximize that project window. > *Close Audacity. > *Restart Audacity. > The resulting new project window should open maximized. > *Restore down that project window. > It should return to the size and location it was in when you > close audacity the last time. > *Try anything that you can think of to confuse Audacity about window > location! > > A word of warning, at some point Audacity blows up after creating a large > number of new projects. The number of new projects that a user may create > seems to be highly dependent upon the operating system (XP allows about 24, > Vista allows about 36, Mac and Linux allow about 80). If you get to this > condition you will need to use the operating system or the debugger to exit > the program. > > --Ed > > >> -----Original Message----- >> From: Leland [mailto:[hidden email]] >> Sent: Saturday, November 07, 2009 4:51 PM >> To: [hidden email] >> Subject: Re: [Audacity-devel] [re] final Disapearing Window patch >> >> Hi Ed, >> >> I'm working on a loop on the Mac and I was wondering if you could give me > a >> hint as to what the "for (int i...)" and "for (int j...)" loops in >> GetNextWindowPlacement() are doing? Except for the 3rd one, they all >> appear to do the same thing. (Be gentle if I missed something obvious.) >> >> The 3rd one (the "+-" case) is the one that's causing a loop on the Mac. >> Consider the following: >> >> targetLeft = 14; >> targetRight = 178; >> targetTop = -1; >> targetBottom = 13 >> >> These values cause the "+-" case and since j is decremented from "-1", it >> takes a VERY long time to get to targetBottom. >> >> Leland >> >> Ed Musgrove wrote: >>> Please find attached fixFinalDisapWindow.patch, it is an update to >>> the patch I sent this morning--use this one. >>> >>> One tiny behavior change was made--when cascading and marching >> windows >>> eventually automatically reduced in size to an unacceptable level, I >>> chose to use the user's most recently stored prefs values (if >>> available) instead of the defaultWindow value for the new window's size >> and location. >>> I also did a lot of housecleaning--I was calling the same function to >>> get unchanging data every pass through nested for-loops. I moved all >>> of them out of the loops. I also switched to "break" instead of >>> manually trying to set the loop counter out-of-bounds--much cleaner >>> and I had had problems with the calculations being off-by-one > yesterday). >>> --Ed >>> >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> ---------------------------------------------------------------------- >>> -------- Come build with us! The BlackBerry(R) Developer Conference in >>> SF, CA is the only developer event you need to attend this year. >>> Jumpstart your developing skills, take BlackBerry mobile applications >>> to market and stay ahead of the curve. Join us from November 9 - 12, >>> 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> _______________________________________________ >>> audacity-devel mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >> > ---------------------------------------------------------------------------- > -- >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day >> trial. Simplify your report design, integration and deployment - and focus > on >> what you do best, core application coding. Discover what's new with > Crystal >> Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> audacity-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> audacity-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Leland (Audacity Team)
|
In reply to this post
by Ed Musgrove-2
Ed Musgrove wrote:
> > A word of warning, at some point Audacity blows up after creating a large > number of new projects. The number of new projects that a user may create > seems to be highly dependent upon the operating system (XP allows about 24, > Vista allows about 36, Mac and Linux allow about 80). If you get to this > condition you will need to use the operating system or the debugger to exit > the program. > On Windows, I believe you're hitting the maximum GDI object limits for the process. See: http://msdn.microsoft.com/en-us/library/ms724291%28VS.85%29.aspx If you want to monitor the GDI handles while recreating the failure, use: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx On OSX (and probably Linux), I believe you're hitting the maximum address space for a 32-bit app. Just use Activity Monitor to watch the virtual memory size while creating new project windows. It should crash when it gets near 4GB. Leland ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Ed Musgrove-2
|
Thank you for this information that first link was especially helpful. I am
also following a discussion on the wxWidgets dev-list which could also be pertinent. It has been noted that wxWidgets does not throw an exception when malloc() fails. This was slated to be addressed shortly (3.x). I spent a couple of days stepping through the wxWidgets code via Audacity and could only determine that the problem happened while trying to create the buttons on one of the toolbars. It was almost always the same button but stepping into the code and single stepping suppressed the problem. I am not going to worry about it other than if we think we need to make a note about in the manual. --Ed > -----Original Message----- > From: Leland [mailto:[hidden email]] > Sent: Saturday, November 07, 2009 8:50 PM > To: [hidden email] > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > Ed Musgrove wrote: > > > > A word of warning, at some point Audacity blows up after creating a > > large number of new projects. The number of new projects that a user > > may create seems to be highly dependent upon the operating system (XP > > allows about 24, Vista allows about 36, Mac and Linux allow about 80). > > If you get to this condition you will need to use the operating system > > or the debugger to exit the program. > > > On Windows, I believe you're hitting the maximum GDI object limits for the > process. See: > > http://msdn.microsoft.com/en-us/library/ms724291%28VS.85%29.aspx > > If you want to monitor the GDI handles while recreating the failure, use: > > http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx > > On OSX (and probably Linux), I believe you're hitting the maximum address > space for a 32-bit app. Just use Activity Monitor to watch the virtual > size while creating new project windows. It should crash when it gets near > 4GB. > > Leland > > ---------------------------------------------------------------------------- -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with Crystal > Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Leland (Audacity Team)
|
Ed Musgrove wrote:
> Thank you for this information that first link was especially helpful. I am > also following a discussion on the wxWidgets dev-list which could also be > pertinent. It has been noted that wxWidgets does not throw an exception when > malloc() fails. This was slated to be addressed shortly (3.x). I spent a > couple of days stepping through the wxWidgets code via Audacity and could > only determine that the problem happened while trying to create the buttons > on one of the toolbars. It was almost always the same button but stepping > into the code and single stepping suppressed the problem. I am not going to > worry about it other than if we think we need to make a note about in the > manual. > have a large number of project windows open at once. Leland ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Ed Musgrove-2
|
I too doubt that it's a big deal. I do dislike an application which does not
fail gracefully. In this case, on all three platforms it requires the intervention of the platform's version of Task Manager to kill it. --Ed > -----Original Message----- > From: Leland [mailto:[hidden email]] > Sent: Saturday, November 07, 2009 9:43 PM > To: [hidden email] > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > Ed Musgrove wrote: > > Thank you for this information that first link was especially helpful. > > I am also following a discussion on the wxWidgets dev-list which could > > also be pertinent. It has been noted that wxWidgets does not throw an > > exception when > > malloc() fails. This was slated to be addressed shortly (3.x). I spent > > a couple of days stepping through the wxWidgets code via Audacity and > > could only determine that the problem happened while trying to create > > the buttons on one of the toolbars. It was almost always the same > > button but stepping into the code and single stepping suppressed the > > problem. I am not going to worry about it other than if we think we > > need to make a note about in the manual. > > > Actually, I don't think it's a big deal since most (if any) people would > large number of project windows open at once. > > Leland > > ---------------------------------------------------------------------------- -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with Crystal > Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Gale (Audacity Team)
|
| From "Ed Musgrove" <[hidden email]> | Sat, 7 Nov 2009 22:04:58 -0800 | Subject: [Audacity-devel] [re] final Disapearing Window patch > I too doubt that it's a big deal. I do dislike an application which does not > fail gracefully. In this case, on all three platforms it requires the > intervention of the platform's version of Task Manager to kill it. > > --Ed I'd agree this isn't worth documenting. Other programs would similarly fail wouldn't they, when they reached the OS restriction? Gale > > -----Original Message----- > > From: Leland [mailto:[hidden email]] > > Sent: Saturday, November 07, 2009 9:43 PM > > To: [hidden email] > > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > > > Ed Musgrove wrote: > > > Thank you for this information that first link was especially helpful. > > > I am also following a discussion on the wxWidgets dev-list which could > > > also be pertinent. It has been noted that wxWidgets does not throw an > > > exception when > > > malloc() fails. This was slated to be addressed shortly (3.x). I spent > > > a couple of days stepping through the wxWidgets code via Audacity and > > > could only determine that the problem happened while trying to create > > > the buttons on one of the toolbars. It was almost always the same > > > button but stepping into the code and single stepping suppressed the > > > problem. I am not going to worry about it other than if we think we > > > need to make a note about in the manual. > > > > > Actually, I don't think it's a big deal since most (if any) people would > have a > > large number of project windows open at once. > > > > Leland ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Ed Musgrove-2
|
Yikes!
--Ed > -----Original Message----- > From: Gale Andrews [mailto:[hidden email]] > Sent: Sunday, November 08, 2009 3:12 AM > To: [hidden email] > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > > | From "Ed Musgrove" <[hidden email]> Sat, 7 Nov 2009 > | 22:04:58 -0800 > | Subject: [Audacity-devel] [re] final Disapearing Window patch > > I too doubt that it's a big deal. I do dislike an application which > > does not fail gracefully. In this case, on all three platforms it > > requires the intervention of the platform's version of Task Manager to > it. > > > > --Ed > > I'd agree this isn't worth documenting. Other programs would similarly fail > wouldn't they, when they reached the OS restriction? > [ Ed-- ] I fired off Microsoft Word 2010 and pressed control n 34 times. My C: drive is now rebuilding itself (I am really glad I have RAID). I lost one database on my D: drive-- it was open at the time in MediaMonkey; MM will rebuild it from scratch but it takes almost 2 days; MM will still play music while doing so. So, Microsoft Word fails much less gracefully than Audacity! It clearly fails from the same lack of resource. At least Audacity is gracious enough to allow for the Task Manager to run and nuke it. > > Gale > > > > > -----Original Message----- > > > From: Leland [mailto:[hidden email]] > > > Sent: Saturday, November 07, 2009 9:43 PM > > > To: [hidden email] > > > Subject: Re: [Audacity-devel] [re] final Disapearing Window patch > > > > > > Ed Musgrove wrote: > > > > Thank you for this information that first link was especially > > > > I am also following a discussion on the wxWidgets dev-list which could > > > > also be pertinent. It has been noted that wxWidgets does not throw an > > > > exception when > > > > malloc() fails. This was slated to be addressed shortly (3.x). I spent > > > > a couple of days stepping through the wxWidgets code via Audacity and > > > > could only determine that the problem happened while trying to > create > > > > the buttons on one of the toolbars. It was almost always the same > > > > button but stepping into the code and single stepping suppressed the > > > > problem. I am not going to worry about it other than if we think we > > > > need to make a note about in the manual. > > > > > > > Actually, I don't think it's a big deal since most (if any) people would > > have a > > > large number of project windows open at once. > > > > > > Leland > > > > > ---------------------------------------------------------------------------- -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |