[gentoo-user] alsamixer transparent, should submit feature to bugzilla?

2010-02-26 Thread daid kahl
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).

d...@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.0 
+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)
 #defineMIXER_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);



Re: [gentoo-user] alsamixer transparent, should submit feature to bugzilla?

2010-02-26 Thread Stroller


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.