Hi Gale!
> -----Original Message-----
> From: Gale Andrews [mailto:
[hidden email]]
> | From "Ed Musgrove" <
[hidden email]> Sat, 17 Oct 2009
> | 20:36:01 -0700
> | Subject: I think you might like this new project behavior
>
> Thanks for the latest suggestion to fix large new project windows being
> hidden. Can we keep this on the list please, in case others have comments?
[Ed:]
Sorry for e-mailing you off the list, I did not want to expose the patch to
others until you commented upon it.
> I applied the patch below, tested on XP. Two things first:
>
> If I start with an initialised .cfg, launch Audacity, maximise it, exit
and re-
> launch it, then click "Restore Down", the project window moves up so that
> the Title bar is off screen. If I exit
> like that, .cfg has
>
> X=-4
> Y=-29
> Width=1028
> Height=712
> Maximized=0
[Ed:]
This has to do with the fact that Audacity has no way (as of yet) of
remembering a "normalized" state of a maximized window. I think I know how
to do this and will add that ability to the "final" patch for this problem.
I consider that a "feature" request more than a bug fix involved in this
specific bug.
> If I re-initialise .cfg, so it opens with a small normalised window at top
left, do
> File > New six times then exit using that last new window, Audacity
> relaunches with the x,y of the default window, not the one that was exited
> with. I think that's reasonable, but also think you had this on your list
of
> possible improvements, is that correct?
[Ed:]
Audacity has always stepped through the list of projects starting with the
oldest (in the above case the "default" window) when looking for an
appropriate project whose state (size and location) will be saved in
preferences.
If I change this, I would want to see a discussion to determine the design
criteria. Here are some possible cases:
*use the oldest non-iconized project-- if no project fits this use default
(current behavior-- has problems if the "accepted" project is maximized)
*use the oldest non-iconized project-- if no project fits, do not save
anything (current behavior "fixes" those configuration files where the X.
and Y. locations are -32,000 -- this would not solve that problem )
*use the oldest non-iconized project-- if no project fits, do not save
anything (but check for the X. and Y. locations equal to -32,000 -- if
found, use the default; this WOULD solve that problem )
*use the oldest non-itemized and non-maximized project (see the previous two
items -- same problems)
*use the newest... (as the above four items -- similar problems)
> In my test case with a large more or less square project
> window:
>
> X=0
> Y=0
> Width=689
> Height=662
> Maximized=0
>
> the first new project window opens offset down and to right; the second
and
> subsequent new ones are offset only to right at the same vertical position
> and window size. When the right edge of the screen is reached, then the
> subsequent new windows start decreasing in size. Could we be more exotic
> (such as offsetting alternate windows up and down when they cannot go
> lower)? Otherwise, IMO this now works quite well and is definitely
> acceptable (to me).
[Ed:]
We could be more exotic, but offsetting the windows up and down would
eventually cause windows to be hidden. I know you do not want to add more
preferences to help deal with this but without some input from the user as
to how this type of situation should be dealt with, any exotic method I
create would most likely only satisfy a small handful of users and confuse
most others. Personally, I prefer the method which I presented which
cascaded the new projects (down twenty-five and right twenty-five) then
resized the window as needed. I do understand your desire to keep the
windows as tall as possible in any given situation.
> I noticed when the windows cannot be decreased further in size at the
right
> edge, no new windows are added when you File > New, and the Selection
> Toolbar end/length buttons blackout. Audacity then becomes unresponsive
> to mouse unless you realise you can use CTRL + W to get out of the
problem.
> This does not happen until I have over 20 windows on my 1024 x 768 screen,
> but could be an issue on smaller screens. Can we do what we used to do
> when no more windows can be added at right, and start the next new
> window at the stored .cfg position? Or some other idea?
[Ed:]
NEW -- (I'm going to leave what I previously wrote below) testing again, I
too got to the point where Audacity was no longer responsive to the mouse--
this time it was after opening 36 projects. In fact, it only seemed like it
was unresponsive; regardless, the behavior is unacceptable. I believe we are
actually running into some other limiting factor system RAM, graphics RAM or
something (Windows has a small buffer which it uses to store information
about existing windows, shortcuts and the like -- this buffer is very tiny,
we might be over stressing it). In this test, when I opened project number
thirty I shrank its window down and drag it over near the top left so in
this case, I know for sure that was not a problem with overlapping windows
of the exact same dimensions and location.
I think the behavior that you are experiencing is not quite what you think.
I think those windows are being created but they are hidden behind existing
windows. Let me do a quick test... Yikes! After opening 37 new projects
Audacity forced Windows and my display hardware into overload. I am not sure
quite exactly what happened and I do not know if it was intentional on the
part of Vista and ATI (my graphic card is an ATI based SAPPHIRE HD3870); a
poorly implemented full screen display opens, it is completely blank
(although the Audacity project windows are there but drawn completely in
white on white) and the taskbar is invisible until I move the mouse down to
that region of the screen. I have full access to the taskbar and can close
individual Audacity projects or all projects.
When you say "Audacity then becomes unresponsive to mouse unless you
either..." my guess is that the hidden window has focus and is gobbling your
mouse events. Look down at your taskbar -- you should see a bunch of
Audacity entries (I don't think XP groups these entries but it might).
Opening the group if necessary, select one of the middle projects -- it's
window should pop to the front. Close that project to get it out of your
face then select the window to the extreme right-- does it open right on top
of a previously existing window?
If this is what is going on we could test for that (one window opening right
on top of another window) then move down twenty-five and start stepping
across the screen again (of course this would require making these new
Windows twenty-five pixels shorter).
> So apart from the "Restore Down" problem, I think we could have cracked
> this one now. Once restore down is fixed, I'll try the patch on Linux too.
[Ed:]
Changing the "restored down" behavior will require modifications to
AudacityApp, AudacityProject and the storage in the configuration file of a
wxRect. As such it will require serious debugging on all platforms.
I know this is a monstrously long thread and there is a lot of information
in this current post. Here is what I propose:
First, examine what happens as the new projects march toward the right and
eventually cause at best user confusion or possibly a bug.
Potential solution: use some method (once again I vote for a user preference
setting <grin>) to set a minimum width (and eventually minimum height) to
which a project window can be automatically resized
a) if automatically resizing would cause this minimum to be
dishonored, warn the user and ask the user what to do:
1) do not create the new project
2) ask the user for a new top left location
b) if automatic resizing would cause this minimum to be dishonored,
automatically:
1) do not create the new project
2) use some built-in default for the new projects top left
location
Second, make the "restore down" feature. While this is far afield from the
original bug I think it an important GUI improvement.
Third, consider some "exotic" techniques for cascading windows. See if you
can view this:
http://home.wavecable.com/~edgarmusgrove/exoticAudacity.jpgnote how the cascading of the Windows begins again (I forced this) and
eventually starts marching to the right. If you cannot view the picture let
me know and I will attach a picture to e-mail.
If you've gotten this far (I applied your perseverance), let me know if you
approve of the order in which I propose to attack this and share your
thoughts about the potential solution for the first case.
------------------------------------------------------------------------------
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
exoticAudacity.zip (144K) 
