configuring the GUI

This is a spinoff from the “bigger fonts” thread. Personally, I’m not really happy with the experimental Themeing so for my own personal version of Audacity I have started adding the ability to configure some of the GUI. I am most interested in fonts and specific interface item colors. Obviously, this will require some kind of an interface for the user’s preferences; here is what mine looks like so far:
prefs.png
I have added a new section (see the bright green box) to the “Interface” page; currently there are five sets of controls (eventually I will do a better job of rearranging these into appropriately labeled sections). The first set of controls exposes the existing ability to play a custom “Beep” at the end of time-consuming operations.

The next set of controls (see the bright blue box and arrow) allows the user to modify the font (family, size and color) of the text display of the track name in the waveform track panel; I have also expanded this text display ability to all the other things which might be drawn in a track panel (MIDI, spectrogram etc.).

Next comes a control (see the orange box and arrow) which allows the user to toggle the “Snap To” control so that it is disabled (or not) at startup. Since the “Snap To” behavior can also be controlled via keyboard shortcuts, this on screen widget is not absolutely required.

Next is a control (see the green box and arrow) which allows the user to adjust the font size in the Selection toolbar and all Time Text Controls; since there are a number of different fonts used in this toolbar I went with a percentage of the current default (which is defined in the code as a “minimum” and is nine points). If …the user sets this to 100 the default behavior will be maintained, larger values will result in bigger fonts and a taller Selection toolbar (I have not tested with values smaller than 100 – that is left as an exercise for the student).

Finally there is a pair of controls (both of which perform the same identical function; see the red box and arrow) which allows the user to change the color of the “zero” line which is drawn in the waveform.

I realize that this is a bit clunky and offered only as a proof of concept.

Regarding the “track name display” (as the feature in this group that is currently, partially, implemented).
When you first introduced that feature I think there were some cross platform issues regarding making the colour selectable. Can they be resolved?
The yellow colour shows up well against the blue waveform, but less well against a grey background if the waveform is small, so configurable colour for that text would certainly be beneficial.

Also there seems to be a bug in the current implementation of track names in waveform display. This shows up most clearly if there is a label track with audio tracks above and below the label track. Those above the label track have yellow text and those below the label track have black text. In some cases the colours will change between yellow and black when scrolling vertically.

I’ve not put this on bugzilla yet, but I was wondering if you have any idea what the problem might be or how to fix it.

(this issue was originally raised here: https://forum.audacityteam.org/t/displaying-long-track-names/27266/4)

See my reply in the “long track names” thread. The only cross-platform issue is that both Linux and Windows have “rich” font pickers (under wxWidgets 2.8.12) and Mac does not. If only a color picker control was added I don’t think there were any cross-platform issues, but back then Gale did not have a Mac on which to compile so we had no one who could test that.

I really do understand the drawbacks of adding user choice to some of the GUI elements. Audacity is a very mature application and was originally never designed to give the user any control of the GUI. To do this right would require ripping out all of the experimental theming code as well as changing the current reuse of defined GUI colors – e.g. there are three grays Dark, Medium and Light all of which are shared by disparate GUI elements. Here is an example:
a.png
Note that the grabbers on the toolbars and the background color of the horizontal ruler would normally be one of the grays, but it is easy to override that.

(BTW, the colors I chose above were more for demonstration then because I like them. I do like the green on the grabbers. What I am trying to achieve in the horizontal ruler is enough contrast so that I can read the numbers; I have not figured out how to affect the font of the numbers quite yet.

I also found tucked away in the code that someone along time back (whoever wrote the Time Track code) wrote that code with a user interface so that the user could control the size, family and style of the font. Unfortunately, there was no interface written to do so. To implement the interface requires 10 or 15 lines of code but adds new control to Preferences which the Developers have decided is unacceptable.

The reluctance of the devs to add to Preferences is an ongoing problem - not restricted to the functionality under discussion in this thread.

Enriching the capabilities of Audacity will often call for additional Prefs to control and manage behaviour - it just goes with the territory …

In my ongoing exploration of the GUI I investigated one of my pet peeves – the discoverability of the sizers on those toolbars which have them.
Sizer.png
Currently the Sizer is 4 pixels wide and delineated by a dark gray vertical line on each side. I tried just recoloring it but found no color combination that would make it stand out enough to suit my desires. What I found was that if I made it 5 (or even 7) pixels wide and used a very saturated color it stood out better. Making it an odd number of pixels wide allows us to have additional vertical lines.

I did find a trivial bug in the code during this investigation. In the file:
srctoolbarsToolBar.cpp
at or near line number 69:

// Width of the resize grab area
//
#define RWIDTH 5//efm5 debug was 4

the width of the Sizer is defined; everywhere in the code which uses this value the defined (RWIDTH) value is used except for one place; at or near line number 594:

AColor::Line(dc, sz.x - RWIDTH,  0, sz.x - RWIDTH, sz.y );//efm5 RWIDTH was hardcoded to 4 here

the value was hardcoded as “4” (the #define was not used).

The next chapter…controlling the drawing colors:
ap.png
The above image came from an early “proof of concept”; I now have many of the other drawing pens under control. There are enough of them that they will require a separate page in Preferences I am going to call it “Drawing Colors” and insert it immediately after Interface.

Notice the items set off in red; a long while back we talked about adding some controls for the Pan and Gain sliders. I now have a Preferences item for each which controls whether or not they are disabled at start up. I also have added a “toggle” in Track Info’s drop-down menu for each of them so that they may also be controlled on-the-fly.

I’m interested - is this all leading somewhere?
What have you done with the old theming code? Is that still there? Are you using it? Are you working around it?
Your configurations are becoming quite extensive. Configuring the GUI in such detail would probably be a niche interest (though probably quite a large niche). I’m wondering, do “preferences” all need to be in the Preferences menu? Could there just be a file (audacity-gui.cfg) to define all of these settings without the “bloat” to the Preferences menu that the developers are so keen to avoid?

On Linux there is a program called “GConf” that provides access to hundreds of “preferences” for the Gnome Desktop that the developers did not want to include in the standard set-up options. There is also a GUI interface for GConf:
gconf.png

Leading somewhere? Probably not. Worst case, I am exploring the code, keeping my mind honed and gratifying my own desires; best case, I will get others interested in the concept and a discussion going about how to do it “right”.

As far as the old theming code, it is all still there, I am not using it but working around it; most of it is wrapped up in #defines which, by default, are not defined.

Quite extensive – you ain’t seen nothing yet! As far as “do preferences all need to be in preferences”, it would seem to me that is self answering and obvious – of course they do. I realize that the Developers are loath to add anything to preferences but that is their problem.

I will keep extending my personal copy of Audacity and posting screenshots.

A long time ago, in a wiki far far away, Gale complained about the current color of the Snap Guideline color (bright yellow):
old.png
Note that when viewed against some of the interface colors it is next to impossible to see. I have added new preference:
prefs.png
I may now modify that color:
new.png
Given that I may now modify the colors of the selected an unselected background behind the wave and the colors of the wave itself*, I may now achieve something that is much more visible.

*Still to do – add color picker buttons for both of the wave colors; the underlying code is already in place.

More progress…
track.png
I am not suggesting that these particular colors are for everyone! However, they do work well for me visually.

I think that it is an “unintended feature” that the Label Track’s track info panel background color (which I have not messed with) inherits the same default color as the background of the Time Track. I suspect that the original intention was that it inherit the same color as that of a Wavetrack’s track info panel’s background color.There are a number of “defined”/named colors in the Theme which share exactly the same value of gray – these named colors seem to of been used somewhat “randomly” without thought continuity.

and now the Preferences interface…
This is the current Interface page extended to allow some control of “Behaviors”:
interface.png
This is a new page which allows control over some of the colors:
interface colors.png
Oh yeah, in case you’re just joining my little interface party…
resized preferences.png
a long time ago I changed the Preferences dialogs so that they were resizable, their minimum size was useful and that their maximum size was 90% of the screen’s size. This allows the built-in layout mechanism (ShuttleGUI) free reign in designing each dialogue. Unfortunately, I have yet to figure out how to add sliders to all of the layouts when required; I have it mostly working but it’s still a bit ugly.

In my never-ending quest to make things more legible…
aPic.png
I spent some time tearing apart the timeline; unfortunately, from a GUI standpoint, it shares a lot of code with a number of unrelated GUI items. Is called an “Adorned Ruler” and can be either horizontal (as the timeline) or vertical (as the Vertical Scale between the Track Info Panel and the Wavetrack); it is also used to draw the scales on the edges of graphs and meters.it has a default text font, text color, background color, selected background color, and tick color. Almost every GUI usage other than the timeline overrides these defaults to one extent or another. Here is a close-up example of its use labeling a graph:
zPic.png
A close inspection will reveal that the text color is now a dark blue instead of black. You can see this is used in the timeline, the vertical ruler, the labeling of the graph and also the meters in the toolbar.

Once again, I am not necessarily suggesting that the colors, fonts and sizes depicted herein are necessarily “good” or even “better than the default”, they are used mainly here to make a visual distinction.

This should be the last picture for this cycle:
side-bt-side.png
this is a side-by-side view–mine to the left, current on the right. My final attention was to be Preferences dialog. Notice that it now has horizontal and vertical scrollbars (when needed). Also notice that the size and color of the font is user controlled. One item which may not be pictorially depicted – the Preferences dialog now remembers its size and location.

I am trying to determine how to affect the font in tips (when you hover the mouse over something). From what I can determine this is probably not adjustable.