9fda6b107a
Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
119 lines
6.2 KiB
Plaintext
119 lines
6.2 KiB
Plaintext
3.5 NEWS:
|
|
Fixed link failure with GCC 10.
|
|
Fixed some typo's.
|
|
|
|
3.4 NEWS:
|
|
Call `XSetCommand()`.
|
|
Added autogen and .gitignore.
|
|
Update mailing list links to new Google Groups.
|
|
|
|
3.3 NEWS:
|
|
Remove trailing whitespace.
|
|
Fix a buffer overflow (how did this ever work?)
|
|
Add native ALSA mixer support
|
|
Improve the osd update code
|
|
- More logical relationship between volume level and bar length
|
|
- No unnecessary drawing
|
|
- Volume bar shrinks properly even when volume is lowered very quickly
|
|
Draw osd only on the primary monitor if randr extensions are available
|
|
Add a command line option for choosing a monitor for osd display
|
|
Improve monitor selection code
|
|
- Default to monitor 0 instead of failing if a crazy number is given
|
|
- Allow monitor to be specified by osdmonitor in the config file
|
|
Better handling of configuration defaults for the new settings
|
|
Allow sound api to be specified in the config file
|
|
Use autotools for build.
|
|
Add desktop entry file.
|
|
|
|
3.2 NEWS:
|
|
Added support for volume control keys found on all modern keyboards.
|
|
Added plenty of information to the man page on invocation and configuration.
|
|
Made wmix more verbose when something is not right in the configuration.
|
|
|
|
3.1 NEWS:
|
|
Fixed a 3 years old bug about volume level showing up as "0" when it's
|
|
actually set to 10. Thank to all 20 or so people who e-mailed me about this.
|
|
Changed struct mixer_info name to allow compiling wmix under 2.6.1+ kernels.
|
|
Thanks Neil Burch <burch@cs.ualberta.ca> for the patch.
|
|
Added a patch to enable exclusion of channels from display - allows you to
|
|
remove mixer channels you never use. adds '-e <channame>' command line option
|
|
which can be repeated any number of times. Thanks to Nicolas Descomps <nico_206@noos.fr>.
|
|
Added #include <string.h> since glibc finally fixed most of the includes since 2001.
|
|
|
|
3.0 NEWS:
|
|
Major code rewrite. Now uses much better mixer library. New knob drawing code.
|
|
New config parsing code - no more segfaults. New mouse control code for knob
|
|
and slider dragging - more intuitive. Documentation updates. Removed runtime
|
|
config parsing, only reading config file once on startup. New command line
|
|
options to specify X display, config file, and mixer device. Removed "mixermax"
|
|
code until someone complains. Current channel title scrolling is now
|
|
configurable.
|
|
|
|
2.2 NEWS:
|
|
This is a bugfix release. On-Screen-Display code now looks for some common
|
|
large bitmap font. Check that $HOME is set before trying to write a config
|
|
file. Wmix makes a pid file for use with signal changing volume up/down.
|
|
Minor code reorganization.
|
|
|
|
2.11 NEWS:
|
|
Mostly bugfixes and other random stuff. OSD now really stays on top provided
|
|
you run a GNOME-compliant window manager (wmaker/E/saw-what-ever,etc)
|
|
|
|
2.1 NEWS:
|
|
Configuration file implemented. Mousewheel functionality, OSD display,
|
|
OSD color, main mixer device, and OSS bug work-around can now be selected
|
|
through WMixer rc file, by default placed in ~/.wmixrc
|
|
Changes to the rc file are loaded dynamically, while the mixer is running -
|
|
you can change the OSD color, for example, and see the results right away.
|
|
|
|
2.04 NEWS:
|
|
New feature: Volume of the current channel can be controlled using signals.
|
|
Sending SIGUSR1 will increase the volume by 1 step, and SIGUSR2 will decrase
|
|
the volume by 1 step. This could be useful if you have a newer style keyboard
|
|
with volume buttons and all the other extra shit. You can tell your favorite
|
|
window manager to run a program on keypress, and that program could be
|
|
something like "killall -USR1 wmix" for volume up key, and "killall -USR2 wmix"
|
|
for volume down. How to assign programs to specific keys is up to you. I know
|
|
Blackbox and WindowMaker can both do it. Keep in mind most X-servers don't
|
|
automatically support those extra keys, so some hacking might be required.
|
|
Usually they are sent as a Win95 key scancode plus another scancode. I don't
|
|
have one of these keyboards so I don't know. If enough people ask for it
|
|
I will add 2 more signal handlers to switch the current "channel" back and
|
|
forth.
|
|
|
|
2.02 NEWS:
|
|
Version 2.02 adds mouse wheel support to adjust volume, thanks to the
|
|
patch from Gilles QUERRET <gilles.querret@free.fr>. Now instead of
|
|
dragging the knob, you can use your mouse wheel to adjust the current channel
|
|
volume. Position the cursor anywhere on the dockapp, and move the wheel.
|
|
This behaviour is off by default, but you can compile wmix with -DMOUSEWHEEL
|
|
in the Makefile to enable this feature. In case your mouse has more than 2
|
|
buttons and a wheel, you can set which button signals the wheel generates as
|
|
"up" and "down" in mix.c, lines 45 and 46. The default is for a standard
|
|
mouse with 2 buttons and a wheel. WHEEL_STEP is the amount to adjust the knob.
|
|
The default of 3 should be good for everyone. Changing the volume using the
|
|
wheel also brings up OSD for the current channel following same rules as if the
|
|
knob was used directly.
|
|
|
|
2.01 NEWS:
|
|
New feature, which isn't really new, but a feature move from WMixer 1.5, is the
|
|
On-Screen-Display (OSD), just like the one you probably have on your TV. The
|
|
concept was the only thing copied from Wmixer 1.5 though, the code has been
|
|
rewritten to use a modeless window instead of drawing on the root window,
|
|
and draw code has been optimized not to draw any unnecessary stuff. The OSD
|
|
only comes up when the Knob is turned, i.e. during manual adjustment. OSD stays
|
|
hidden during automatic updates due to mixer reads or changing rec/balance etc.
|
|
However, due to the way the OSD timer is done, as long as you are moving inside
|
|
the dockapp (adjusting balance, or just generally moving the mouse inside the
|
|
dockapp window, the OSD will stay lit. After all movement is gone, and in
|
|
approximately 1.5 seconds, the OSD fades out. If some Xlib programmer knows
|
|
a /NON GAY/ way to handle always-on-top, feel free to mail me a diff that makes
|
|
the OSD continuously on top while being displayed. Right now, it comes up
|
|
on top, but if you move a window over it or something, it gets hidden. Not
|
|
too much of a loss, but still could be improved. OSD follows the same low-CPU
|
|
use guidelines as the rest of the code. No updates happen unless something
|
|
changes that requires an update. Also, expose events after uncovering the OSD
|
|
window are not handled - if you can manage to obscure it in 1.5 seconds and
|
|
want to see it again after that, you can always go back and twiddle the knob
|
|
or something.
|