On Thu, Feb 13, 2003 at 08:39:21PM -0000, Max Bowsher wrote: >Christopher Faylor wrote: >> On Thu, Feb 13, 2003 at 01:34:28AM +0100, Vaclav Haisman wrote: >>> >>> Hi, >>> this small patch adds an ability to produce beeps (\a) using >>> soundcard by MessageBeep() call. It can be enabled by new CYGWIN >>> option winbeep. >>> >>> Vaclav Haisman >>> >>> 2003-02-13 Vaclav Haisman <[EMAIL PROTECTED]> >>> * environ.cc (windows_beep): New variable declaration. >>> (parse_thing): New CYGWIN option. >>> * fhandler_console.cc (windows_beep): New variable definition. >>> (fhandler_console::write_normal): Handle the new option. >>> * Makefile.in (DLL_IMPORTS): Add libuser32.a for MessageBeep. >> >> I'm sorry but I really don't want to add too many options to the >> CYGWIN environment variable. I don't think this really justifies an >> option. > >Does that mean it will replace the current beep, or is it a rejection of the >patch? I would really like this - Beep() can be quite painful if you're >wearing headphones!. MessageBeep would be controllable via the volume >settings, but Beep is just a maximum volume blast! > >Does it really *matter* for there to be lots of options in CYGWIN? I can't >see any disadvantage at all.
I don't like to introduce lots of unnecessary decision points into a product. It increases support and it increases code complexity. Once again, how does linux handle this scenario? You don't do a "export LINUX=linbeep" to get linux to use the soundcard. cgf
