Re: [tuxdroid-user] Event handling chain?

[David B. <da...@ja...>]

On Tue, 10 Apr 2007 14:50:52 +0200, Martin Thomas  
<ma...@ma...> wrote:

> On Tue, 2007-04-10 at 08:57 +0200, David Bourgeois wrote:
>> On Mon, 09 Apr 2007 23:55:23 +0200, martin <ma...@ma...>  
>> wrote:
>>
>> > Are button presses (like wing or head or RC) always passed on by the
>> > firmware or can they be 'swallowed'?
>> >
>> > I am thinking of adding a function to the firmware so that I can tap  
>> the
>> > head button to mute sound.. but I am not sure if the button event will
>> > still
>> > be propagated to the daemon, overloading the button.  Maybe I could  
>> just
>> > do
>> > everything on the pc.. but I would like to play with the firmware a
>> > little
>> > more.
>>
>> That depends on what you want to handle locally and from the computer. I
>> would say that muting the sound requires to have sound sent from the
>> computer so I would find it more logical to have the computer get the  
>> head
>> button event and decide to do the mute (by siftware or send the mute
>> command). But in case you just use the usb audio device and don't have  
>> the
>> daemon running, that makes sense to have it locally by firmware.
> You might also want to mute locally stored sounds which Tux will play
> regardless of a host computer. So perhaps a mute button is not as simple
> as it appears.

You're right, it might be intersting to mute the local sounds easily. On  
the other hand the internal sound flash can only store 1 minute of sounds  
so you're not likely to play local songs and you can also turn off the  
volume dial.
But anyway the above solution is still convenient if you store the mute  
funciton associated with the head button event in eeprom, then even if the  
computer is disconnected and you restart tux, you'll be able to mute with  
the head button. That makes me think we need a toggle_mute() function  
otherwise you'll only be able to mute and not unmute with this method :-)

>> In such a case, I think the standalone behavior proposal I already
>> explained a bit would be a good solution. You could associate the mute
>> function to the head button event in the eeprom (when this will be
>> possible to do from the api in the near future) and easily  
>> enable/disable
>> that event from the computer. When disabled,the status of the button  
>> would
>> still be sent to the computer but the sequence won't be played. So even  
>> if
>> your applications need to use the head button at a certain point, they
>> could still disable the standalone head button event momentarily. Though
>> the daemon/api should handle that instead of the application.
> It probably is an application level behaviour to associate buttons and
> behaviours.

Yep but what I mean is that some of your your applications (let's say  
VOIP) aren't supposed to know that you associated the mute function with  
the head button locally on tux or from another application. So to avoid  
muting at the same time you pick up the call, the api or a manager  
application needs to deal with that.