Re: [tuxdroid-user] Event handling chain?

[Martin T. <ma...@ma...>]

On Tue, 2007-04-10 at 15:47 +0200, David Bourgeois wrote:
> 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.
Both good points.
> 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 :-)
Or a method to query mute status maybe?
> 
> >> 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.
I think you are right that other applications don't need to know what
other applications have done.  It may be that it is useful for them to
be able to see what the daemon or the firmware is setup to do - I am
thinking in terms of a stack with the app at the top and the local
firmware at the bottom.  If the daemon has associated a mute function
and a button then the app does not need to.
Maybe I should just play with tux for a while :-)

Thanks // M
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________ tux-droid-user mailing list tux...@li... https://lists.sourceforge.net/lists/listinfo/tux-droid-user