> >If a compatible keyboard extension isn't present in the X server,
> >XkbBell calls XBell with the specified display and percent,
> >and returns False. Otherwise, XkbBell calls XkbDeviceBell
> >with the specified display, window, percent, and name, a device_spec
> >of XkbUseCoreKbd, a bell_class
>I like the idea of the patch, but I would like know how this function
>works. I mean, you say that you can have a process listenning for the
>event, but, what happens if you don't have such process?
>From the manual pages
>If a compatible keyboard extension isn't present in the X server,
>XkbBe
> However, if you use XkbBell() then you can have a process listening for
> the XkbBellNotifyEvent that is produced and either alert you visually or
> play an audio file or whatever you want as your notification. You have
> to include one more header file but the function seems to be compiled as
>
>On Fri, Oct 3, 2014 at 3:25 PM, CustaiCo
>wrote:
>> The XBell() call currently used when a bell is recieved sends a message
>> to the X server, but if the X server doesn't know how to sound it,
>> it just gets ignored and I have not been able to find anywhere in x.org's
>> code a way to configur
Hello,
On Fri, Oct 3, 2014 at 3:25 PM, CustaiCo wrote:
> The XBell() call currently used when a bell is recieved sends a message
> to the X server, but if the X server doesn't know how to sound it,
> it just gets ignored and I have not been able to find anywhere in x.org's
> code a way to configu
The XBell() call currently used when a bell is recieved sends a message
to the X server, but if the X server doesn't know how to sound it,
it just gets ignored and I have not been able to find anywhere in x.org's
code a way to configure the action that the server does.
However, if you use XkbBel