Bugzilla – Bug 618
Chains - no minimum width set for column title in the "Chain" window
Last modified: 2018-08-20 11:51:47 UTC
In the right hand window of the "Edit Chains" dialog, there is no minimum width set for the columns that display the titles (Num, Command and Parameters). Thus when adding a new Chain (or when adding a command to a chain which has short text or no parameters) the column titles are uglily and unhelpfully truncated, resulting in an unclear GUI for the user. Steps to reproduce: 1) select File > Edit Chains... 2) click the Add button 3) the "Chain" window displays: truncated-N... Com ... P...
(In reply to comment #0) I have set this as a P4 for now but it could be considered for upgrading.
Created attachment 347 [details] Sets default column width
Seems OK on Windows and Linux. Cannot test on Mac until I get a replacement cable. I notice on Windows you can drag a column over a neighbour, obliterating it completely including its border. On Linux, you can't quite do that but you can obliterate the text. Is there any point in allowing that, or isn't it preventable?
(In reply to comment #3) I don't think that can be prevented. If a user wants to resize the column close to zero width they can, but (testing on Linux) the columns will automatically resize to make all columns the correct width as soon as they select or add a Chain. or re-open the window.
(In reply to comment #4) > (testing on Linux) the columns will automatically resize to make all columns the > correct width as soon as they select or add a Chain. or re-open the window. Yes on Windows too, but this was why my suggestion was for a minimum width. Compare the VLC hotkeys preferences where you can never completely obliterate the column.It seems to me these Audacity columns (except maybe Num) are not optional, like choosing columns to show in a file manager list are. But if it's a Widgets limitation (Tortoise does the same) or people like it that way, it's acceptable I guess. If Edit Chains is ever changed to remember its size and column positions then it may need revisiting. Being able to reopen the dialogue wider where a command has many parameters would be really useful.
Created attachment 353 [details] edit chains pre-patch image
Created attachment 354 [details] edit chains after-patch image
Attached before-patch and after-patch images on Mac. The command headers are now readable but each column is 1/3rd of the width, so little parameters info can be seen. However the patch cures the problem that clicking on the column headings obliterated the text underneath.
Steve, neither of the two patches you sent me off-list (2a and 2b) change anything. On initialised cfg, then File > Edit Chains..., each column is 1/3rd of the width. Resizing the window to right means you can read more of the parameters, but does not make the other two columns change width. Perhaps Leland might know?
Created attachment 359 [details] Workaround fixed header width on Mac As previous patch with wxMac fix from Leland. I have only tested this on Linux.
(In reply to comment #10) > workaround fixed header width on Mac Thanks, Leland. This works OK for me on Mac so that the initialised width fits to the width of the columns like on Windows and Linux. I won't say I like it as much as it might be with minimum width columns to fill the window e.g. if no commands have parameters then as it is now, there is a redundant fourth column wider than the others. Still, it's far better than before. Debug build asserts on Mac when you double-click a command row in Chain: ../src/mac/carbon/listctrl_mac.cpp(2071): assert "status == noErr" failed in HitTest() but it does this in HEAD too. I have a stack trace if wanted. Release Builds do not crash when double-clicking the commmand row (HEAD or this patch). Do you want to track it as a low priority bug, Leland?
(In reply to comment #11) > (In reply to comment #10) > > workaround fixed header width on Mac > Thanks, Leland. This works OK for me on Mac so that the initialised width fits > to the width of the columns like on Windows and Linux. I won't say I like it as > much as it might be with minimum width columns to fill the window e.g. if no > commands have parameters then as it is now, there is a redundant fourth column > wider than the others. Still, it's far better than before. > I didn't test for that. Let me see if there's an easy correction. Btw, the way Steve fixed this will work equally well for other places where wxListCtrl column oddities exist. > Debug build asserts on Mac when you double-click a command row in Chain: > > ../src/mac/carbon/listctrl_mac.cpp(2071): assert "status == noErr" failed in > HitTest() > > but it does this in HEAD too. I have a stack trace if wanted. Release Builds do > not crash when double-clicking the commmand row (HEAD or this patch). Do you > want to track it as a low priority bug, Leland? I got it too and looked into it. It looks like the wx folks were trying to debug something and left in an assertion to try and capture it. It's only in Debug builds of wxMac, so it can be ignored. Leland
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > workaround fixed header width on Mac > > Thanks, Leland. This works OK for me on Mac so that the initialised width fits > > to the width of the columns like on Windows and Linux. I won't say I like it as > > much as it might be with minimum width columns to fill the window e.g. if no > > commands have parameters then as it is now, there is a redundant fourth column > > wider than the others. Still, it's far better than before. > > > > I didn't test for that. Let me see if there's an easy correction. I see the what you mean. Does that same thing happen on Windows/Linux? (Sorry, not in a position to test those right now.) Would you have the (empty) Parameter column simply extend completely to the right so that 4th "column" (really, just unused space) doesn't show? Leland
(In reply to comment #13) > I see the what you mean. Does that same thing happen on Windows/Linux? Yes, the same on those. The only platform difference I see is that on Windows, you can drag a column heading back so that it completely obliterates another. On Mac/Linux, you still see a small fragment of remaining column with no text. But that's not a big thing, given refreshing the row in some way sets it back to default. > Would you have the (empty) Parameter column simply extend completely to the > right so that 4th "column" (really, just unused space) doesn't show? I think that would look better, like this (vlc on Windows): http://gaclrecords.org.uk/images/vlc_shortcuts.png But they use QT, I think. In short, we have three columns, so why show a redundant fourth? But don't lose sleep over it. If to do this we had to have a horizontal scrollbar even when no commands had parameters, that probably looks worse.
Created attachment 362 [details] Resizes final column to fit > Would you have the (empty) Parameter column simply extend completely to the > right so that 4th "column" (really, just unused space) doesn't show? The new patch (bug618-EditChain-fit-columns-3.patch) should do this hopefully on Windows as well as Linux. I've not attempted to implement this in Leland's Mac code so the behaviour will be noticeably different on Mac, but I think it should be fairly straightforward to extend to Mac (for someone that is able to test on Mac) if this is what we want.
>> Would you have the (empty) Parameter column simply extend completely to >> the right so that 4th "column" (really, just unused space) doesn't show? >The new patch (bug618-EditChain-fit-columns-3.patch) should do this hopefully > on Windows as well as Linux Thanks, Steve. On Windows there is now almost no apparent fourth column, just a thin faint border where you can hover to see the drag pointer and then drag rightwards so as to trigger the horizontal scrollbar. I'm inclined to think people with parameters that exceed the width of the third column will think this is worse, because the horizontal scrollbar now does not automatically appear in that case. To get the scrollbar and see all the parameters displayed in the row itself, you must realise there is a grab bar at the right of the third column (which is unexpected given there are only actually three active columns). Or you must realise the parameters have a tooltip. Resizing the window to right will not display the end of the parameters string but will expose the redundant fourth column. Is this as you see it on Linux, Steve? Is widgets not capable of realising there are only three columns, and tying the final column to the end of the window, as vlc does it? If not, much as I dislike seeing the fourth column when the parameters don't fill the column, I think that is more functional than Steve's patch.
(In reply to comment #16) This is why I didn't mark my previous patch as "obsolete". The "Resizes final column to fit" patch definitely looks neater than the previous patch (as per comment 14) but it is perhaps less functional. Personally, if I want a detailed view of the settings I'll bring up the effect interface, so the "parameters" column is little more than a guide that things are as expected. It would be good to close this satisfactorily so that it does not need to be revisited, so what is the design spec? Do we want the "Command" column to default to a little larger than the header (resizeable by the user) and the "Parameters" column to fill the available space unless the parameters require more space, in which case a scroll bar appear?
(In reply to comment #17) > Do we want the "Command" column to default to a little larger than the header > (resizeable by the user) and the "Parameters" column to fill the available > space unless the parameters require more space, in which case a scroll bar > appear? Basically yes, though it doesn't matter what method pushes the "Parameters" column to right just enough to hide its border with the fourth column. I'm guessing though that pushing "Parameters" that bit to right will introduce the scrollbar, as would happen now with HEAD. Personally I think having that redundant fourth column if the parameters don't fill the space (as in the previous patch) would be preferable to a permanent horizontal scrollbar where there is no "apparent" need for it. If you can do as in "Resizes final column to fit", leaving the border between columns 3 and 4 there sufficiently to prevent the scrollbar when parameters don't overflow, but still introduce the scrollbar when they do overflow, that would be OK, and I think better than any previous patch to date. . The real design spec IMO would be three columns not four, so that when you resize the window to right, this does exactly the same as dragging the border between columns 3 and 4 does now in "Resizes final column to fit" (i.e. as the user sees it, it resizes Column 3).
Created attachment 365 [details] bug618-EditChain-fit-columns-5.patch > The real design spec IMO would be three columns not four, The apparent "4th column" isn't actually a column (though it looks like one). The table is inside a kind of 'container box', and the apparent extra column on the right is how Widgets copes with space between the final column and the right edge of the container. > so that when you resize the window to right, this does exactly the same > as dragging the border between columns 3 and 4 does now in "Resizes final > column to fit" (i.e. as the user sees it, it resizes Column 3). If the Parameters will fit in the final column, I see no need to show the right hand edge of that column (i.e. there does not need to be any visible sign of a 4th column). It looks neater if the three columns fit exactly inside the 'container box'. If the parameters do not fit in the parameter column, then the parameter column needs to automatically resize so that the parameters fit, which will then require a scroll bar to appear. This new patch also handles resizing the window. (only tested on Linux). I've not attempted to implement this in Leland's Mac code so the behaviour will be noticeably different on Mac.
Hi Steve, This is the best yet on Windows and I suspect as good as it gets if Widgets insists on a final pseudo-column. The horizontal scrollbar appears when the row text overflows. Resizing the window to right doesn't make the fourth column visible (it just adds space to the end of the third column). Dragging the boundary between the third and fourth column rightwards does the same (click to right of the horizontal scrollbar to see the space). So the only way to see the fourth column AFAICT is to drag leftwards on any of the column boundaries. On Mac, if there are no parameters, columns 1 to 3 fill half the width and column 4 fills the rest of the width. Column four decreases in width as parameters increase the width of column 4 until the text overflows, then the horizontal scrollbar appears as expected.
(In reply to comment #20) > On Mac, if there are no parameters, columns 1 to 3 fill half the width and > column 4 fills the rest of the width. Column four decreases in width as > parameters increase the width of column 4 until the text overflows, then the > horizontal scrollbar appears as expected. Gale, Steve's patch works equally as well on the Mac. Just move the "#endif" in FitColumns() from its current location to just before the "int bestfit..." line. Third column will resize as it should. Leland
Created attachment 366 [details] applies Steve's column 3 fix to Mac as suggested by Leland
(In reply to comment #21) Leland wrote: > Just move the "#endif" in FitColumns() from its current location > to just before the "int bestfit..." line. Thanks, that works for me on Mac so attached that as latest patch. Is this OK for you Steve?
(In reply to comment #23) > Leland wrote: >> Just move the "#endif" in FitColumns() from its current location >> to just before the "int bestfit..." line. > Thanks, that works for me on Mac so attached that as latest patch. Is > this OK for you Steve? Yes. I thought that would be the case but was not able to test it myself.
Right then we have consensus and the same behaviour on all platforms, so marked as "patch_ready". Thanks Steve and Leland.
(In reply to comment #25) Leland, You, Gale, and Steve have approved this, so I don't see much reason for any other devs to start anew on it, follow it through, and re-endorse the whole thing. On quick scan, it's not clear to me whether both patches or only the latter need be applied, and I don't think it's a good use of my time to figure it out. 25 comments (some quite long) on a P4! Please use your developer commit privilege, Leland. Thanks!
Comment on attachment 359 [details] Workaround fixed header width on Mac This patch was not the final solution so marked obsolete
Committed r12254 and RESOLVED-FIXED (yes, perhaps only the patch now remaining should have been left up after marked "patch_ready", but if anyone did want to see it, it could end up a bit confusing if it had been obsoleted).
(In reply to comment #28) I note that the fix for this has increased cosiderablt the depth of the Edit Chains Window. Is this deliberate,is it to provide users with expansion space for additionla chains without vertical scrollbar or dragging the window to increase its size? I observed this (on W7) when I was about to update the image of the dialog for the Manual. Bearing in mind that the sole default supplied chain is the MP3 Conversion then the image will not look good on the page with so much empty space below the one chain. Is this what we really want?
(In reply to comment #29) As in the pre-patched code, the default size is set to 3/4 of the screen width and 4/5 of the screen height. This may not have actually happened on all platforms, but that is how it was designed (and I've not changed it). The minimum size is fixed to a minimum that the layout allows (about 800 x 300 pixels) So the actual size is dependent on screen size, but the minimum size is set by the layout and is platform dependent due to different borders. Whether to use a smaller size in the manual, or change the default sizes are really matters for the -manual and -QA mailing lists.
(In reply to comment #29) > I note that the fix for this has increased considerably the depth of the > Edit Chains Window. On Win 7 1024x768, the initialised width and height are identical pre- and post-patch. Are you sure there is a difference Peter if you remove your Chains folder from C:\Users\<your user name>\AppData\Roaming\Audacity then compare 2.0.3 and HEAD? The only difference I see is that in HEAD you now see a couple of letters less of the Normalise parameters.
(In reply to comment #31) Yes, I'm sure. I deleted the Chains folder as you suggested and the resultant dialog window is still larger both in width and depth. I uploaded the new image to the alpha manual, you can compare this with the previous image in the 1.2.3 manual: http://manual.audacityteam.org/man/Chains_-_for_batch_processing_and_effects_automation http://manual.audacityteam.org/o/man/edit_chains.html And compare the images in the images's history http://manual.audacityteam.org/man/File:Edit_chains_basic7.png
(In reply to comment #32) On a screen resolution of 1024x768, the Edit Chains window should be about 768x614 pixels. My screen resolution is 1366x768, so the window size should be 1366x3/4=1024 wide by 768x4/5=614 tall. The actual size is 1032x644 which is close enough allowing for borders and platform variations. The image that you have posted is 1024×614 which would indicate that wxWidgets thinks that your screen size is 1366x768 and not 1024x768. In any case, this part of the code has not been changed in this patch so I don't understand why there should be a difference. Are you sure that your monitor is 1024x768 and not (a wide-screen) 1266x768? Does the window fill the full screen width? Also, the previous image in the manual is clearly much smaller than it was designed to be on a 1024x768 monitor and I assume that it was manually resized as I doubt that the screenshot was taken on a monitor with a vertical resolution of only 360 pixels.
(In reply to comment #33) My screen size is 1366x768 (like yours) Curiously I now also get this larger dialog window (1024x614) in earlier versions of Audacity including 1.3 Beta - so I'm puzzled.
(In reply to comment #34) Peter, there is no issue here. The dialogue width is not hard-coded but proportional to resolution width. The dialogue is 768 px wide on a 1024x768 monitor both before and after Steve's patch. On a 1366x768 monitor (your current resolution) the dialogue will be 1024 px wide (and so your image was 1024 px wide). > Curiously I now also get this larger dialog window (1024x614) in earlier > versions of Audacity including 1.3 Beta - so I'm puzzled.. If you got 768 px wide before then it was because you were looking at it on a 1024x768 monitor.
