Display label count

[Edgar]

OK then the default label track height "could" be higher, but arguably the default is too high now. Accommodating two labels stacked above each other ought to be enough for the default height, shouldn't it? I am always having to reduce the label track height so I can see all the tracks without scrolling up and down.

FYI, in srcLabelTrack.cpp near line number 99:

Code: Select all

   // Label tracks are narrow
   // Default is to allow two rows so that new users get the
   // idea that labels can 'stack' when they would overlap.

Your argument bears water; from the above it is clear that the Developers tried to design the default height to be as short as possible and still completely expose 2 stacked labels. There is quite a bit of wasted space:

spacing.png (1.27 KiB) Viewed 1747 times

In the above image I drew in the three red diagonal lines so that it would be easy to count pixels; above the top label is a four pixel gap, this could certainly be smaller though probably nonzero; between the two labels is a five pixel gap, again, this could certainly be smaller and also probably be nonzero; most wasteful, blow the bottom label is a 15 pixel gap, this almost surely could be smaller but again nonzero.

I'm not going to bother to dig into the code unless Steve (Linux) & Gale (Windows) (do we have a beta tester – Bill? – compiling Mac) are willing to try a patch-of-discovery which allows the user to control these three gaps on-the-fly so that they may inspect the various sizing implications. Personally, given that I run at very high resolution, I would start with three pixel spacing for all three gaps but would expect that 1 pixel top and bottom and 2 pixels in between would give us the tightest acceptable values. Shall I prepare such a patch against SVN HEAD? If we were to settle on a consensus I would be willing to prepare a patch for consideration.

[Edgar]

I still need to get uncomfortably close to a 19 inch screen to read 12 point.

If so there must be the same issue with the Audio Track info text and other static text, and the correct solution must surely be to fix that globally, not piecemeal fashion for label tracks only.

There are a number of considerations in defining "the correct solution". First and foremost – IMHO, there is no way that a single font (family, size & style) would be appropriate EVERYWHERE in the GUI. wxWidgets 2.8 does not give developers complete control of every widget's font (e.g. tooltips have no SetFont method). A lot of the GUI is built on wxWidgets Sizers and these are fairly easy to make font/language localization sensitive (grow or shrink to accommodate the string height & width); this is especially true if it is possible to use scrollbars on the Sizer and/or allow the user to manually drag it larger or smaller.

As you know, I provide a highly customizable version of Audacity. With the exception of tooltips it gives the user control of most of the common " things' " font, automatically resizing the appropriate Sizer to accommodate the font & localization. Is my belief that this is the only practical solution. As an example of another app which provides a similar user experience, take a look at any of the recent Microsoft Visual Studios; Tools> Options> Fonts and Colors gives access to preferences which allows the user to set the font (family & size, not style) individually for almost everything – text editing default (the user can use <ctrl+scroll wheel> to override size locally and non-stickyly), Find Results window, Output window, Breakpoints window etc.

Part of my solution is to get the current screen size, allow dialogs to be sized automatically to accommodate the font & language (up to 80% of the screen's height and width), allow the user to resize the dialog and to provide either or both horizontal & vertical scrollers as needed:

scrollers.png (27.82 KiB) Viewed 1747 times

[Edgar]

IMO you simply won't get the enhancement in if it requires extending the main Preferences. Meter Preferences is a case in point where .cfg settings are not activated in the main Preferences.

The Developers are leaning more towards extending Preferences; within the last couple of days Vaughan specifically said he was OK with doing this. However, I'm not proud, if QA can settle on a specification I will craft a matching patch.

[Gale Andrews]

Perhaps it would be acceptable to abbreviate Pt: Reg: Invis: or similar? We already use L and R as abbreviation for Left and Right.

There's not a problem with "Point" or "Region" (at least in English). The problem is with "behind zero" being rather too long.
If it can be printed reliably, how about (with some fictitious values):

Point: 1
Region: 17
←0.0 : 1

I'm not sure that representation of Behind Zero will be understandable to all, especially if they don't have any tracks behind zero.

Other ideas could be "Hidden" or "Pre Zero".

That might argue for having the label info off by default. If label info is switched on, then the default height could be increased to accommodate the info.

So a smaller default height when label track info is off, and a tiny bit higher when info is on? That sounds good to me.

Yes, removing some of the vertical padding that Ed refers to.

Gale

[Gale Andrews]

OK then the default label track height "could" be higher, but arguably the default is too high now. Accommodating two labels stacked above each other ought to be enough for the default height, shouldn't it? I am always having to reduce the label track height so I can see all the tracks without scrolling up and down.

FYI, in srcLabelTrack.cpp near line number 99:

Code: Select all

   // Label tracks are narrow
   // Default is to allow two rows so that new users get the
   // idea that labels can 'stack' when they would overlap.

Your argument bears water; from the above it is clear that the Developers tried to design the default height to be as short as possible and still completely expose 2 stacked labels. There is quite a bit of wasted space:

spacing.png

In the above image I drew in the three red diagonal lines so that it would be easy to count pixels; above the top label is a four pixel gap, this could certainly be smaller though probably nonzero; between the two labels is a five pixel gap, again, this could certainly be smaller and also probably be nonzero; most wasteful, blow the bottom label is a 15 pixel gap, this almost surely could be smaller but again nonzero.

I'm not going to bother to dig into the code unless Steve (Linux) & Gale (Windows) (do we have a beta tester – Bill? – compiling Mac) are willing to try a patch-of-discovery which allows the user to control these three gaps on-the-fly so that they may inspect the various sizing implications. Personally, given that I run at very high resolution, I would start with three pixel spacing for all three gaps but would expect that 1 pixel top and bottom and 2 pixels in between would give us the tightest acceptable values. Shall I prepare such a patch against SVN HEAD? If we were to settle on a consensus I would be willing to prepare a patch for consideration.

I am not sure if Bill has got building on Mac working yet, if not I can test on Mac as well as Windows.

Obviously if people want very large label font they won't get two labels stacked now, let alone if we reduce the height of label-track-without-info. I think we can only make it look reasonable (less vertical padding than now) with two labels stacked with default font size.

Does anyone feel we should count overlapped labels? That would be a long word, and I'm not sure if we would want the extra height that would be caused when the info is on.

The Developers are leaning more towards extending Preferences; within the last couple of days Vaughan specifically said he was OK with doing this.

I have not read the context in which he said that yet, but for the way I would use this feature I would find it much easier to toggle from the Label Track menu.

Gale

[steve]

Other ideas could be "Hidden" or "Pre Zero".

"Pre Zero" could be OK.
"Hidden" is too ambiguous because it could refer to stacked labels that are hidden due to the track height.

[Edgar]

Thanks to Steve for creating a bare-bones Proposal page:
http://wiki.audacityteam.org/wiki/Propo ... Track_Info
I have filled it out as well as I can for now. In the section for Developer/QA support I only included first names; please append your last name if you so desire (Gale, Peter, Steve).

Can we describe a bare-bones feature set? If so, I will craft the patch.

[Edgar]

I've put a patch for what I think of as a bare-bones implementation of this on the wiki Proposal page. It adds three new checkmark menu items to the Label Track's Track Info Panel's drop-down menu. These give the user control over the preferences for turning the three count displays on/off.

[Robert J. H.]

Hi Edgar,
I'm just trying to make the Label tracks more accessible to screen readers.
It works somewhat but the main problem is that all tracks appear the same.
I can't tell if a label track or a audio track has focus.
That's a typical description for a track--just a row of the track panel window in fact:

Code: Select all

INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (20:15:25):
Developer info for navigator object:
name: u'Track 9 Select On'
role: ROLE_TABLEROW
states: STATE_FOCUSABLE, STATE_SELECTABLE, STATE_FOCUSED, STATE_SELECTED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.IAccessible.IAccessible object at 0x0AEE2A50>
Python class mro: (<class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: None
location: (4, 839, 1256, 69)
value: None
appModule: <'audacity' (appName u'audacity', process ID 14400) at address 56d7d50>
appModule.productName: u'Audacityxae'
appModule.productVersion: u'2,0,7,0'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 8981322
windowClassName: u'wxWindowClassNR'
windowControlID: 1003
windowStyle: 1375731712
windowThreadID: 14416
windowText: u'Track Panel'
displayText: u''
IAccessibleObject: <POINTER(IAccessible) ptr=0x6253c40 at ae75670>
IAccessibleChildID: 9
IAccessible event parameters: windowHandle=8981322, objectID=-4, childID=9
IAccessible accName: u'Track 9 Select On'
IAccessible accRole: ROLE_SYSTEM_ROW
IAccessible accState: STATE_SYSTEM_SELECTABLE, STATE_SYSTEM_SELECTED, STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (3145734)
IAccessible accDescription: None
IAccessible accValue: exception: (-2147024809, 'Falscher Parameter.', (None, None, None, 0, None))

I wonder if one of the bare properties could be filled with your label info string (such as the IAccessibleDescription which is normally filled with the tool tip text)
My current way of discrimination is very crude: I have to examine the context menu with regard to 'Font...'--if found, the focus is on a label track.

Thank you

[Edgar]

I'm just trying to make the Label tracks more accessible to screen readers.
[…]
typical description for a track

Code: Select all

[…]
Developer info for navigator object:
name: u'Track 9 Select On'
role: ROLE_TABLEROW
states: STATE_FOCUSABLE, STATE_SELECTABLE, STATE_FOCUSED, STATE_SELECTED
isFocusable: True
[…]

I wonder if one of the bare properties could be filled with your label info string (such as the IAccessibleDescription which is normally filled with the tool tip text)
My current way of discrimination is very crude: I have to examine the context menu with regard to 'Font...'--if found, the focus is on a label track.

I'm at a bit of a loss here, screen readers are something of which I know absolutely nothing! If you're willing to do a little handholding I'll see what we can do.

First, in the code that you show you have some variables like:

Code: Select all

windowText: u'Track Panel'
displayText: u''
IAccessible accName: u'Track 9 Select On'

Can we add another variable? Maybe:
readThis: u''
If so, we should probably be able to fill that with a compounded string which included whichever of the counts the user is displaying.
If not, do I understand correctly that: 1) there is no tooltip; 2) within the Audacity source code we can fill that variable (IAccessibleDescription) with our compounded string; 3) the result would be read appropriately by a screen reader?

Tracks know which kind they are. How does the screen reader dig the information out of the Track class? Obviously somewhere within the screen reader code Is something which vaguely resembles:
IAccessibleString accName = track.GetName()
We need a new variable or two:
IAccessibleInt type = track.GetType()
IAccessibleString readThis = track.GetPointsString()
(Note - I just made up those variable types and Track accessor functions.)

I have absolutely no idea how to accomplish any of this!