Various Updates - 'o' to toggle options dialog, smaller 'default' notification, color/layout tweaks, ^L to redraw screen

[apocalyptech]

These are a whole bunch of tweaks to how pacmixer's TUI looks; mostly it's just layout/coloring changes, though I've also added in a new key (to toggle the options selections), and fixed a bug. I'm sure that much of this is down to personal preference, re: the layout, so if you like some of these but not all, I'd be happy to pull it apart a bit and get a smaller pull request together.

Anyway, here's what I've added to the project's changelog:

• Tweaked colors to be closer to alsamixer.
• Force terminal background color to be black.
• Added "OO/MM" mute labels, as alsamixer does.
• Collapse "default" notification to a single line, below the channel name, and leave room for it whether the channel supports it or not.
• Added o keybinding to toggle display of control options.
• Added numeric channel level indicator, as alsamixer does (currently this will only ever show the first two channels per control).
• Fix settings dialogs when options are turned off.
• Add ^L hotkey to redraw screen, useful if some cruft gets left on the screen.

Most of what I changed is apparent from a simple screenshot, so here's how it looks without the options dialogs showing:

... and here it is with the options dialogs:

As I say, personally I like how my tweaked version looks (and it's closer to how alsamixer looks), but I'd certainly understand if there's lots of bits in here that you don't actually want to merge.

Thanks for the app, btw! I'd always felt that not having an alsamixeralike for PulseAudio was one of its biggest weaknesses, so I was thrilled to stumble upon this.

[KenjiTakahashi]

Hey, thank you for taking interest in the project and sorry for such a late response!

Now, onto the point :-]. I have not looked at the code yet, but I'll comment on the changes you described and how I think about them.

• Apps should not force background colour. If user uses light bg, app should use light bg too and look good. Same for dark bg. If it doesn't that should be fixed. Could you please tell me what terminal and colour theme you use? I'd have a look at what could be wrong. BTW: I plan to have colours configurable later. See more at the end of the comment.
• OO/MM I deliberately left out. On practical side, they were added mostly for terminals with no colour, but pacmixer wouldn't work fine on them anyway and I don't like them visually :-).
• The Def. thing actually looks nice. I was kinda opposed at first, but it is more clear than a green/red block. Also takes less space, which is good. What I'd probably change is to move it above the name. Names, IMHO, act as a nice "line" that separates controls from the bottom status.
• The o binding, well, doesn't hurt, I guess ;-).
• Numeric channel values are tricky thing. The longest standing issue in my resume (and shame on me). The problem is, of course, that there can be more than 2 channels. In fact, the standard says that a single control can have up to 32 channels, AFAIR. I'm yet to find a way to visualise it in a (at least semi-) practical way. But I'd like to support this.
• Screen corruption should ideally not happen :-), but again, a binding doesn't hurt.

FYI: The ongoing development of pacmixer is kinda on hold now. That's because I'm trying to get out of the Objective-C fiasco, so I'm working on a little "framework" that will help me make this move, make implementing and controlling widgets easier and make everything more configurable (like colours, hiding/showing things, layouting, etc.). This will probably take some time, as I unfortunately don't have much of it to work on this...

[apocalyptech]

No worries! Only so many hours in the day, etc.

I shall comment on a couple of your comments!

• Yeah, you're right - forcing background is a bad idea. In the absence of fully user-controllable colors, perhaps it'd make sense to support a CLI argument for whether the mixer's being run with a dark or light background, to adjust the colors to suit. I could poke at that later when I'm back (I'm out of the country for awhile at the moment)
• Yeah, I'd struggled a bit with how to handle >2 channels with numeric values, and as you can see, in the end for my own purposes I decided to just stick my head in the sand and blindly only draw up to two of them. :) I have no magic solutions up my sleeve for that!

Anyway, no worries re: development! I've got a long list of personal projects on hold, so I get it. I'll look over this stuff again more thoroughly when I'm back, though!

Thanks, CJ