[re] final Disapearing Window patch

18 messages Options
Embed this post
Permalink
Ed Musgrove-2

[re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
 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

fixFinalDisapWindow.patch (25K) Download Attachment
Martyn Shaw-2

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
> -----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)

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
> -----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?
>
> 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)

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink

| 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

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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)

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink

| 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

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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
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


------------------------------------------------------------------------------
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)

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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

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

GNWP.patch (14K) Download Attachment
Leland (Audacity Team)

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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)

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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
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


------------------------------------------------------------------------------
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)

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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
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
Gale (Audacity Team)

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink

| 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

Re: [re] final Disapearing Window patch

Reply Threaded More More options
Print post
Permalink
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
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?
>
[   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
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


------------------------------------------------------------------------------
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