Thread: [Audacity-devel] wxGetClientDisplayRect
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Ed M. <edg...@ya...> - 2009-09-27 06:38:20
|
Delving into the source code for wxRect wxGetClientDisplayRect() I learned some interesting things. Given that my concern was solely with width and height, that is where I focused my inspection. I found that to determine width and height 2 conditions for the Microsoft case exist; for other platforms things are a little confusing to me. In file wx2.8.10\src\common\gdicmn.cpp (line 848): wxRect wxGetClientDisplayRect() { int x, y, width, height; wxClientDisplayRect(&x, &y, &width, &height); // call plat-specific version return wxRect(x, y, width, height); } and in file wx2.8.10\src\msw\utilsgui.cpp (line 337; i.e. building for msw): void wxClientDisplayRect(int *x, int *y, int *width, int *height) { #if defined(__WXMICROWIN__) *x = 0; *y = 0; wxDisplaySize(width, height); #else // Determine the desktop dimensions minus the taskbar and any other // special decorations... RECT r; SystemParametersInfo(SPI_GETWORKAREA, 0, &r, 0); if (x) *x = r.left; if (y) *y = r.top; if (width) *width = r.right - r.left; if (height) *height = r.bottom - r.top; #endif } and in file wx2.8.10\src\unix\displayx11.cpp (line 327): #if defined(__WXGTK__) || defined(__X__) [... at line 348]: // NB: this function is implemented using X11 and not GDK calls as it's shared // by wxGTK[12], wxX11 and wxMotif ports void wxClientDisplayRect(int *x, int *y, int *width, int *height) { Display * const dpy = (Display *)wxGetDisplay(); wxCHECK_RET( dpy, _T("can't be called before initializing the GUI") ); const Atom atomWorkArea = XInternAtom(dpy, "_NET_WORKAREA", True); if ( atomWorkArea ) { [...] if ( XGetWindowProperty ( [...] ) == Success && workareas ) { wxX11Ptr x11ptr(workareas); // ensure it will be freed [...] if ( actualType != XA_CARDINAL || format != 32 || numItems != 4 ) { wxLogDebug(_T("XGetWindowProperty(\"_NET_WORKAREA\") failed")); return; } [...] } } // if we get here, _NET_WORKAREA is not supported so return the entire // screen size as fall back [...] wxDisplaySize(width, height); } #else // !(wxGTK or X) void wxClientDisplayRect(int *x, int *y, int *width, int *height) { [...] wxDisplaySize(width, height); } #endif // wxGTK or X in file wx2.8.10\src\msw\utilsgui.cpp (line 278 -- note that as far as I can tell, this is the only definition and declaration of this function even though it's called in file wx2.8.10\src\unix\displayx11.cpp): // Get size of display void wxDisplaySize(int *width, int *height) { #ifdef __WXMICROWIN__ [...] if ( width ) *width = rect.right - rect.left; if ( height ) *height = rect.bottom - rect.top; #else // !__WXMICROWIN__ [...] if ( width ) *width = ::GetDeviceCaps(dc, HORZRES); if ( height ) *height = ::GetDeviceCaps(dc, VERTRES); #endif // __WXMICROWIN__/!__WXMICROWIN__ --------------------------------------------------------- Note that in file: Audacity 1.3.9b\src\Project.cpp(527): // BG: The default size and position of the first window void GetDefaultWindowRect(wxRect *defRect) { [527] *defRect = wxGetClientDisplayRect(); defRect->width = 600; defRect->height = 400; [...] which assumes the platform is capable of supporting a specified resolution. Please also note that in file wx2.8.10\src\unix\displayx11.cpp (line 389): wxLogDebug(_T("XGetWindowProperty(\"_NET_WORKAREA\") failed")); return; the function returns without setting any values for x, y, width or height and might better return a bool that a void. I suppose that needs to be taken up with the wxWidgets developers. Still, Audacity does rely on the x and y values being correctly filled out. In fileAudacity 1.3.9b\src\Project.cpp(line 54 7): wxRect defWndRect; [...] GetDefaultWindowRect(&defWndRect); relies on the default constructor: wxRect() : x(0), y(0), width(0), height(0) { } which at least seeds the values with a non-random number (0). As a sanity check Audacity might check the value of either width or height to ensure that it is not 0. -Ed Musgrove |
From: John C. <jc...@gm...> - 2009-09-27 18:16:26
|
Ed Musgrove wrote: > Delving into the source code for wxRect wxGetClientDisplayRect() I > learned some interesting things. Given that my concern was solely with > width and height, that is where I focused my inspection. I found that > to determine width and height 2 conditions for the Microsoft case > exist; for other platforms things are a little confusing to me. > > Please forgive my intrusion. I have been "lurking" on this list for a while, but up until now have remained silent. I had previously looked at the "minimize" bug where a second Audacity window will come up "minimized" if the original one was also. My thoughts were the problem was most likely related to wxwidgets. Perhaps you have come to the heart of this matter. Or were you already working on this ? :) On http://wiki.audacityteam.org/index.php?title=Release_Notes_1.3.9#Known_Issues_at_Release the following "intermittent" bug is noted: (Windows) After a period launching correctly, Audacity may not come up on top at launch. Workaround: Right-click over Audacity's Taskbar icon > "Maximize" or "Restore", ALT - tab, or reset the audacity.cfg settings file by removing all content except "NewPrefsInitialized=1". I have more info on this problem if you are interested. - John |
From: Gale A. <ga...@au...> - 2009-09-27 20:50:59
|
Sorry for the length of this, but essential to address it. Please delete if you are not interested. See below otherwise. | From John Colket <jc...@gm...> | Sun, 27 Sep 2009 13:15:57 -0500 | Subject: [Audacity-devel] wxGetClientDisplayRect > Ed Musgrove wrote: > > Delving into the source code for wxRect wxGetClientDisplayRect() I > > learned some interesting things. Given that my concern was solely with > > width and height, that is where I focused my inspection. I found that > > to determine width and height 2 conditions for the Microsoft case > > exist; for other platforms things are a little confusing to me. > > > > > Please forgive my intrusion. I have been "lurking" on this list for a > while, but up until now have remained silent. > > I had previously looked at the "minimize" bug where a second Audacity > window will come up "minimized" if the original one was also. My > thoughts were the problem was most likely related to wxwidgets. > > Perhaps you have come to the heart of this matter. Or were you already > working on this ? :) > > On > http://wiki.audacityteam.org/index.php?title=Release_Notes_1.3.9#Known_Issues_at_Release > > the following "intermittent" bug is noted: > (Windows) After a period launching correctly, Audacity may not come up > on top at launch. Workaround: Right-click over Audacity's Taskbar icon > > "Maximize" or "Restore", ALT - tab, or reset the audacity.cfg settings > file by removing all content except "NewPrefsInitialized=1". > > I have more info on this problem if you are interested. John, I have not forgotten this, but as I have told you, your steps are not reproducible here, on a single monitor 1024x768 (but steps other than the ones you state are - see below). I'm not actually sure at the moment this is the same as the P3 on the Checklist, because most of those reports are of trying to launch a single project window, and there is no indication that these people ever open multiple windows. Opening a single project window apparently works for you too, until you go trying to open a new *project window* by launching a new *instance* of Audacity. As I explained to you, you cannot have two audacity.exe processes running at the same time. If you launched Audacity 1.2 and then double-clicked audacity.exe again, you would get an error. In 1.3, we try to be more friendly by opening a new project window instead. If you want to open a new project window, use File > New. If you are working with restored rather than maximised windows, minimise the previous window at that stage. You can always Task Switch (ALT + TAB) to bring either window on top. In your steps cited below from your previous e-mail, the problem arises for you in (H) where audacity.cfg acquires "X=-31975 Y=-31975". That does not happen for me. Here, audacity.cfg acquires X=25 Y = 25 for the off-top-left second window and the new window is always accessible. But if I exit Audacity maximised (which is how I use it) then: * re-launch it * generate a tone * minimise that window using (_) top right * double-click audacity.exe I *can* replicate the new window being hidden behind the old one having the tone. I can easily task switch to that old window or raise it by left-clicking the taskbar icon, but I cannot access the new one. If I raise the old window and File > Exit, I can re-launch Audacity maximised without any problem. Now, if I exit Audacity maximised then: * re-launch it (don't generate a tone) * minimise that window using (_) top right * double-click audacity.exe I get the new window hidden as before. If I task switch to the old one, File > Exit, then re-launch Audacity, I get the Welcome message with no window behind it, and then no Audacity real estate at all when I OK the Welcome message. The audacity.cfg file shows: X=-1 Y=-1 W=327 H=55 (no maximised status) Task Switching does not help. However, right-clicking the taskbar icon > Maximize brings Audacity on top. I can then File > Exit and Audacity will launch properly next time, maximised. FWIW when I repeated the only scenario where I can reproduce your issue as above, the .cfg then read X=-4 Y=-4 Width=1032 Height=712 Maximized=1 Clearly there is something we can address here with the .cfg getting garbled, now that (I hope) we can reproduce it. However if you open a new project window in the proper way, I don't think your issue will occur. Thanks for your persistence anyway, which nagged me into experimenting further. Gale > The consistency that I do see is that I start up the 2nd Audacity > instance/project via Windows WHILE THE FIRST PROJECT IS STILL MINIMIZED! > In the case of the 1.3.9 alpha, I do this by (a) minimizing the original > project (with the "_" button in the upper-right-hand corner of the > window), then (b) dbl-clicking on the audacity.exe file. It is just as > though audacity is deliberately bringing up the second project minimized. > > OK, here is what happens with the .cfg file. Initial contents: > > NewPrefsInitialized=1 > > - > > (A) Copy audacity.cfg to audacity.1.txt > > (B) In 1.3.9 directory, dbl-click on "audacity.exe". Click OK for > English. Click OK for intro screen. Alt-F,C to Close window. > > (C) Copy audacity.cfg to audacity.2.txt > > (D) In 1.3.9 directory, dbl-click on "audacity.exe". Click OK for intro > screen. In upper right-hand corner, click "_" to minimize. > > (E) In 1.3.9 directory, dbl-click on "audacity.exe". > > (F) The ONLY obvious change to the screen is the addition of a 2nd > Audacity icon to the Taskbar. LEFT-clicking on this new Taskbar icon > does nothing. > > (G) LEFT-click on original (1st) Audacity Taskbar icon. The Audacity > screen appears. Alt-F,X to Exit Audacity. > > (H) Copy audacity.cfg to audacity.3.txt > > (I) In 1.3.9 directory, dbl-click on "audacity.exe". Click OK for intro > screen. Audacity main window is hidden. LEFT-click on Audacity icon in > Taskbar. Nothing happens. > > I have attached the .audacity cfg txt files I mentioned. > > It MAY be possible to clear the problem by taking the following steps. > These steps could be easier than having to reset the .cfg file. > > (J) RIGHT-Click the Audacity Taskbar icon, Maximize. Alt-F,X to close > WHILE MAXIMIZED. > > (K) In 1.3.9 directory, dbl-click on "audacity.exe". Click OK for intro > screen. > > (L) In the upper right-hand corner of the window, click on the Restore > Down box between the "_" and the "X". This seems to fix the problem. > . > > - John > |
From: Gale A. <ga...@au...> - 2009-10-01 09:30:20
|
Hi Ed Many thanks for your patience and thoroughness with this. I haven't tested every possible permutation of scenarios on Windows XP, but after your patch I cannot now reproduce my scenario that reliably led to the problem, and John's creates no issue here. I notice that when I now (A) launch Audacity with default x,y position (restored window), minimise it then relaunch the executable, the new window comes on top but the old one stays minimised. That isn't the behaviour I got before when following those steps; what happened then was that both windows came up on relaunching the executable, with the old one behind at top left and the new one offset and on top. So I guess that's better too, because it respects the iconisation of the old window. I note however that if (B) I have one window restored, don't minimise it but just task switch to the 1.3.10 directory and re-launch, the old window is also minimised, not respecting the state of the old window. This is also different behaviour from (C) clicking File > New in a restored window, where the old is visible without focus behind the new. So although it's a small point I guess we may as well discuss it: In case (C), is it best behaviour as now to leave the old window restored, or minimise it, as John seems to want to do? I think leave as is, as this seems more normal behaviour? If so, is there any case for (B) behaving as (C)? Reading your discussion, your changes may hopefully have fixed the other scenarios we don't know about where users launch Audacity but it is minimised "P3 (Windows only) After a period launching correctly, Audacity opens minimised." John, can you test out Ed's work please if you have a moment: http://www.gaclrecords.org.uk/audacity-win-unicode-1.3.10-alpha.zip Thanks Gale | From Gale Andrews <ga...@au...> | Sun, 27 Sep 2009 21:50:31 +0100 | Subject: Problem with hidden second project window on Windows WAS: Re: [Audacity-devel] wxGetClientDisplayRect > > Sorry for the length of this, but essential to address it. Please > delete if you are not interested. See below otherwise. > > | From John Colket <jc...@gm...> > | Sun, 27 Sep 2009 13:15:57 -0500 > | Subject: [Audacity-devel] wxGetClientDisplayRect > > Ed Musgrove wrote: > > > Delving into the source code for wxRect wxGetClientDisplayRect() I > > > learned some interesting things. Given that my concern was solely with > > > width and height, that is where I focused my inspection. I found that > > > to determine width and height 2 conditions for the Microsoft case > > > exist; for other platforms things are a little confusing to me. > > > > > > > > Please forgive my intrusion. I have been "lurking" on this list for a > > while, but up until now have remained silent. > > > > I had previously looked at the "minimize" bug where a second Audacity > > window will come up "minimized" if the original one was also. My > > thoughts were the problem was most likely related to wxwidgets. > > > > Perhaps you have come to the heart of this matter. Or were you already > > working on this ? :) > > > > On > > http://wiki.audacityteam.org/index.php?title=Release_Notes_1.3.9#Known_Issues_at_Release > > > > the following "intermittent" bug is noted: > > (Windows) After a period launching correctly, Audacity may not come up > > on top at launch. Workaround: Right-click over Audacity's Taskbar icon > > > "Maximize" or "Restore", ALT - tab, or reset the audacity.cfg settings > > file by removing all content except "NewPrefsInitialized=1". > > > > I have more info on this problem if you are interested. > > John, > > I have not forgotten this, but as I have told you, your steps are not > reproducible here, on a single monitor 1024x768 (but steps other > than the ones you state are - see below). > > I'm not actually sure at the moment this is the same as the P3 on the > Checklist, because most of those reports are of trying to launch a > single project window, and there is no indication that these people > ever open multiple windows. Opening a single project window > apparently works for you too, until you go trying to open a new > *project window* by launching a new *instance* of Audacity. > > As I explained to you, you cannot have two audacity.exe processes > running at the same time. If you launched Audacity 1.2 and then > double-clicked audacity.exe again, you would get an error. In 1.3, > we try to be more friendly by opening a new project window instead. > > If you want to open a new project window, use File > New. If you > are working with restored rather than maximised windows, minimise > the previous window at that stage. You can always Task Switch > (ALT + TAB) to bring either window on top. > > In your steps cited below from your previous e-mail, the problem > arises for you in (H) where audacity.cfg acquires "X=-31975 > Y=-31975". That does not happen for me. Here, audacity.cfg acquires > X=25 Y = 25 for the off-top-left second window and the new window > is always accessible. > > But if I exit Audacity maximised (which is how I use it) then: > > * re-launch it > * generate a tone > * minimise that window using (_) top right > * double-click audacity.exe > > I *can* replicate the new window being hidden behind the old one having > the tone. I can easily task switch to that old window or raise it by > left-clicking the taskbar icon, but I cannot access the new one. If I > raise the old window and File > Exit, I can re-launch Audacity maximised > without any problem. > > Now, if I exit Audacity maximised then: > > * re-launch it (don't generate a tone) > * minimise that window using (_) top right > * double-click audacity.exe > > I get the new window hidden as before. If I task switch to the old one, > File > Exit, then re-launch Audacity, I get the Welcome message with > no window behind it, and then no Audacity real estate at all when I OK > the Welcome message. The audacity.cfg file shows: > > X=-1 > Y=-1 > W=327 > H=55 > (no maximised status) > > Task Switching does not help. However, right-clicking the taskbar > icon > Maximize brings Audacity on top. I can then File > Exit and > Audacity will launch properly next time, maximised. > > FWIW when I repeated the only scenario where I can reproduce your > issue as above, the .cfg then read > > X=-4 > Y=-4 > Width=1032 > Height=712 > Maximized=1 > > Clearly there is something we can address here with the .cfg getting > garbled, now that (I hope) we can reproduce it. However if you open > a new project window in the proper way, I don't think your issue will > occur. Thanks for your persistence anyway, which nagged me into > experimenting further. > > > > > Gale > > > > > > The consistency that I do see is that I start up the 2nd Audacity > > instance/project via Windows WHILE THE FIRST PROJECT IS STILL MINIMIZED! > > In the case of the 1.3.9 alpha, I do this by (a) minimizing the original > > project (with the "_" button in the upper-right-hand corner of the > > window), then (b) dbl-clicking on the audacity.exe file. It is just as > > though audacity is deliberately bringing up the second project minimized. > > > > OK, here is what happens with the .cfg file. Initial contents: > > > > NewPrefsInitialized=1 > > > > - > > > > (A) Copy audacity.cfg to audacity.1.txt > > > > (B) In 1.3.9 directory, dbl-click on "audacity.exe". Click OK for > > English. Click OK for intro screen. Alt-F,C to Close window. > > > > (C) Copy audacity.cfg to audacity.2.txt > > > > (D) In 1.3.9 directory, dbl-click on "audacity.exe". Click OK for intro > > screen. In upper right-hand corner, click "_" to minimize. > > > > (E) In 1.3.9 directory, dbl-click on "audacity.exe". > > > > (F) The ONLY obvious change to the screen is the addition of a 2nd > > Audacity icon to the Taskbar. LEFT-clicking on this new Taskbar icon > > does nothing. > > > > (G) LEFT-click on original (1st) Audacity Taskbar icon. The Audacity > > screen appears. Alt-F,X to Exit Audacity. > > > > (H) Copy audacity.cfg to audacity.3.txt > > > > (I) In 1.3.9 directory, dbl-click on "audacity.exe". Click OK for intro > > screen. Audacity main window is hidden. LEFT-click on Audacity icon in > > Taskbar. Nothing happens. > > > > I have attached the .audacity cfg txt files I mentioned. > > > > It MAY be possible to clear the problem by taking the following steps. > > These steps could be easier than having to reset the .cfg file. > > > > (J) RIGHT-Click the Audacity Taskbar icon, Maximize. Alt-F,X to close > > WHILE MAXIMIZED. > > > > (K) In 1.3.9 directory, dbl-click on "audacity.exe". Click OK for intro > > screen. > > > > (L) In the upper right-hand corner of the window, click on the Restore > > Down box between the "_" and the "X". This seems to fix the problem. > > . > > > > - John > > |
From: Ed M. <edg...@ya...> - 2009-10-01 17:00:51
|
Hi Gale! In regard to your situation (A), the code could be modified I suppose to operate the other way but I do not think that is good GUI implementation. As you point out the current way respects the users choice to have that window iconized. As for situation (B), here on Vista 64-bit I did not seem to get the behavior you do. The discrepancy may well involve a semantic difference. My working definition of "restored" and "minimized" may not coincide with yours! I did try as many variations as I could possibly figure out just now. One thing I recall from previous posts of yours is that you always start Audacity in an "maximize" window. I tested in this configuration but still did not achieve the behavior you note. (I did find another trivial issue that I would like to deal with -- if you start with a maximized window, "restore down" then size the window so that it only covers a small portion of the screen, then maximize the window, then exit Audacity; then restart Audacity -- it will open maximized -- then "restore down" the window will now be the default size. It would be cool to store the "restored down" size and location in the configuration file; but I digress!) These are my working definitions for the buttons and conditions involving window sizing based on Microsoft Windows operating systems: the button which looks like an _ (underscore) is the "iconize" button -- it has only one state the button in the middle has 2 states -- when it looks like a single rectangle it is the "maximize" button; when it looks like 2 smaller rectangles superimpose it is the "restore down" button when a window is "maximized" it occupies the entire screen with the exception of the taskbar -- it can not be resized nor dragged a window can be "minimized" only from the "maximize" condition -- it has been "restored down" -- it can be resized and dragged when a window is "iconized" the only visual representation of that window is on the taskbar; the typical user interface is via the mouse -- either a left click to "restore up" space or a right-click to activate the context menu (obviously, pressing <ALT> + <TAB> and cycling to the app is the same as a left mouse click). So, given my definitions, your " I have one window restored, don't minimise it but just task switch" I can't quite pin down the state of the originally open window. I think the confusion comes from the term "minimize" -- it could mean make smaller after having been "maximized" or it could mean "iconize". Still, I just now tested every permutation I could imagine, I could not get your "the old window is also minimised, not respecting the state of the old window". Again, we may be having problem with the term "minimized". At your discretion and convenience please try to give me more explicit instructions for re-creating your situation (B). Please pardon the length of this post, beta testing and bug hunting are tedious, require meticulous attention to detail and require that both parties speak the same vernacular! As for situation (C), best GUI implementation IMHO is to leave it as is -- I cannot speak for John but I expect him to chime in here! I have no way to determine if this solves the bug "P3 (Windows only) After a period launching correctly, Audacity opens minimised." As I have not figured out how to gain access to the actual user reports. Do we have any way of contacting those specific users? If so, I would be happy to join in a dialogue with them off the developer's mailing list to get the new code installed and tested by those users who most likely would experience the problem. Since changing the code, I have exercised Audacity (with many different configurations of open project windows) at least 200 times without experiencing this problem. Thank you very much for allowing me this opportunity to contribute! -Ed Musgrove ----- Original Message ---- From: Gale Andrews ga...@au... I notice that when I now (A) launch Audacity with default x,y position (restored window), minimise it then relaunch the executable, the new window comes on top but the old one stays minimised. That isn't the behaviour I got before when following those steps; what happened then was that both windows came up on relaunching the executable, with the old one behind at top left and the new one offset and on top. So I guess that's better too, because it respects the iconisation of the old window. I note however that if (B) I have one window restored, don't minimise it but just task switch to the 1.3.10 directory and re-launch, the old window is also minimised, not respecting the state of the old window. This is also different behaviour from (C) clicking File > New in a restored window, where the old is visible without focus behind the new. So although it's a small point I guess we may as well discuss it: In case (C), is it best behaviour as now to leave the old window restored, or minimise it, as John seems to want to do? I think leave as is, as this seems more normal behaviour? If so, is there any case for (B) behaving as (C)? Reading your discussion, your changes may hopefully have fixed the other scenarios we don't know about where users launch Audacity but it is minimised "P3 (Windows only) After a period launching correctly, Audacity opens minimised." |
From: Gale A. <ga...@au...> - 2009-10-02 08:40:51
|
| From Ed Musgrove <edg...@ya...> | Thu, 1 Oct 2009 10:00:18 -0700 (PDT) | Subject: [Audacity-devel] Problem with hidden second project window on Windows WAS: Re: wxGetClientDisplayRect > As for situation (B), here on Vista 64-bit I did not seem to get the > behavior you do. The discrepancy may well involve a semantic difference. > My working definition of "restored" and "minimized" may not coincide > with yours! ... To me, "restored" means any window that is neither maximised nor minimised ("iconised" as seems the more geekish term). "Restored" however implies nothing to me about any previous state of the window. Is there a better term? My (B) scenario (reproduces 100% for me): 1. Exit Audacity and initialise .cfg 2. Launch Audacity, choose language, OK welcome, exit 3. Launch Audacity, OK welcome, Task switch to Explorer, relaunch Audacity 4. I now have the window I just created by relaunching Audacity, offset from top left. The first is minimised (accessible by the taskbar icon or Task Switcher), but I did not actually ask to minimise it. I think it might be less confusing if it behaved just as File > New does, leaving the first window visible top left but without focus. > (I did find another trivial issue that I would like to deal with -- if > you start with a maximized window, "restore down" then size the window > so that it only covers a small portion of the screen, then maximize the > window, then exit Audacity; then restart Audacity -- it will open > maximized -- then "restore down" the window will now be the default size. > It would be cool to store the "restored down" size and location in the > configuration file; but I digress!) You mean so it stores the last "restored down" setting where Audacity was reduced to a small portion of the screen? Would be very clever, but complex? It would have to cope with the possibility of a number of different "restored" settings in a session, plus the possibility that the last time a "restored" setting was used may be several sessions ago. > As for situation (C), best GUI implementation IMHO is to leave it > as is -- I cannot speak for John but I expect him to chime in here! I agree, better "as is", and (B) should I think do the same. John seems to agree, the only issue being why is (B) behaving differently for me instead of doing the same as (C) ? > I have no way to determine if this solves the bug "P3 (Windows only) > After a period launching correctly, Audacity opens minimised." As I have > not figured out how to gain access to the actual user reports. Do we > have any way of contacting those specific users? If so, I would be happy > to join in a dialogue with them off the developer's mailing list to get > the new code installed and tested by those users who most likely would > experience the problem. Since changing the code, I have exercised > Audacity (with many different configurations of open project windows) at > least 200 times without experiencing this problem. I admire your patience :=). I could contact a sample of the complainants who wrote to feedback@ about it, and that might actually be a very good way of testing the new code. I have no information at all about the previous exiting (or other) scenarios by which the users launched Audacity and found it iconised. However none of them mentioned the issue of opening multiple project windows, only John raised that. > [John:] Now I have a new case in 1.3.10, which I will call case (M), which > doesn't seem quite exactly right, but is perfectly acceptable as is. > This case is identical to case (B), with the exception that the original > window was Maximized. In this case the second window comes up maximized > as one would expect, but if I then click on the box to "Restore" it, it > comes up in the upper-left hand corner of the screen. This would be OK > except, unfortunately, in my case, I run my task bar on the left edge of > the screen, so the left 1/2" of the new Audacity window is hidden by the > task bar. As I said before, this is a situation I can deal with. The > behavior under 1.3.9 puts the two windows exactly on top of each other > and does not have this issue. If your window had previously been "restored down" to upper left in that session, that really would be correct behaviour, I think. If I understand him correctly , Ed would like to save that last restored down position so it persists across sessions. The issue you raise with the Audacity window not sticking to the taskbar if it is on the left edge of the screen is one of my "locally stored P4 issues" (i.e. I know about it). From a cursory test some time ago, that left edge is the only edge where this issue occurs. > [John] The only other case I would bring up is the desirability of arming > Audacity to defend against a corrupted .cfg file. This could happen if, > as you say, (1) there are "other scenarios we don't know about", (2) > there is other prior .cfg damage from perhaps running a beta, or (3) > the possible case where the Audacity window is left on a second monitor > screen which is subsequently removed. Since each of these cases are > hopefully one-time events, they could be manually dealt with; besides > one might question making additional changes this close to the 2.0 > release. Another advantage of postponing this effort is that the longer > we wait, the less of an issue it becomes (assuming it was one to begin > with). (I cling to the belief that there might be an Audacity user out > there with a damaged file, who has given up on Audacity, but nonetheless > later installs 2.0 only to find out that this install apparently fails > as well). (3) has already been specifically dealt with for the metadata editor window: http://sourceforge.net/mailarchive/forum.php?thread_name=E1M9wiU-0001tN-Km%4023jxhf1.ch3.sourceforge.com&forum_name=audacity-cvs Apart from (1) and (2) there is no doubt the .cfg can and does get "garbled" in other ways than window placement. I've very strong suspicions that the P3 "AIFF files created by Audacity from recorded or generated data import intermittently (but at times very frequently) as noise - files play fine in other software" is tied up with .cfg problems. Initialising .cfg almost always cures this problem (even if the user had default settings in the first place). Plus I've seen occasional reports of the same issue with most of the other formats too. While we should address these issues if we can figure them out, I do think we need an easier way for user to initialise preferences than editing .cfg themselves with a text editor. I'd suggest one way might be a checkbox like we have for rescan of VST effects (as default would be "off", it would automatically be unchecked when restarting after initialisation). Gale > ----- Original Message ---- > From: Gale Andrews ga...@au... > > I notice that when I now (A) launch Audacity with default > x,y position (restored window), minimise it then relaunch > the executable, the new window comes on top but the old > one stays minimised. That isn't the behaviour I got before > when following those steps; what happened then was that > both windows came up on relaunching the executable, > with the old one behind at top left and the new one offset > and on top. So I guess that's better too, because it respects > the iconisation of the old window. > > I note however that if (B) I have one window restored, > don't minimise it but just task switch to the 1.3.10 > directory and re-launch, the old window is also minimised, > not respecting the state of the old window. This is also > different behaviour from (C) clicking File > New in a > restored window, where the old is visible without focus > behind the new. > > So although it's a small point I guess we may as well > discuss it: > > In case (C), is it best behaviour as now to leave the old > window restored, or minimise it, as John seems to > want to do? I think leave as is, as this seems more > normal behaviour? If so, is there any case for (B) > behaving as (C)? |
From: Ed M. <edg...@ya...> - 2009-10-02 18:36:09
|
Hi Gale! I have had the pleasure <GRIN> I'm doing telephone software support for many years. On numerous occasions I have had clients to use the term "restored" to mean different things (for the sake of brevity I will use the term "small window" to mean any window that does not cover the entire screen IE is not maximized): window is maximized, iconized then "restored" -- now maximize small window is iconized them "restored" -- now is a small window small window is maximized then "restored" -- now it is a small window again [you get the picture -- there are many permutations] When you say "initialize .cfg", how do you do that now? For my tests I will rename my configuration file audacity.cfg.OLD so that Audacity builds a new configuration file upon launch. I will test this in reply to you in a separate e-mail. I will also give some thought to an interface. I am not sure your checkbox idea is the best solution as it would appear the process would only activate (after exiting Audacity) the next time Audacity is run. I also see 2 potential cases: restore the Audacity configuration file to all defaults repair the Audacity configuration file saving all sensible settings As for your comment about saving the last "restored down" needing to be clever, you're right! I had not given it that much thought -- let me consider the permutations and make a matrix of potential situation. Please do consider contacting complainants who wrote to feedback@; feel free to give them my @dress (edg...@ya...). Please consider including the following information in your contact e-mail: developers have only been able to re-create this situation when Audacity's configuration file was <garbled/hosed/damage/messed up> it seemed to be related to closing Audacity while having multiple project windows open with one of them being minimized (iconized to the taskbar) or closing Audacity while having one or more project windows on a 2nd monitor Please mention that the case involving iconized project windows has been addressed in the most recent beta release and ask that they download that release (insert a URL) and try to make the problem happen. In the case of a 2nd monitor (I use 2 monitors) again, I will do some tests and reply on a separate e-mail. -Ed Musgrove ----- Original Message ---- From: Gale Andrews ga...@au... To me, "restored" means any window that is neither maximised nor minimised ("iconised" as seems the more geekish term). "Restored" however implies nothing to me about any previous state of the window. Is there a better term? My (B) scenario (reproduces 100% for me): > [Ed] (I did find another trivial issue ... > It would be cool to store the "restored down" size and location in the > configuration file You mean so it stores the last "restored down" setting where Audacity was reduced to a small portion of the screen? Would be very clever, but complex? I could contact a sample of the complainants > [John] The only other case I would bring up is the desirability of arming > Audacity to defend against a corrupted .cfg file. This could happen if, > as you say, (1) there are "other scenarios we don't know about", (2) > there is other prior .cfg damage from perhaps running a beta, or (3) > the possible case where the Audacity window is left on a second monitor > screen which is subsequently removed.... (3) has already been specifically dealt with for the metadata editor window: http://sourceforge.net/mailarchive/forum.php?thread_name=E1M9wiU-0001tN-Km%4023jxhf1.ch3.sourceforge.com&forum_name=audacity-cvs While we should address these issues if we can figure them out, I do think we need an easier way for user to initialise preferences than editing .cfg themselves with a text editor. I'd suggest one way might be a checkbox like we have for rescan of VST effects (as default would be "off", it would automatically be unchecked when restarting after initialisation). |
From: John C. <jc...@gm...> - 2009-10-03 01:39:15
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Gale Andrews wrote: <blockquote cite="mid:200...@au..." type="cite"> <pre wrap="">| From Ed Musgrove <a class="moz-txt-link-rfc2396E" href="mailto:edg...@ya..."><edg...@ya...></a> | Thu, 1 Oct 2009 10:00:18 -0700 (PDT) | Subject: [Audacity-devel] Problem with hidden second project window on Windows WAS: Re: wxGetClientDisplayRect </pre> <blockquote type="cite"> <pre wrap="">As for situation (B), here on Vista 64-bit I did not seem to get the behavior you do. The discrepancy may well involve a semantic difference. My working definition of "restored" and "minimized" may not coincide with yours! ... </pre> </blockquote> <pre wrap=""><!----> To me, "restored" means any window that is neither maximised nor minimised ("iconised" as seems the more geekish term). "Restored" however implies nothing to me about any previous state of the window. Is there a better term? My (B) scenario (reproduces 100% for me): 1. Exit Audacity and initialise .cfg 2. Launch Audacity, choose language, OK welcome, exit 3. Launch Audacity, OK welcome, Task switch to Explorer, relaunch Audacity 4. I now have the window I just created by relaunching Audacity, offset from top left. The first is minimised (accessible by the taskbar icon or Task Switcher), but I did not actually ask to minimise it. I think it might be less confusing if it behaved just as File > New does, leaving the first window visible top left but without focus. </pre> <blockquote type="cite"> <pre wrap="">(I did find another trivial issue that I would like to deal with -- if you start with a maximized window, "restore down" then size the window so that it only covers a small portion of the screen, then maximize the window, then exit Audacity; then restart Audacity -- it will open maximized -- then "restore down" the window will now be the default size. It would be cool to store the "restored down" size and location in the configuration file; but I digress!) </pre> </blockquote> <pre wrap=""><!----> You mean so it stores the last "restored down" setting where Audacity was reduced to a small portion of the screen? Would be very clever, but complex? It would have to cope with the possibility of a number of different "restored" settings in a session, plus the possibility that the last time a "restored" setting was used may be several sessions ago. </pre> <blockquote type="cite"> <pre wrap=""> As for situation (C), best GUI implementation IMHO is to leave it as is -- I cannot speak for John but I expect him to chime in here! </pre> </blockquote> <pre wrap=""><!----> I agree, better "as is", and (B) should I think do the same. John seems to agree, the only issue being why is (B) behaving differently for me instead of doing the same as (C) ? </pre> </blockquote> Ed, Gale, as I stated ealier, "In case (C) with 1.3.10, the results are identical to my case (B), which I would think is a good thing." <br> <blockquote cite="mid:200...@au..." type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">I have no way to determine if this solves the bug "P3 (Windows only) After a period launching correctly, Audacity opens minimised." As I have not figured out how to gain access to the actual user reports. Do we have any way of contacting those specific users? If so, I would be happy to join in a dialogue with them off the developer's mailing list to get the new code installed and tested by those users who most likely would experience the problem. Since changing the code, I have exercised Audacity (with many different configurations of open project windows) at least 200 times without experiencing this problem. </pre> </blockquote> <pre wrap=""><!----> I admire your patience :=). I could contact a sample of the complainants who wrote to feedback@ about it, and that might actually be a very good way of testing the new code. I have no information at all about the previous exiting (or other) scenarios by which the users launched Audacity and found it iconised. However none of them mentioned the issue of opening multiple project windows, only John raised that. </pre> <blockquote type="cite"> <pre wrap="">[John:] Now I have a new case in 1.3.10, which I will call case (M), which doesn't seem quite exactly right, but is perfectly acceptable as is. This case is identical to case (B), with the exception that the original window was Maximized. In this case the second window comes up maximized as one would expect, but if I then click on the box to "Restore" it, it comes up in the upper-left hand corner of the screen. This would be OK except, unfortunately, in my case, I run my task bar on the left edge of the screen, so the left 1/2" of the new Audacity window is hidden by the task bar. As I said before, this is a situation I can deal with. The behavior under 1.3.9 puts the two windows exactly on top of each other and does not have this issue. </pre> </blockquote> <pre wrap=""><!----> If your window had previously been "restored down" to upper left in that session, that really would be correct behaviour, I think. If I understand him correctly , Ed would like to save that last restored down position so it persists across sessions. The issue you raise with the Audacity window not sticking to the taskbar if it is on the left edge of the screen is one of my "locally stored P4 issues" (i.e. I know about it). From a cursory test some time ago, that left edge is the only edge where this issue occurs. </pre> </blockquote> Case (M) is not an issue for me (other than being "pretty", see below).<br> <blockquote cite="mid:200...@au..." type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">[John] The only other case I would bring up is the desirability of arming Audacity to defend against a corrupted .cfg file. This could happen if, as you say, (1) there are "other scenarios we don't know about", (2) there is other prior .cfg damage from perhaps running a beta, or (3) the possible case where the Audacity window is left on a second monitor screen which is subsequently removed. Since each of these cases are hopefully one-time events, they could be manually dealt with; besides one might question making additional changes this close to the 2.0 release. Another advantage of postponing this effort is that the longer we wait, the less of an issue it becomes (assuming it was one to begin with). (I cling to the belief that there might be an Audacity user out there with a damaged file, who has given up on Audacity, but nonetheless later installs 2.0 only to find out that this install apparently fails as well). </pre> </blockquote> <pre wrap=""><!----> (3) has already been specifically dealt with for the metadata editor window: <a class="moz-txt-link-freetext" href="http://sourceforge.net/mailarchive/forum.php?thread_name=E1M9wiU-0001tN-Km%4023jxhf1.ch3.sourceforge.com&forum_name=audacity-cvs">http://sourceforge.net/mailarchive/forum.php?thread_name=E1M9wiU-0001tN-Km%4023jxhf1.ch3.sourceforge.com&forum_name=audacity-cvs</a> </pre> </blockquote> This is very curious indeed. I wonder why the fix for this didn't correct the problem I was having originally. If it had, that might have been the end of this whole mess.<br> <blockquote cite="mid:200...@au..." type="cite"> <pre wrap="">Apart from (1) and (2) there is no doubt the .cfg can and does get "garbled" in other ways than window placement. I've very strong suspicions that the P3 "AIFF files created by Audacity from recorded or generated data import intermittently (but at times very frequently) as noise - files play fine in other software" is tied up with .cfg problems. Initialising .cfg almost always cures this problem (even if the user had default settings in the first place). Plus I've seen occasional reports of the same issue with most of the other formats too. While we should address these issues if we can figure them out, I do think we need an easier way for user to initialise preferences than editing .cfg themselves with a text editor. I'd suggest one way might be a checkbox like we have for rescan of VST effects (as default would be "off", it would automatically be unchecked when restarting after initialisation). </pre> </blockquote> To me, there are three issues here.<br> <br> (1) The "pretty", including exactly where a windows comes up on the screen, and whether or not it is partially obscured. This issue has been addressed somewhat by Ed. While it is nice to get everything looking pretty and polished, it might also be nice to rewrite major sections of Audacity.<br> <br> (2) The "irritant", that a second project window comes up hidden, which may lead to .cfg file corruption, and which Ed has corrected.<br> <br> (3) The "catastrophe", that once the .cfg file gets corrupted, no simple, "Normal" recovery procedure can be used to <i>ever</i> get the program running again. These simple recovery procedures would include a reboot, a re-install, and installing a new release. (Of course, I now include "Maximize" in my toolkit). Although I imagine an uninstall could purge all of the .cfg file, but I do not know if it does this.<br> <br> To correct the catastrophe, I was thinking that all Audacity would have to do is during initialization, at the time it is reading the .cfg file and is loading up it's X,Y coordinates, that it could check this one time that the coordinates are reasonable for the current screen, and if not, to revert to the defaults.<br> <br> While I personally favor the former, a system to re-initialize the .cfg file, as you suggest, would undoubtly provide a better return for the effort. In terms of re-initializing the .cfg file, there are three other ideas listed here:<br> <a class="moz-txt-link-freetext" href="http://forum.audacityteam.org/viewtopic.php?f=20&t=13361">http://forum.audacityteam.org/viewtopic.php?f=20&t=13361</a><br> <br> - John<br> <br> <br> <br> <br> <br> </body> </html> |
From: Gale A. <ga...@au...> - 2009-10-03 03:59:17
|
| From John Colket <jc...@gm...> | Fri, 02 Oct 2009 20:32:19 -0500 | Subject: [Audacity-devel] Problem with hidden second project window on Windows WAS: Re: wxGetClientDisplayRect > ... I imagine an uninstall could purge all of the .cfg file, but I do > not know if it does this. Uninstallation of 1.3.x leaves the .cfg file completely "as is". Similarly, uninstalling 1.2.x leaves the settings (on Windows, the Audacity HKCU registry key) untouched. > ... The "catastrophe", that once the .cfg file gets corrupted, no simple, > "Normal" recovery procedure can be used to ever get the program > running again... To correct the catastrophe, I was thinking that all > Audacity would have to do is during initialization, at the time it is > reading the .cfg file and is loading up it's X,Y coordinates, that it > could check this one time that the coordinates are reasonable for > the current screen, and if not, to revert to the defaults. Is that necessary? The defaults in the .cfg: X=0 Y=0 Width=600 Height=440 Maximized=0 should be able to work in all cases. Will those defaults fail if the machine only has the second monitor working? > While I personally favor the former, a system to re-initialize the > .cfg file, as you suggest, would undoubtly provide a better return for > the effort. In terms of re-initializing the .cfg file, there are three > other ideas listed here: > http://forum.audacityteam.org/viewtopic.php?f=20&t=13361 To which I've now added my own ideas for an executable in the installation folder to initialise .cfg (to cover all cases where Audacity can't be accessed, not just a "minimised" launch). For example, switching to a sound device or driver set that Audacity can't work with will typically give an error on launch, with the only option being to quit. Note that adding an incompatible plug-in could also cause Audacity to fail to launch properly, which a .cfg reset won't help. The chances of that should now be much reduced however with our VST GUI support and VST scanning routine. Gale |
From: Ed M. <edg...@ya...> - 2009-10-03 04:50:25
|
I think (from my tests) that currently the default first restores from the registry if possible (it does on my system). My graphics card (ATI) will not allow the primary monitor to be disabled so nuking .cfg will restore visual project windows. What Gale added at viewtopic.php?f=20&t=13361 seems to cover the bases until we try to implement this. -Ed Musgrove ----- Original Message ---- From: Gale Andrews ga...@au... Is that necessary? The defaults in the .cfg: X=0 Y=0 Width=600 Height=440 Maximized=0 should be able to work in all cases. Will those defaults fail if the machine only has the second monitor working? http://forum.audacityteam.org/viewtopic.php?f=20&t=13361 To which I've now added my own ideas |
From: Gale A. <ga...@au...> - 2009-10-03 08:59:16
|
| From Ed Musgrove <edg...@ya...> | Fri, 2 Oct 2009 21:50:14 -0700 (PDT) | Subject: [Audacity-devel] Problem with hidden second project window on Windows WAS: Re: wxGetClientDisplayRect > I think (from my tests) that currently the default first restores > from the registry if possible (it does on my system). The default does not look at any registry settings if you have opened .cfg and removed all the content except "NewPrefsInitialized=1" at the top. That is how I was testing with my cases (B) and (C) where I said I had "initialised .cfg". I think in the past we've touched on what to do with the 1.2 preferences when we release 2.0, and I think the consensus was not to delete them in case the user went back to 1.2. No doubt some people will do so, purely out of personal preference for a simpler app, or where they just prefer some specific behaviour in 1.2 to that in 1.3. Despite that, I'd have thought we would optimise behaviour for a freshly initialised .cfg, as that is a known quantity whereas a 1.2 preferences setting can't be. Gale > My graphics card (ATI) will not allow the primary monitor to be > disabled so nuking .cfg will restore visual project windows. > > What Gale added at viewtopic.php?f=20&t=13361 seems to cover the > bases until we try to implement this. > > > -Ed Musgrove > > > > ----- Original Message ---- > From: Gale Andrews ga...@au... > > Is that necessary? The defaults in the .cfg: > > X=0 > Y=0 > Width=600 > Height=440 > Maximized=0 > > should be able to work in all cases. Will those defaults fail if the > machine only has the second monitor working? > > > http://forum.audacityteam.org/viewtopic.php?f=20&t=13361 > > To which I've now added my own ideas > |
From: John C. <jc...@gm...> - 2009-10-03 13:11:47
|
Gale Andrews wrote: > | From John Colket <jc...@gm...> > | Fri, 02 Oct 2009 20:32:19 -0500 > | Subject: [Audacity-devel] Problem with hidden second project window on Windows WAS: Re: wxGetClientDisplayRect > > >> ... I imagine an uninstall could purge all of the .cfg file, but I do >> not know if it does this. >> > > Uninstallation of 1.3.x leaves the .cfg file completely "as is". > Similarly, uninstalling 1.2.x leaves the settings (on Windows, > the Audacity HKCU registry key) untouched. > > > >> ... The "catastrophe", that once the .cfg file gets corrupted, no simple, >> "Normal" recovery procedure can be used to ever get the program >> running again... To correct the catastrophe, I was thinking that all >> Audacity would have to do is during initialization, at the time it is >> reading the .cfg file and is loading up it's X,Y coordinates, that it >> could check this one time that the coordinates are reasonable for >> the current screen, and if not, to revert to the defaults. >> > > Is that necessary? The defaults in the .cfg: > > X=0 > Y=0 > Width=600 > Height=440 > Maximized=0 > > should be able to work in all cases. Will those defaults fail if the > machine only has the second monitor working? > > Gale, I think what I wrote was not clear. No, the defaults would /not/ have to be checked. But if defaults were /not/ being used it would be standard on every Audacity startup/initialization to check that what was read from the .cfg file made sense for the current machine configuration. In that case, if the config file made no sense, /then/ the defaults would be used /without/ checking. > >> While I personally favor the former, a system to re-initialize the >> .cfg file, as you suggest, would undoubtly provide a better return for >> the effort. In terms of re-initializing the .cfg file, there are three >> other ideas listed here: >> http://forum.audacityteam.org/viewtopic.php?f=20&t=13361 >> > > To which I've now added my own ideas for an executable in the > installation folder to initialise .cfg (to cover all cases where > Audacity can't be accessed, not just a "minimised" launch). > For example, switching to a sound device or driver set that > Audacity can't work with will typically give an error on launch, > with the only option being to quit. > +1 on your suggestion of a separate program to do this. I think keeping this out of the menu is a good idea. Also, since it looks like old Registry settings are going to be a problem ad infinitum, would it make sense for Audacity to ask /before/ transferring these settings to the new config file ? > Note that adding an incompatible plug-in could also cause > Audacity to fail to launch properly, which a .cfg reset won't > help. The chances of that should now be much reduced however > with our VST GUI support and VST scanning routine. > > |
From: Gale A. <ga...@au...> - 2009-10-03 19:08:40
|
| From John Colket <jc...@gm...> | Sat, 03 Oct 2009 08:11:25 -0500 | Subject: [Audacity-devel] Problem with hidden second project window on Windows WAS: Re: wxGetClientDisplayRect > Gale Andrews wrote: > > | From John Colket <jc...@gm...> > > | Fri, 02 Oct 2009 20:32:19 -0500 > > | Subject: [Audacity-devel] Problem with hidden second project window on Windows WAS: Re: wxGetClientDisplayRect > >> ... The "catastrophe", that once the .cfg file gets corrupted, no simple, > >> "Normal" recovery procedure can be used to ever get the program > >> running again... To correct the catastrophe, I was thinking that all > >> Audacity would have to do is during initialization, at the time it is > >> reading the .cfg file and is loading up it's X,Y coordinates, that it > >> could check this one time that the coordinates are reasonable for > >> the current screen, and if not, to revert to the defaults. > >> > > > > Is that necessary? The defaults in the .cfg: > > > > X=0 > > Y=0 > > Width=600 > > Height=440 > > Maximized=0 > > > > should be able to work in all cases. Will those defaults fail if the > > machine only has the second monitor working? > > > > Gale, I think what I wrote was not clear. No, the defaults would /not/ > have to be checked. But if defaults were /not/ being used it would be > standard on every Audacity startup/initialization to check that what was > read from the .cfg file made sense for the current machine > configuration. In that case, if the config file made no sense, /then/ > the defaults would be used /without/ checking. OK. You mentioned "initialization" so I thought you might be talking about initializing .cfg. This is the thread where the issue of the saved Metadata Editor co-ordinates pointing to a now unavailable second monitor was discussed: http://n2.nabble.com/Metadata-Editor-and-Multi-monitor-bug-tp2637790p2637790.html The fix there was that if the majority of the metadata window was positioned off a valid display, or either of the top two corners of the window fell off a valid display, the window was shown centered over the main Audacity window. I only ever said the fix was for Metadata Editor; we only changed the two tags source code files. We had people complaining at the time that if Audacity was in the secondary monitor when exited, then restarted with only the primary monitor available, it would be off screen. Ed seems to confirm that, so we do need a similar check like you suggest. > ... Also, since it looks like old Registry settings are going to be a > problem ad infinitum, would it make sense for Audacity to ask /before/ > transferring these settings to the new config file ? I think a confirmation dialogue would likely be more confusing than it's worth; the decision is just to keep the old registry settings or delete them. If there is a check like the above for the "off screen" case, that should not be a problem. I think the main problem with 1.2 will be getting across to Windows users that they need a new lame_enc.dll for MP3 Export. The path to that .dll will be stored in the 1.2 Registry settings, but (in theory) that should not be a problem if they install the new .dll to C:\Program Files\Lame for Audacity because Audacity should just detect and use that new one whatever the preferences path points to. That definitely works for me, though there are suspicions that perhaps it doesn't always do so for everyone. Gale PS Thanks for the plain text e-mail. Much easier to handle here. |
From: Ed M. <edg...@ya...> - 2009-10-04 00:55:17
|
I think this whole issue boils down to the perennial user interface trade-off; if the application was last visualized off the main monitor, should the application honor that user's decision (to operate off the main monitor), or should the application play it safe. If the choices to play it safe, the safest choice is to always open the application visualized on the main monitor; a safe but happy medium is just to open the application off the main monitor in its last known position then open an information dialog on the main monitor warning of this situation. All this could be set up as options in preferences and the information dialog could have that little checkbox for "Don't ever tell me again". Personally, I believe that Audacity should play it safe but offer the information dialog and store the user's choice in preferences. An additional preferences choice should exist which allows the power user's decision to open off the main monitor always honored. This would be fairly easy to implement; I would be happy to do so. As this is really a matter of any given user's personal taste, would it make any sense to open a discussion on the forum in regard to this issue? Maybe with a poll? I do not think that the solution provided for the Metadata Editor is completely appropriate for the opening Project window. I do think it might well be appropriate for any other window that opens subjective to a project window. -Ed Musgrove ----- Original Message ---- From: Gale Andrews ga...@au... This is the thread where the issue of the saved Metadata Editor co-ordinates pointing to a now unavailable second monitor was discussed: http://n2.nabble.com/Metadata-Editor-and-Multi-monitor-bug-tp2637790p2637790.html |
From: John C. <jc...@gm...> - 2009-10-04 06:20:56
|
Ed Musgrove wrote: > I think this whole issue boils down to the perennial user interface trade-off; if the application was last visualized off the main monitor, should the application honor that user's decision (to operate off the main monitor), or should the application play it safe. If the choices to play it safe, the safest choice is to always open the application visualized on the main monitor; a safe but happy medium is just to open the application off the main monitor in its last known position then open an information dialog on the main monitor warning of this situation. > > All this could be set up as options in preferences and the information dialog could have that little checkbox for "Don't ever tell me again". > > Personally, I believe that Audacity should play it safe but offer the information dialog and store the user's choice in preferences. An additional preferences choice should exist which allows the power user's decision to open off the main monitor always honored. > > This would be fairly easy to implement; I would be happy to do so. As this is really a matter of any given user's personal taste, would it make any sense to open a discussion on the forum in regard to this issue? Maybe with a poll? > > I do not think that the solution provided for the Metadata Editor is completely appropriate for the opening Project window. I do think it might well be appropriate for any other window that opens subjective to a project window. > -Ed Musgrove > Ed, I am happy that you are showing such thought and careful consideration into this matter. It shows that you are dedicated and keenly interested in the project, not taking shortcuts, and taking time to doing things right the first time. Personally, I favor the KISS method in this case. Minimize the amount of code that needs to be written and maintained. Hopefully, it won't be used more than once in the user's lifetime. It doesn't need to be fancy. It just needs to protect the user from a "catastrophic" problem. I would go for a an absolute minimum of code and logic. We can purge (or reinitialize the .cfg file elsewhere). Also, more options and queries for the user tends to overwhelm him. I would think that Audacity could look at the top two corners of the main window, as it does with Metadata, and see if either corner is displayable on any of the monitors. If either corner is displayable, give the user the benefit of the doubt; the user is going to be able to grab and re-position the window to wherever he wants it. Since the window is being displayed, and is capable of being manipulated, and is being displayed where the user wants it and remembers it, there is no need to advise or otherwise warn the user. No need to do him any favors. Action in this case: Simply leave things as the user left it. On the other hand, if Audacity finds that neither top corner is displayable, the user will be unable to manipulate the window and will require help. A warning message here would be superfluous. The window is going to have to be moved regardless. All Audacity would have to do is move the window to its default location. Time to bail out the user from a "fatal" problem. Action in this case: Return to defaults. - John |
From: Ed M. <edg...@ya...> - 2009-10-04 15:56:11
|
Hi John! The KISS method is frequently my favorite also. If it were possible on every OS for which Audacity compile to determine the current number of monitors, their resolution, their placement (i.e. main on right secondary on left), whether they are in extended or copy mode and their state (on/off) -- and I'm not convinced this is impossible -- then your solution makes complete sense to me -- respect the user's last configuration if possible. Audacity is a very mature program with a lot of features. We are way past the point of overwhelming the naïve user. No recent discussions about something like an Audacity Lite for users who are overwhelmed with all the features. Options, when provided with a reasonable default, do not impact a new, infrequent or naïve user. As for informational warning dialogs (especially those which may be turned off by the user both in the dialogue and in preferences), I do not believe that they overwhelm the naïve user nor annoy the power user. Obviously, the warning text itself needs to be clear and concise leaving no doubt as to the problem and explaining the offered solution. -Ed Musgrove ----- Original Message ---- From: John Colket jc...@gm... Ed Musgrove wrote: > I think this whole issue boils down to the perennial user interface trade-off Personally, I favor the KISS method in this case... Also, more options and queries for the user tends to overwhelm him. I would think that Audacity could look at the top two corners of the main window, as it does with Metadata, and see if either corner is displayable on any of the monitors. |
From: John C. <jc...@gm...> - 2009-10-04 16:26:11
|
Ed Musgrove wrote: > Hi John! > > The KISS method is frequently my favorite also. If it were possible on every OS for which Audacity compile to determine the current number of monitors, their resolution, their placement (i.e. main on right secondary on left), whether they are in extended or copy mode and their state (on/off) -- and I'm not convinced this is impossible -- then your solution makes complete sense to me -- respect the user's last configuration if possible. > But I thought the following code from Tags.cpp did the job on every OS, and worked properly for the Metadata window (although I don't see why the bottoms need to be checked): bool TagsEditor::IsWindowRectValid(const wxRect *windowRect) const { wxDisplay display; wxPoint topLeft(windowRect->GetTopLeft().x, windowRect->GetTopLeft().y); wxPoint topRight(windowRect->GetTopRight().x, windowRect->GetTopRight().y); wxPoint bottomLeft(windowRect->GetBottomLeft().x, windowRect->GetBottomLeft().y); wxPoint bottomRight(windowRect->GetBottomRight().x, windowRect->GetBottomRight().y); display.GetFromPoint(topLeft); if (display.GetFromPoint(topLeft) == -1 && display.GetFromPoint(topRight) == -1 && display.GetFromPoint(bottomLeft) == -1 && display.GetFromPoint(bottomRight) == -1) { return false; } return true; } > > Audacity is a very mature program with a lot of features. We are way past the point of overwhelming the naïve user. No recent discussions about something like an Audacity Lite for users who are overwhelmed with all the features. Options, when provided with a reasonable default, do not impact a new, infrequent or naïve user. > > As for informational warning dialogs (especially those which may be turned off by the user both in the dialogue and in preferences), I do not believe that they overwhelm the naïve user nor annoy the power user. Obviously, the warning text itself needs to be clear and concise leaving no doubt as to the problem and explaining the offered solution. > -Ed Musgrove > > > > ----- Original Message ---- > From: John Colket jc...@gm... > > Ed Musgrove wrote: > >> I think this whole issue boils down to the perennial user interface trade-off >> > > Personally, I favor the KISS method in this case... Also, more options and > queries for the user tends to overwhelm him. > > I would think that Audacity could look at the top two corners of the > main window, as it does with Metadata, and see if either corner is > displayable on any of the monitors. > > > > > |
From: Ed M. <edg...@ya...> - 2009-10-05 07:40:41
|
Hi! > From: John Colket <jc...@gm...> > But I thought the following code from Tags.cpp did the job on every OS, > and worked properly for the Metadata window (although I don't see why > the bottoms need to be checked): > > bool TagsEditor::IsWindowRectValid(const wxRect *windowRect) const > { > wxDisplay display; > wxPoint topLeft(windowRect->GetTopLeft().x, windowRect->GetTopLeft().y); > wxPoint topRight(windowRect->GetTopRight().x, > windowRect->GetTopRight().y); > wxPoint bottomLeft(windowRect->GetBottomLeft().x, > windowRect->GetBottomLeft().y); > wxPoint bottomRight(windowRect->GetBottomRight().x, > windowRect->GetBottomRight().y); > display.GetFromPoint(topLeft); > if (display.GetFromPoint(topLeft) == -1 && > display.GetFromPoint(topRight) == -1 && > display.GetFromPoint(bottomLeft) == -1 && > display.GetFromPoint(bottomRight) == -1) { > return false; > } > return true; > } If the window is maximized or iconized that code will not work (the Meta Data window allows neither). Note also the line: display.GetFromPoint(topLeft); which is extraneous. GetFromPoint() returns an int and the return value is ignored. I've got this "all" figured out on Windows Vista. The primary monitor is unit 0, secondary is unit 1 (and so on, I guess--I only have a dual monitor setup to test with). If a window is maximized or iconized it reports being on unit -1. Using reported window location is fine for non-maximized and non-minimized windows but not for maximized and iconized window which report x,y values out of the monitor' reporteds pixel region. I have no familiarity with other supported OSes so have no way to tell if code which works on Windows will work on them. Does UNIX even have windows—I’m pretty sure Macs do; if so, do either allow “maximizing” or “iconizing”? If some kind souls compiling on Mac, UNIX and other OSes (with multi-monitor setups) would give me the results of this using 2 projects and 2 monitors, I could be better informed. Stick this in just before SaveWindowSize() in AudacityApp.cpp and add the couple of line at the beginning of SaveWindowSize() (comment out the wxMessageBox() line and un-comment the printf() line and run from a command line with something like: Audacity.exe >> report.txt and attach the text file if practical) try with various combinations: here is some sample output from my system and the case matrix: 1 project: proj0 on mon 0 (main display) maximized top Left x=-8, y=-8, top Right x=1927, y=-8, bottom Left x=-8, y=1177, bottom Right x=1927, y=1177; monitor #-1 iconized top Left x=-32000, y=-32000, top Right x=-31841, y=-32000, bottom Left x=-32000, y=-31976, bottom Right x=-31841, y=-31976; monitor #-1 restored down top Left x=1025, y=119, top Right x=1824, y=119, bottom Left x=1025, y=665, bottom Right x=1824, y=665; monitor = 0 proj0 on mon 1 (2nd display) maximized iconized restored down 2 projects: proj0 on mon 0 (main display) proj1 on mon 0 maximized iconized restored down project0 top Left x=30, y=24, top Right x=676, y=24, bottom Left x=30, y=578, bottom Right x=676, y=578; monitor #0 project1 top Left x=50, y=54, top Right x=676, y=24, bottom Left x=50, y=578, bottom Right x=676, y=578; monitor #0 proj0 on mon 1 (2nd display) proj1 on mon 0 proj0 on mon 0 (main display) proj1 on mon 1 proj0 on mon 1 (2nd display) proj1 on mon 1 here’s the code: #include <wx/display.h>/*efm5*/ void MultiDisplayWindowRectValid(const wxWindow *window, size_t projNum) //just testing various display conditions and information returning functions /*efm5*/ { if (!window) { wxMessageBox("NULL window -- MultiDisplayWindowRectValid()!"); //printf("NULL window – MultiDisplayWindowRectValid()!\n"); return; } if (wxUSE_DISPLAY == 1) { wxString defined("wxUSE_DISPLAY is defined"); wxMessageBox(defined); //printf("wxUSE_DISPLAY is defined\n"); } wxRect windowRect = window->GetRect(); wxPoint topLeft(windowRect.GetTopLeft().x, windowRect.GetTopLeft().y); wxPoint topRight(windowRect.GetTopRight().x, windowRect.GetTopRight().y); wxPoint bottomLeft(windowRect.GetBottomLeft().x, windowRect.GetBottomLeft().y); wxPoint bottomRight(windowRect.GetBottomRight().x, windowRect.GetBottomRight().y); wxDisplay display; const unsigned numdisplays = display.GetCount(); wxString numDisplays; //numDisplays.Printf("There are %d monitors\n", numdisplays); wxMessageBox(numDisplays); //printf("%s\n", numDisplays.c_str()); int monitorFromPoint = display.GetFromPoint(topLeft); if (monitorFromPoint == wxNOT_FOUND) { wxMessageBox("wxNOT_FOUND -- monitor not found"); //printf("wxNOT_FOUND -- monitor not found, %d\n", projNum); } wxString corners; corners.Printf("The corners of window %d are: \n\t\ttop Left x=%d, y=%d, \n\t\ttop Right x=%d, y=%d, \n\t\tbottom Left x=%d, y=%d, \n\t\tbottom Right x=%d, y=%d; \n\t\tmonitor #%d\n", projNum, topLeft.x,topLeft.y, topRight.x,topRight.y, bottomLeft.x,bottomLeft.y, bottomRight.x,bottomRight.y, monitorFromPoint); wxMessageBox(corners); //printf("%s\n", corners.c_str()); for (unsigned i = 0; i < numdisplays; i++) { wxDisplay *thisDispaly = new wxDisplay(i); wxRect geo = thisDispaly->GetGeometry(); wxPoint geotopLeft(geo.GetTopLeft().x, geo.GetTopLeft().y); wxPoint geotopRight(geo.GetTopRight().x, geo.GetTopRight().y); wxPoint geobottomLeft(geo.GetBottomLeft().x, geo.GetBottomLeft().y); wxPoint geobottomRight(geo.GetBottomRight().x, geo.GetBottomRight().y); wxString geoCorners; geoCorners.Printf("This is monitor #%d, it's corners are at: \n\ttop Left x=%d, y=%d, \n\ttop Right x=%d, y=%d, \n\tbottom Left x=%d, y=%d, \n\tbottom Right x=%d, y=%d\n", i, geotopLeft.x,geotopLeft.y, geotopRight.x,geotopRight.y, geobottomLeft.x,geobottomLeft.y, geobottomRight.x,geobottomRight.y); wxMessageBox(geoCorners); //printf(geoCorners.c_str()); delete thisDispaly; } } void SaveWindowSize() //This code was heavily modified to deal with iconized project windows. //efm5 28 September 2009 //this code only saves the Project window size { //////////////// add this /////////////////////////////// size_t anumProjects = gAudacityProjects.Count(); for (size_t i = 0; i < anumProjects; i++) { wxWindow * projectWindow = (wxWindow *)gAudacityProjects[i]; MultiDisplayWindowRectValid(projectWindow, i); } //////////////////////////////////////////////////////////////////// -Ed Musgrove |
From: John C. <jc...@gm...> - 2009-10-05 14:25:29
|
Ed Musgrove wrote: > Hi! > > >> From: John Colket <jc...@gm...> >> But I thought the following code from Tags.cpp did the job on every OS, >> and worked properly for the Metadata window (although I don't see why >> the bottoms need to be checked): >> >> bool TagsEditor::IsWindowRectValid(const wxRect *windowRect) const >> { >> wxDisplay display; >> wxPoint topLeft(windowRect->GetTopLeft().x, windowRect->GetTopLeft().y); >> wxPoint topRight(windowRect->GetTopRight().x, >> windowRect->GetTopRight().y); >> wxPoint bottomLeft(windowRect->GetBottomLeft().x, >> windowRect->GetBottomLeft().y); >> wxPoint bottomRight(windowRect->GetBottomRight().x, >> windowRect->GetBottomRight().y); >> display.GetFromPoint(topLeft); >> if (display.GetFromPoint(topLeft) == -1 && >> display.GetFromPoint(topRight) == -1 && >> display.GetFromPoint(bottomLeft) == -1 && >> display.GetFromPoint(bottomRight) == -1) { >> return false; >> } >> return true; >> } >> > > If the window is maximized or iconized that code will not work (the Meta Data window allows neither). Note also the line: > display.GetFromPoint(topLeft); > which is extraneous. GetFromPoint() returns an int and the return value is ignored. > > I've got this "all" figured out on Windows Vista. The primary monitor is unit 0, secondary is unit 1 (and so on, I guess--I only have a dual monitor setup to test with). If a window is maximized or iconized it reports being on unit -1. Using reported window location is fine for non-maximized and non-minimized windows but not for maximized and iconized window which report x,y values out of the monitor' reporteds pixel region. > > Once again, your thoroughness inspires me. :) Also, consider that Audacity doesn't have to come up either minimized or maximized. It would seem logical to force a "Restore" on the window in either case. A single click for the user could put him into his altered state. Think KISS. > I have no familiarity with other supported OSes so have no way to tell if code which works on Windows will work on them. Does UNIX even have windows—I’m pretty sure Macs do; if so, do either allow “maximizing” or “iconizing”? > If some kind souls compiling on Mac, UNIX and other OSes (with multi-monitor setups) would give me the results of this using 2 projects and 2 monitors, I could be better informed. Stick this in just before SaveWindowSize() in AudacityApp.cpp and add the couple of line at the beginning of SaveWindowSize() (comment out the wxMessageBox() line and un-comment the printf() line and run from a command line with something like: > Audacity.exe >> report.txt > and attach the text file if practical) try with various combinations: > here is some sample output from my system and the case matrix: > > 1 project: > proj0 on mon 0 (main display) > maximized > top Left x=-8, y=-8, > top Right x=1927, y=-8, > bottom Left x=-8, y=1177, > bottom Right x=1927, y=1177; > monitor #-1 > iconized > top Left x=-32000, y=-32000, > top Right x=-31841, y=-32000, > bottom Left x=-32000, y=-31976, > bottom Right x=-31841, y=-31976; > monitor #-1 > restored down > top Left x=1025, y=119, > top Right x=1824, y=119, > bottom Left x=1025, y=665, > bottom Right x=1824, y=665; > monitor = 0 > proj0 on mon 1 (2nd display) > maximized > iconized > restored down > 2 projects: > proj0 on mon 0 (main display) proj1 on mon 0 > maximized > iconized > restored down > project0 > top Left x=30, y=24, > top Right x=676, y=24, > bottom Left x=30, y=578, > bottom Right x=676, y=578; > monitor #0 > project1 > top Left x=50, y=54, > top Right x=676, y=24, > bottom Left x=50, y=578, > bottom Right x=676, y=578; > monitor #0 > proj0 on mon 1 (2nd display) proj1 on mon 0 > proj0 on mon 0 (main display) proj1 on mon 1 > proj0 on mon 1 (2nd display) proj1 on mon 1 > > here’s the code: > > #include <wx/display.h>/*efm5*/ > > void MultiDisplayWindowRectValid(const wxWindow *window, size_t projNum) > //just testing various display conditions and information returning functions /*efm5*/ > { > if (!window) > { > wxMessageBox("NULL window -- MultiDisplayWindowRectValid()!"); > //printf("NULL window – MultiDisplayWindowRectValid()!\n"); > return; > } > if (wxUSE_DISPLAY == 1) > { > wxString defined("wxUSE_DISPLAY is defined"); > wxMessageBox(defined); > //printf("wxUSE_DISPLAY is defined\n"); > } > wxRect windowRect = window->GetRect(); > wxPoint topLeft(windowRect.GetTopLeft().x, windowRect.GetTopLeft().y); > wxPoint topRight(windowRect.GetTopRight().x, windowRect.GetTopRight().y); > wxPoint bottomLeft(windowRect.GetBottomLeft().x, windowRect.GetBottomLeft().y); > wxPoint bottomRight(windowRect.GetBottomRight().x, windowRect.GetBottomRight().y); > wxDisplay display; > const unsigned numdisplays = display.GetCount(); > wxString numDisplays; > //numDisplays.Printf("There are %d monitors\n", numdisplays); > wxMessageBox(numDisplays); > //printf("%s\n", numDisplays.c_str()); > int monitorFromPoint = display.GetFromPoint(topLeft); > if (monitorFromPoint == wxNOT_FOUND) > { > wxMessageBox("wxNOT_FOUND -- monitor not found"); > //printf("wxNOT_FOUND -- monitor not found, %d\n", projNum); > } > wxString corners; > corners.Printf("The corners of window %d are: \n\t\ttop Left x=%d, y=%d, \n\t\ttop Right x=%d, y=%d, \n\t\tbottom Left x=%d, y=%d, \n\t\tbottom Right x=%d, y=%d; \n\t\tmonitor #%d\n", > projNum, topLeft.x,topLeft.y, topRight.x,topRight.y, bottomLeft.x,bottomLeft.y, bottomRight.x,bottomRight.y, monitorFromPoint); > wxMessageBox(corners); > //printf("%s\n", corners.c_str()); > for (unsigned i = 0; i < numdisplays; i++) > { > wxDisplay *thisDispaly = new wxDisplay(i); > wxRect geo = thisDispaly->GetGeometry(); > wxPoint geotopLeft(geo.GetTopLeft().x, geo.GetTopLeft().y); > wxPoint geotopRight(geo.GetTopRight().x, geo.GetTopRight().y); > wxPoint geobottomLeft(geo.GetBottomLeft().x, geo.GetBottomLeft().y); > wxPoint geobottomRight(geo.GetBottomRight().x, geo.GetBottomRight().y); > wxString geoCorners; > geoCorners.Printf("This is monitor #%d, it's corners are at: \n\ttop Left x=%d, y=%d, \n\ttop Right x=%d, y=%d, \n\tbottom Left x=%d, y=%d, \n\tbottom Right x=%d, y=%d\n", > i, geotopLeft.x,geotopLeft.y, geotopRight.x,geotopRight.y, geobottomLeft.x,geobottomLeft.y, geobottomRight.x,geobottomRight.y); > wxMessageBox(geoCorners); > //printf(geoCorners.c_str()); > delete thisDispaly; > } > } > void SaveWindowSize() > //This code was heavily modified to deal with iconized project windows. > //efm5 28 September 2009 > //this code only saves the Project window size > { > //////////////// add this /////////////////////////////// > size_t anumProjects = gAudacityProjects.Count(); > for (size_t i = 0; i < anumProjects; i++) > { > wxWindow * projectWindow = (wxWindow *)gAudacityProjects[i]; > MultiDisplayWindowRectValid(projectWindow, i); > } //////////////////////////////////////////////////////////////////// > > -Ed Musgrove |
From: Ed M. <edg...@ya...> - 2009-10-05 16:51:02
|
Hi! ----- Original Message ---- > From: John Colket jc...@gm... > >>Ed said: >> I've got this "all" figured out on Windows Vista. The primary monitor is unit >> 0, secondary is unit 1 (and so on, I guess--I only have a dual monitor setup to >> test with). If a window is maximized or iconized it reports being on unit -1. >> Using reported window location is fine for non-maximized and non-minimized >> windows but not for maximized and iconized window which report x,y values out of >> the monitor' reporteds pixel region. > > Once again, your thoroughness inspires me. :) Also, consider that > Audacity doesn't have to come up either minimized or maximized. Being thorough is the only way to both learn this established code base and "get it right". I now have the complete wxWidgets (Mac, UNIX etc.) code (stripped down to just C, C++ and header files) installed on my harddrive so that I can at least examine the methods used on other OSes. As for exhaustive case testing, that is the only way I would have noticed that BOTH maximized and iconized windows report -1 for their monitor unit. I consider this to be at best poor program design and at worst a bug for both as maximized windows are clearly on a monitor and both, when un-maximized/iconized, recall their original monitor, size and location. As for “consider that Audacity doesn't have to come up either minimized or maximized”, that is not quite accurate. Current design philosophy for Audacity respects the maximized (state which it stores in preferences) and respects at launch. Audacity also respects multi-monitor usage but in a potentially non-user-friendly manner. At least, after my patch, the problem is not catastrophic – if one closes Audacity in a state not stored in preferences it no longer opens in never never land! Here is the new behavior I would like to see (and can accomplish myself in Windows): 1) Currently, if one starts with the window centered on the main monitor and covering 25% of the main monitor, then one clicks maximize and subsequently exits Audacity; if one relaunches Audacity it opens on the main monitor maximized; all this is good and proper so far. Now however, if one “restores down” the maximized window the resulting window covers almost the same amount of the main monitor as it did when maximized; the only difference is the minor icon change at the top right and the addition of the sizing gadget at the bottom right. Windows stores the original “restore down” size and location of a maximized window; I would like Audacity to do the same in preferences; thus when Audacity exits in a maximized condition it also saves the appropriate “restore down” size and location. 2) If Audacity exits with all project windows iconized upon relaunch it currently opens a new project window in the default position on the main monitor. I would like Audacity to select an appropriate iconized window, determine its monitor, size and location, then store those values in preferences as the position, size and monitor to use upon relaunch. 3) As previously stated, I would like to add an informational dialogue (with a “never show this dialog again” checkbox) which warns the user if Audacity launches off the main monitor. In conjunction with this I would like to add two preference items: a) a toggle/checkbox to turn on/off “Never show the multi-monitor warning dialog” b) a toggle/checkbox to turn on/off “Always launch on the main monitor” -Ed Musgrove |
From: Gale A. <ga...@au...> - 2009-10-05 21:40:39
Attachments:
diffResult2.Oct.09.txt
|
| From Ed Musgrove <edg...@ya...> | Mon, 5 Oct 2009 09:50:49 -0700 (PDT) | Subject: [Audacity-devel] Problem with hidden second project window on Windows WAS: Re: wxGetClientDisplayRect > I have no familiarity with other supported OSes so have no way > to tell if code which works on Windows will work on them. Does > UNIX even have windows I'm pretty sure Macs do; if so, do > either allow maximizing or iconizing Using the GNOME desktop environment on Linux, windows work very similarly to the Windows OS with maximise and minimise (termed as such). The other common desktop environment on Linux (KDE) I believe also supports maximise and minimise (though the buttons look different). I have never tried KDE and don't intend to. > Being thorough is the only way to both learn this established > code base and "get it right". I now have the complete wxWidgets (Mac, > UNIX etc.) code (stripped down to just C, C++ and header files) > installed on my harddrive so that I can at least examine the methods > used on other OSes. As for exhaustive case testing, that is the only way > I would have noticed that BOTH maximized and iconized windows report -1 > for their monitor unit. I consider this to be at best poor program > design and at worst a bug for both as maximized windows are clearly on a > monitor and both, when un-maximized/iconized, recall their original > monitor, size and location. Are you proposing to fix this then (what are the implications of not doing so)? > As for consider that Audacity doesn't have to come up either > minimized or maximized, that is not quite accurate. Current design > philosophy for Audacity respects the maximized (state which it stores in > preferences) and respects at launch. Audacity also respects > multi-monitor usage but in a potentially non-user-friendly manner. At > least, after my patch, the problem is not catastrophic if one closes > Audacity in a state not stored in preferences it no longer opens in > never never land! This thread has been very difficult to follow in more ways than one (is it possible to set a sensible word wrap on your posts, Ed, so those on smaller screens or trying to view them in a summary window can do so without horizontal scrolling)? So forgive this question, but I thought the (main) problem was that second screen co-ordinates were saved when Audacity was open and exited on a second monitor, but that if that second monitor was then removed and Audacity started, Audacity would then be invisible. How do you close Audacity in a state not saved in preferences, given closing it should save the co-ordinates? Or are you saying the same thing another way around? > Here is the new behavior I would like to see (and can accomplish > myself in Windows): > 1) Currently, if one starts with the window centered on the main > monitor and covering 25% of the main monitor, then one clicks maximize > and subsequently exits Audacity; if one relaunches Audacity it opens on > the main monitor maximized; all this is good and proper so far. Now > however, if one restores down the maximized window the resulting > window covers almost the same amount of the main monitor as it did when > maximized; the only difference is the minor icon change at the top right > and the addition of the sizing gadget at the bottom right. Windows > stores the original restore down size and location of a maximized > window; I would like Audacity to do the same in preferences; thus when > Audacity exits in a maximized condition it also saves the appropriate > restore down size and location. What I think you mean is, if you "restore down" to a much smaller window (such as 600 x 400) than the "covers almost the same amount of the main monitor", then: * maximise * exit * relaunch * "restore down" the "restored down" position is the "almost the same amount" instead of 600 x 400. +1 to make that change. > 2) If Audacity exits with all project windows iconized upon relaunch > it currently opens a new project window in the default position on the > main monitor. I would like Audacity to select an appropriate iconized > window, determine its monitor, size and location, then store those > values in preferences as the position, size and monitor to use upon > relaunch. This may be over-simplistic, but if all windows are iconised how can it decide co-ordinates (for example in the simplest "main monitor only" situation)? If this happens with a fresh .cfg file, it seems to me current behaviour may be sensible, assuming it picks the correct monitor. Otherwise, why not preserve and use the last saved position in .cfg (including the last "restored down" position if we make that change)? > 3) As previously stated, I would like to add an informational dialogue > (with a never show this dialog again checkbox) which warns the user > if Audacity launches off the main monitor. In conjunction with this I > would like to add two preference items: > a) a toggle/checkbox to turn on/off Never show the multi-monitor warning dialog > b) a toggle/checkbox to turn on/off Always launch on the main monitor a) would go in the Warnings tab of Preferences - which tab do you have in mind for b)? I presume checking b) in the dialogue greys out a)? I'm only weakly in favour, partly because we can easily get Preferences "blight" in Audacity, and this seems rather a fringe issue. I assume I'm correct the vast majority of users don't use second monitors. I'd just as soon have Audacity launch on the main monitor without dialogue if the user arranges things so that it would otherwise launch off the main monitor. It's a user error. Or, just a message with no preferences. But that's only my view. --- Ed, I've reattached your diff for the error in your previous fix for "windows opening minimised". Although I assume the < citation is what you want to change, patches should be submitted as unified diff so it is clear what is changing. I've been guilty in the past, as Windows does not have the correct tools immediately to hand, so you're forgiven :=) Can you resubmit please as a unified diff then if no-one else has comments or commits it, I can do so. Thanks Gale |
From: John C. <jc...@gm...> - 2009-10-01 23:59:34
|
Gale Andrews wrote: > Hi Ed > > Many thanks for your patience and thoroughness with this. > I haven't tested every possible permutation of scenarios > on Windows XP, but after your patch I cannot now reproduce > my scenario that reliably led to the problem, and John's > creates no issue here. > > I notice that when I now (A) launch Audacity with default > x,y position (restored window), minimise it then relaunch > the executable, the new window comes on top but the old > one stays minimised. That isn't the behaviour I got before > when following those steps; what happened then was that > both windows came up on relaunching the executable, > with the old one behind at top left and the new one offset > and on top. So I guess that's better too, because it respects > the iconisation of the old window. > > I note however that if (B) I have one window restored, > don't minimise it but just task switch to the 1.3.10 > directory and re-launch, the old window is also minimised, > not respecting the state of the old window. This is also > different behaviour from (C) clicking File > New in a > restored window, where the old is visible without focus > behind the new. > > So although it's a small point I guess we may as well > discuss it: > > In case (C), is it best behaviour as now to leave the old > window restored, or minimise it, as John seems to > want to do? I think leave as is, as this seems more > normal behaviour? If so, is there any case for (B) > behaving as (C)? > > Reading your discussion, your changes may hopefully > have fixed the other scenarios we don't know about > where users launch Audacity but it is minimised > "P3 (Windows only) After a period launching correctly, > Audacity opens minimised." > > John, can you test out Ed's work please if you have a > moment: > http://www.gaclrecords.org.uk/audacity-win-unicode-1.3.10-alpha.zip > > Gale, Ed, I am quite happy with what I see. Ed's fix seems to correct the problem where the .cfg file gets garbled causing subsequent attempts to access Audacity to be futile. Congratulations, Ed! And thank you! Gale, when I run through your scenarios, I get slightly different behaviors on my XP SP3 machine: In case (A), the new 1.3.10 works properly as you describe, but with 1.3.9, as before, both windows became minimized, and led to the .cfg damage. In case (B), with 1.3.10, the second windows appears properly, perhaps exactly as I would expect, exactly the same size as the old window, on top of the it with the focus, and down and to the right about 1/4". The top and left edges of the old window are visible behind the new one. In case (C) with 1.3.10, the results are identical to my case (B), which I would think is a good thing. In all of the above cases, the new 1.3.10 passes with flying colors for me. Now I have a new case in 1.3.10, which I will call case (M), which doesn't seem quite exactly right, but is perfectly acceptable as is. This case is identical to case (B), with the exception that the original window was Maximized. In this case the second window comes up maximized as one would expect, but if I then click on the box to "Restore" it, it comes up in the upper-left hand corner of the screen. This would be OK except, unfortunately, in my case, I run my task bar on the left edge of the screen, so the left 1/2" of the new Audacity window is hidden by the task bar. As I said before, this is a situation I can deal with. The behavior under 1.3.9 puts the two windows exactly on top of each other and does not have this issue. The only other case I would bring up is the desirability of arming Audacity to defend against a corrupted .cfg file. This could happen if, as you say, (1) there are "other scenarios we don't know about", (2) there is other prior .cfg damage from perhaps running a beta, or (3) the possible case where the Audacity window is left on a second monitor screen which is subsequently removed. Since each of these cases are hopefully one-time events, they could be manually dealt with; besides one might question making additional changes this close to the 2.0 release. Another advantage of postponing this effort is that the longer we wait, the less of an issue it becomes (assuming it was one to begin with). (I cling to the belief that there might be an Audacity user out there with a damaged file, who has given up on Audacity, but nonetheless later installs 2.0 only to find out that this install apparently fails as well). In summary, I am quite happy - mostly for Audacity's sake - that this problem was reproduced and corrected prior to the new stable release. Ed, Gale, thank you very much for your interest in pursuing this issue, as well as the corrections you have brought forth! - John |
From: Ed M. <edg...@ya...> - 2009-10-02 04:55:48
|
Hi John! Let me take your points in reverse order. Personally, no thanks are necessary; I am thoroughly enjoying renewing my C++ skills with Audacity -- after a 5 year hiatus, not only am I rusty, but the language has matured greatly and the IDE of Visual Studio (especially the 2010 version) is beyond acceptable. As for repairing the configuration file, I beta test another commercial program which has a way of dealing with this. This program is a 3-D CAD program and is normally started by double-clicking on the program icon or a project icon. However, when run from the command line one may add switches one of which deletes the configuration file and one of which restores all Windows registry settings to their default value. Given the Audacity does not use registry settings anymore it would be a trivial matter to add this code for any OS which has a command line (I know UNIX does and Windows does what I do not know about Mac or any other OSes that Audacity might run on). As for case (M), as I understand your explanation, what you are saying is that Audacity does not respect alternate Taskbar positions (across the bottom being the "normal"). Once again, I have no knowledge of UNIX or the Mac OS, do they have Taskbar's and if so where are they "normally" and are they adjustable by the user? Currently, Audacity hard codes a "default" window size and location -- off the top of my head I do not recall what the exact figures are but they are a few pixels down and right from 0, 0. I am sure that on Windows there is a function built into the operating system which returns the size and location of the Taskbar. I could "repair" Audacity for case (M), but it would be specific to Windows. Making this a cross platform change would require other programmers to write code for those other OSes. -Ed Musgrove ----- Original Message ---- From: John Colket jc...@gm... Gale, when I run through your scenarios, I get slightly different behaviors on my XP SP3 machine[...] Now I have a new case in 1.3.10, which I will call case (M), which doesn't seem quite exactly right, but is perfectly acceptable as is. This case is identical to case (B), with the exception that the original window was Maximized. In this case the second window comes up maximized as one would expect, but if I then click on the box to "Restore" it, it comes up in the upper-left hand corner of the screen. This would be OK except, unfortunately, in my case, I run my task bar on the left edge of the screen, so the left 1/2" of the new Audacity window is hidden by the task bar. As I said before, this is a situation I can deal with. The behavior under 1.3.9 puts the two windows exactly on top of each other and does not have this issue. The only other case I would bring up is the desirability of arming Audacity to defend against a corrupted .cfg file. |
From: John C. <jc...@gm...> - 2009-10-03 01:50:58
|
Ed Musgrove wrote: > Hi John! > > Let me take your points in reverse order. Personally, no thanks are necessary; I am thoroughly enjoying renewing my C++ skills with Audacity -- after a 5 year hiatus, not only am I rusty, but the language has matured greatly and the IDE of Visual Studio (especially the 2010 version) is beyond acceptable. > > As for repairing the configuration file, I beta test another commercial program which has a way of dealing with this. This program is a 3-D CAD program and is normally started by double-clicking on the program icon or a project icon. However, when run from the command line one may add switches one of which deletes the configuration file and one of which restores all Windows registry settings to their default value. Given the Audacity does not use registry settings anymore it would be a trivial matter to add this code for any OS which has a command line (I know UNIX does and Windows does what I do not know about Mac or any other OSes that Audacity might run on). > > As for case (M), as I understand your explanation, what you are saying is that Audacity does not respect alternate Taskbar positions (across the bottom being the "normal"). Once again, I have no knowledge of UNIX or the Mac OS, do they have Taskbar's and if so where are they "normally" and are they adjustable by the user? Currently, Audacity hard codes a "default" window size and location -- off the top of my head I do not recall what the exact figures are but they are a few pixels down and right from 0, 0. > > I am sure that on Windows there is a function built into the operating system which returns the size and location of the Taskbar. I could "repair" Audacity for case (M), but it would be specific to Windows. Making this a cross platform change would require other programmers to write code for those other OSes. > -Ed Musgrove > Ed, Thanks again for your attention to this matter. Case (M) is not of significance to me - I merely brought it up so that you were aware of it. - John |
From: Ed M. <edg...@ya...> - 2009-10-06 06:49:27
Attachments:
ProjectDIFF.txt
|
----- Original Message ---- > From: Gale Andrews ga...@au... > > Ed, I've reattached your diff > > Can you resubmit please as a unified diff then if no-one else > has comments or commits it, I can do so. Martyn wanted me to try a diff with recursion--I only found the GNU version (which produced the diff you did not like), I have attached a Python unified diff which he liked (as only one file is changed recursion is not in play). > This thread has been very difficult to follow in more ways than one > (is it possible to set a sensible word wrap on your posts I have many text editors and word processors installed. As far as I can determine none of them will force a wordwrap. I have tried to manually wordwrap this reply but it makes editing a nightmare! I have a minor disability which makes using a mouse and typing somewhat difficult. Most of my text, even when programming, is dictated using Dragon NaturallySpeaking. > Using the GNOME desktop environment on Linux, windows work > very similarly to the Windows OS with maximise and minimise > (termed as such). The other common desktop environment on > Linux (KDE) I believe also supports maximise and minimise > (though the buttons look different). I have never tried KDE and > don't intend to. Without someone willing to help me determine what monitor unit values are returned by wxWidgets on other OSes for windows which are iconized and maximized I may only ensure that my code works on Windows Vista. >> BOTH maximized and iconized windows report -1 > > for their monitor unit. I consider this to be at best poor program > > design and at worst a bug for both as maximized windows are clearly on a > > monitor and both, when un-maximized/iconized, recall their original > > monitor, size and location. > > Are you proposing to fix this then (what are the implications > of not doing so)? I am happy and willing to "fix" this. The best method of fixing thisis to repair wxWidgets. I can do that but I am not authorized to commit patches for wxWidgets. As a workaround, the Audacity code can test for a monitor unit returned value of -1. If it is -1 then it can test for IsMaximized() and IsIconized(). Of course, a window can be both if it has been iconized from a maximized state. > So forgive this question, but I thought the (main) problem was that > second screen co-ordinates were saved when Audacity was open > and exited on a second monitor, but that if that second monitor was > then removed and Audacity started, Audacity would then be > invisible. After examining all the information that I could get on the problem I found that it presented in at least 2 or more situations. More generally, the problem can be stated as "Audacity opens its original project window at a pixel location which is not within the current visible pixel region." Examining the configuration file shows us that the saved window location is not within the current visible pixel region. This can happen due to multiple scenarios involving any combination of one or more of maximized windows, iconized windows and multiple monitors. After reviewing this discussion on this developer's list I got the impression that the consensus was that Audacity should respect the user's use of multiple monitors (just as it currently does) and if the user closes the last project window on a secondary monitor, when Audacity re-opens, the original project window will open at that same location on the secondary monitor (even if that secondary monitor no longer exists--a secondary monitor that is not powered up still "exists"). > What I think you mean is, if you "restore down" to a much smaller > window (such as 600 x 400) than the "covers almost the same > amount of the main monitor", then: > > * maximise > * exit > * relaunch > * "restore down" > > the "restored down" position is the "almost the same amount" > instead of 600 x 400. > > +1 to make that change. I would like to reiterate: *one project window open -- 400 x 200 *maximize *exit *relaunch *project window opens maximized *"restore down" -- window now 400 x 200 (currently it is maxX x MaxY minus menu and taskbar) > > 2) If Audacity exits with all project windows iconized upon relaunch > > it currently opens a new project window in the default position on the > > main monitor. I would like Audacity to select an appropriate iconized > > window, determine its monitor, size and location, then store those > > values in preferences as the position, size and monitor to use upon > > relaunch. > > This may be over-simplistic, but if all windows are iconised how > can it decide co-ordinates (for example in the simplest "main > monitor only" situation)? An iconized window knows its previous size and location obviously (when un-iconized it goes back to its old size & location), we save those values instead of the -32,000 x -32,000. > Otherwise, why not preserve and use the last saved position in > .cfg (including the last "restored down" position if we make > that change)? This amounts to precisely what I am suggesting. > > I would like to add an informational dialogue > > (with a “never show this dialog again” checkbox) ... > > a) a toggle/checkbox to turn on/off “Never show the multi-monitor warning > dialog” > > b) a toggle/checkbox to turn on/off “Always launch on the main monitor” > > a) would go in the Warnings tab of Preferences - which tab do > you have in mind for b)? I presume checking b) in the dialogue > greys out a)? Checking b would gray out a. Given that you have 2 tabs one for Interface and one for Warnings, a should go in Warnings and b should go in Interface. > I'm only weakly in favour, partly because we can easily get > Preferences "blight" in Audacity As for preferences "blight", I am a firm believer in giving the user has much choice as practical. Being the new kid on the block though, after making my case I will not press the point. -Ed Musgrove |