Hello,

I've been converting myself over to console applications when possible
now. I think it has a sleek look, and it ought to reduce my overhead.

So on my mutlimedia workspace, I'd considered running a nearly full
screen terminal of alsamixer with a command line music player in a
smaller terminal that is normally on top.

However, for my pseduo-transparent terminals, this was a major eyesore
to have a solid black background for alsamixer. Before I investigated
other mixer option, google fu could produce a patch for alsa-utils to
make alsamixer run transparent.

So, with this patch in hand, then I could easily make a local overlay
of alsa-utils, patch the ebuild, and get my desired result.

The patch isn't for the latest ~x86 alsa-utils, so I may need to tweak
it for more recent versions.

My question is if anyone is going to accept this as a reasonable
"feature" addition to alsa-mixer on the main portage tree. I assume
perhaps not, but I can't really see almost any advantage of the forced
black background. If you want a black background, I say run the
terminal that way.

I didn't make the patch, so I have no intention to take the credit
myself, but I didn't want to look like a dunce on bugzilla, but I've
never submitted a feature request that didn't make me look like a
dunce, hence polling opinion here.

You can see the patch below.

In any case, of course ebuild patching >> plugins

~daid

This idea came from
https://www.prof-maad.org/blog/2009/11/11/transparent-alsamixer/ (and
the website had some apparent security issues the other week when I
found this, just fyi).

daid@flux /usr/local/portage/media-sound/alsa-utils/files $ cat
alsa-utils-1.0.20-transparency.patch
--- alsa-utils-1.0.20/alsamixer/alsamixer.c 2009-05-06 15:07:24.000000000 +0800
+++ alsa-utils-1.0.20-profmaad1/alsamixer/alsamixer.c 2009-11-11
21:33:14.242278621 +0800
@@ -150,7 +150,7 @@
#define MIXER_CBAR_STD_HGT (10)
#define MIXER_MIN_Y (MIXER_TEXT_Y + 6) /* abs minimum: 16 */

-#define MIXER_BLACK (COLOR_BLACK)
+#define MIXER_BLACK (-1)
#define MIXER_DARK_RED (COLOR_RED)
#define MIXER_RED (COLOR_RED | A_BOLD)
#define MIXER_GREEN (COLOR_GREEN | A_BOLD)
@@ -320,7 +320,9 @@
dc_fg[n] = f;
dc_attrib[n] = a;
dc_char[n] = c;
- if (n > 0)
+ if(b==-1)
+ init_pair (n, dc_fg[n] & 0xf, b);
+ else if (n > 0)
init_pair (n, dc_fg[n] & 0xf, b & 0x0f);
}

@@ -339,6 +341,7 @@
mixer_init_draw_contexts (void)
{
start_color ();
+ use_default_colors();

mixer_init_dc ('.', DC_BACK, MIXER_WHITE, MIXER_BLACK, A_NORMAL);
mixer_init_dc ('.', DC_TEXT, MIXER_YELLOW, MIXER_BLACK, A_BOLD);

On 26 Feb 2010, at 12:19, daid kahl wrote:

...
My question is if anyone is going to accept this as a reasonable
"feature" addition to alsa-mixer on the main portage tree. I assume
perhaps not, but I can't really see almost any advantage of the forced
black background. If you want a black background, I say run the
terminal that way.

I didn't make the patch, so I have no intention to take the credit
myself, but I didn't want to look like a dunce on bugzilla, but I've
never submitted a feature request that didn't make me look like a
dunce, hence polling opinion here.
...
https://www.prof-maad.org/blog/2009/11/11/transparent-alsamixer/


The first thing I would do is contact upstream (their -dev mailing
list?) and ask if they're aware of the patch. If know about it, but
refuse to integrate it they may be able to give a good reason.


Stroller.