[Bug 24902] interface for precomposed dial-strings

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24902





--- Comment #14 from Will Thompson <will.thompson at collabora.co.uk>  2010-03-24 08:19:12 PST ---
(In reply to comment #13)
> I'd prefer it to be an interface on the channel interface, but I don't feel
> strongly about it one way or the other.

I think my position on this is: from a theoretical stand-point it should be on
the content, and as Olivier says UIs have to deal with contents anyway. But in
practice I doubt any UI that supports a dial-pad will support >1 audio content
so it probably makes zero practical difference.

> I think it's important from a UI perspective to hear tones when one holds down
> a key.  This is helpful when navigating an automated phone system ("press 1 to
> hear this in english.  pará español,  empuje el número 2, ...").  When one
> eventually gets frustrated at the phone menu and starts mashing 0 repeatedly,
> one would not want to deprive the user of the satisfaction of hearing those
> angry tones.

:D

> What happens when MultipleTones is running, and StartTone(3) is called?  Should
> that quietly truncate the currently playing tone string?
> 
> 
> > What's the use case for SendingTones? It's racy for the UI to change its
> > behaviour based on it, like muting the microphone. But it's probably fine for
> > informational purposes.
> > 
> 
> I'm imagining things like a UI number display.  You're at a phone menu, dialing
> your fedex tracking number (followed by the #).  StartTone(5), StopTone(),
> StartTone(4), StopTone, StartTone(3), etc...   How does the UI know whether the
> tone actually ended up being played?  SendingTones informs you that the number
> has been played, and therefore the UI should display the played number.
> 
> For newly placed calls like '3214p123', SendingTones is an indicator to the UI
> that the call's not quite ready for user input; StoppedTones tells the UI that
> the call is ready for the user to mangle.  I don't think stuff like muting need
> be handled at the UI level; the CM is presumably capable of muting any audio
> while playing tones (if necessary).

Sounds like the UI should wait until any MultipleTones() in progress have
finished by waiting for StoppedTones before letting the user mash buttons?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.