Blueprint changes email notification need better formating
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Bug Description
It difficult to track the additions to a blueprint via the email notifications.
An example Blueprint changes email notification is give below, its not quite clear what was adding until you look *very* closely.
~~~~~~~
Blueprint changed by Luke Yelavich:
Whiteboard changed:
pitti, 2009-06-12:
- Is speech-dispatcher scheduled to become an official part of GNOME, so that it will get upstream support and integration? I'm particularly thinking of maintaining compatiblity with ATK in general, and gnome-at-
TheMuso: speech-dispatcher has nothing to do with ATK, or the GNOME
accessibility framework. gnome-speech used CORBA, and either needs to be
ported to something else, or replaced. Speech-dispatcher would become an
external dependency of GNOME, and I plan to work with the gnome-
orca/
close to being ready.
This work is also very much needed, since there is nobody else in the
accessibility community who has the time, or who is willing to do the
necessary work to get a suitable replacement for speech services by the
time GNOME 3.0 roles around.
- I'm not entirely sure that it is a good idea to translate log files.
Especially not if their purpose is debugging, since you probably can't
send them to bug reports that way. Do they contain information that the
user actually needs to see? If so, these bits should probably go in a
separate "user log" which is translatable?
TheMuso: Fair enough, I've removed that from the spec, as the logs are
only really for debugging purposes at this point.
- Why is it principally easier to implement an entirely new Unix socket
backend than to use different TCP/IP ports? Do you want to store the
Unix sockets in the user's home directory?
TheMuso: I've decided to work out a way to ensure each user session on a
system has its own port. See the spec. In terms of time spent on code,
the IPC is the least of our worries at this point.
- This involves quite a large set of code changes; do you think you'll
be able to fit these into your schedule, together with the audio
maintenance? Or are there more people working on these improvements?
TheMuso: Yes, I will be getting help from the community with this work,
mostly relating to language/
these shouldn't take too long to do.
pitti, 2009-06-16: Thanks, approved
Work items:
Adjust speech-dispatcher logging mechanism to not produce any logs by default: DONE
Add command-line flags to enable logs to be produced for debugging: DONE
Add command-line flags to force the hostname/port to listen on: DONE
Extend the C and python API to use a unique port for individual user sessions: DONE
Implement graceful audio fallback: DONE
Implement multi-level punctuation handling, depending on the client, chosen synthesizer, and language: POSTPONED
Implement multi-level capital letter handling, depending on the client, chosen synthesizer, and language: POSTPONED
Implement multi-level word pronounciation handling, depending on the client, chosen synthesizer, and language: POSTPONED
- Implement indexing of text strings by word, in addition to sentence/utterance: TODO
+ Implement indexing of text strings by word, in addition to sentence/utterance: POSTPONED
Implement speech-dispatcher auto-spawning by client API/bindings: DONE
Port Dasher to speech-dispatcher: POSTPONED
Port Gok to speech-dispatcher: POSTPONED
Promote speech-dispatcher and libdotconf to main: TODO
Debug speech-dispatcher's pulseaudio output support: TODO
Implement mechanism to allow for the system speech-dispatcher daemon to communicate with a user session speech-dispatcher daemon: POSTPONED
--
Replace gnome-speech with a More Flexible Speech Backend
https:/
~~~~~~~
| affects: | launchpad → blueprint |
| Changed in blueprint: | |
| importance: | Undecided → Low |
| status: | New → Triaged |
