expand on Norm's new track name in display

[steve]

(Copied from my e-mail to you Ed)

The patch works fine on my machine (Debian Squeeze).

I agree that yellow or orange are the most clearly visible and much
better than black.
I find that the (not patched) font size is a bit too small. 12 pt is a
lot better on my display.

I think there are pros and cons regarding the buttons using the
selected font and colour. On the one hand it provides immediate
feedback as to the font and colour that are selected, but on the other
hand the button text is hard to read when it is yellow, and over sized
buttons are not very nice. Also, because of the pale button colour it
tends to give a slightly misleading idea of what the colour will
actually look like against the background of a waveform. The benefit,
while it is pretty and clever, is not very important imho (I am able
to remember what colour I selected for more than 5 seconds :=) so on
balance I think I'd prefer normal size black text buttons (but
everything else in this patch exactly as it is now).

Colour and font size choice are both a very significant improvement to
the wave track text feature imo. Nice work Ed.

[Edgar]

After some QA review...
*default text color to yellow (255, 255, 0) & size to 11]
*in my preferred version the buttons inherit the user's choice of font/size/color so make one button's background color the same as a selected wavetrack's background color and the other button's background color the same as an unselected wavetrack's background color:

sizeColorFamily10-ed.patch

(8.58 KiB) Downloaded 137 times

*others prefer that there is no feedback via button text's font/size/color:

sizeColorFamily10.patch

(6.88 KiB) Downloaded 134 times

note that I have shortened the patch's name but retained the numbering scheme

I strongly believe that good GUI design requires that the user's choice of font/size/color should have "feedback"! How else can the user decide if the color scheme works? By resizing/recolorizing the buttons the user can tell at a glance if the font choice is appropriate (especially if the buttons are too big to fit--user knows the font is too big). If changing the buttons is deemed bad another solution would be to draw a tiny portion of a simulated track with the user's choice depicted. This would probably require a lot more room than we currently have available in the dialog.

[steve]

sizeColorFamily10.patch

Is this still on-going?
If so, which checkout revision do I need? (the patch fails against revision 11462).

I strongly believe that good GUI design requires that the user's choice of font/size/color should have "feedback"

I totally agree, but (on Linux) I could see the font, size and colour in the "picker" dialogues and did not feel that I needed any more "feedback" than that.

[Edgar]

sizeColorFamily10.patch

Is this still on-going?
If so, which checkout revision do I need? (the patch fails against revision 11462).

"on-going"--we don' need no steeking "on-going"! <big grin>
Given the Developer's decision to reject my design concept (much less my patch) on the grounds that it is too little, too late (Martyn wants an elegant, exhaustive themeing solution which could include the concept of font family/size/color and could extend such to this text), and given that my patch conflicts with the recent additions of "yellow" and extending the concept to the other wavetrack views, and given that I think patch 10 is sufficient for both Linux & Windows (but untested on Mac), "Sorry, no". You will need to apply the patch manually unless I have some excuse to create a new version against SVN HEAD.

I strongly believe that good GUI design requires that the user's choice of font/size/color should have "feedback"

I totally agree, but (on Linux) I could see the font, size and colour in the "picker" dialogues and did not feel that I needed any more "feedback" than that.

On Windows color is not perfectly represented due to anti-alias artifacts (the background color of the wavetrack influences this). That is why on 10-ed I added (among others) these lines:

Code: Select all

            wxColor unSelectedBackground(214, 214, 214);//2.0 default wavetrack unselected background color
            mGetFontButton->SetBackgroundColour(unSelectedBackground);
            wxColor selectedBackground(148, 148, 170);//2.0 default wavetrack selected background color
            mGetFontColorButton->SetBackgroundColour(selectedBackground);

The colors were based on current hard-coded values set elsewhere and more properly should be derived from those variables.

[steve]

You will need to apply the patch manually

Possibly a bit too tricky for me as I'm not sure what in the current svn Head conflicts with your patch.
If you can tell me the revision number that the patch was created against, then I know how to "roll back" my svn copy to that version.
I'd be interested in seeing how these two patches behave, because I get a feeling that the "name in display" question is not over yet.

[Edgar]

You will need to apply the patch manually

Possibly a bit too tricky for me

I have some errands to do today but after "a while" (today sometime) I will post an 11-ed patch against SVN HEAD as of that time.

[Edgar]

I added the SVN version to the name. I made one cosmetic change from 10 as suggested by Gale on -devel:
http://audacity.238276.n2.nabble.com/Sh ... l#a7259141
although my wording differs slightly:

newWording.png (3.53 KiB) Viewed 5831 times

sizeColorFamily11-edR11463.patch

(8.58 KiB) Downloaded 139 times

note that I now have a "Track Name Display" (static) group; this is because I personally now have more such groups (Beep & Rest Prefs) although this patch 11 does not present the code:

beepANDreset.png (22.38 KiB) Viewed 5831 times

wording is out-of-date.

[steve]

Unfortunately I'm getting a segmentation fault when I try to use the feature.
Perhaps you could tell me, is the background colour of the "Font" button the same as the background colour of a "not selected" empty audio track and the background color of the "Color" button the same as a selected, empty audio track? If so, then I think that is a good idea.

Regarding the font size I'd still prefer the button text to not change size. I don't think that it's necessary and it looks peculiar.

Regarding the "cosmetic change", would "Show name in audio track display" be better?

[steve]

Just a thought, how hard is it to add just a "Font Size" selector rather than the Font picker?
I think that being able to select the Font Size and colour are by far the most important additional features and will probably "sell" to the developers on the grounds of accessibility.

[Edgar]

Unfortunately I'm getting a segmentation fault when I try to use the feature.

I cannot get a stable Squeeze build of default Audacity but will try again (but probably not 'til tomorrow).

Perhaps you could tell me, is the background colour of the "Font" button the same as the background colour of a "not selected" empty audio track and the background color of the "Color" button the same as a selected, empty audio track? If so, then I think that is a good idea.

Yes, that is the color feedback.

Regarding the font size I'd still prefer the button text to not change size. I don't think that it's necessary and it looks peculiar.

For testing, removing that feature requires commenting out a few lines in /src/prefs/GUIPrefs.cpp (I am not sure of the line numbers) in function
void GUIPrefs::OnFontDialogButton(wxCommandEvent & e)
at the very end:

Code: Select all

      mGetFontButton->SetFont(fontData.GetChosenFont());
      mGetFontColorButton->SetForegroundColour(fontColor);
      mGetFontColorButton->SetFont(fontData.GetChosenFont());
      wxSize size = mGetFontButton->GetBestSize();
      mGetFontButton->SetSize(size);
      size = mGetFontColorButton->GetBestSize();
      mGetFontColorButton->SetSize(size);

becomes:

Code: Select all

      //mGetFontButton->SetFont(fontData.GetChosenFont());
      mGetFontColorButton->SetForegroundColour(fontColor);
      //mGetFontColorButton->SetFont(fontData.GetChosenFont());
      //wxSize size = mGetFontButton->GetBestSize();
      //mGetFontButton->SetSize(size);
      //size = mGetFontColorButton->GetBestSize();
     /// mGetFontColorButton->SetSize(size);

Remember, if you do this you not only loose the feedback for size but also family.

Regarding the "cosmetic change", would "Show name in audio track display" be better?

Yep. I changed my local version of 11 to reflect that--did not think it work bumping the patch number:
S.TieCheckBox(_("&Show name in audio track display"),