GNOME Bugzilla – Bug 607610
new plugin to audibly announce new mail
Last modified: 2021-05-19 11:37:46 UTC
Created attachment 151882 [details] [review] Patch adding plugin to read aloud sender, subject of new mail Hi. == About the Plugin == I've written a plugin for Evolution that, upon receipt of new mail, uses Speech Dispatcher to announce aloud the new message's author and subject. If there are multiple new e-mails, it just announces a count of the new e-mails. If the Speech Dispatcher daemon is not available at run time, the plugin is disabled. It has three configuration options: * whether to say the sender's name (can disable for privacy) * whether to say the subject (can disable for privacy) * which language/voice to use out of the synthesis voices offered by Speech Dispatcher. If both sender and subject are disabled, it just states the arrival of new mail. == About the Code == The patch is against git head as of about now. It requires functionality introduced by commit daa8339 in evo master (2.29.2+) noted by bug 464400, to provide a messages sender and subject in the new mail event. I suspect I probably want some automake magic to avoid compiling it if someone doesn't have Speech Dispatcher's libraries installed at compile time, but I'm not quite sure how to do that. (I will poke around.) = Speech Dispatcher = I understand that Speech Dispatcher is the current candidate for GNOME 3.0's speech services. I could switch to a different API if that changes. For speech output modules (espeak, festival, etc.), it currently just uses whatever Speech Dispatcher is set to by default (which I believe can be set in Speech Dispatcher's configuration file). I could optionally add a configuration option to change that. There are some g_warnings printed to the command-line when things that shouldn't fail do (or when Speech Dispatcher's daemon is unavailable). If you try this plugin and you don't hear something when receiving new mail, try ensuring that Speech Dispatcher is up and running properly by using $ spd-say "Speech Dispatcher is working if I hear this, and the plugin is broken." Fedora 10's default configuration for Speech Dispatcher was broken, and it used to have some issues with alsa versus pulse audio for sound systems. If Speech Dispatcher isn't working for you by default, I'll be happy to pursue bugs for your problem to try to ensure that Speech Dispatcher can work by default for this plugin. == Miscellaneous == The name of the plugin is currently "Evo Aqua". I think we'd probably want to change it to something meaningful like "Announce New Messages". It's Evo Aqua for now because it's part of a series of plugins including DJ Aqua (for Rhythmbox) and IM Aqua (for Pidgin) that announce the next track and read aloud new messages respectively. Cheers, Richard Schwarting
Thanks Richard, this looks really cool! I haven't tried it out yet or looked at the patch in detail, but I just have a few comments on how I think this should be integrated into the application. A few versions ago we had at least three different mail notification plugins that performed different tricks -- played a sound, emitted a D-Bus message, showed an icon in the notification area, etc. The configuration options were scattered all over the place and were hard to find, so at one point we combined those plugins so all the new mail notification options are in one place. (One could reasonably argue that they belong in Preferences, but there's just no room at the moment.) As we add more methods of mail notification like speech synthesis, I'd still prefer to keep all notification options in one place. Would it be possible for you to extend the existing "mail-notification" plugin with this new cababillity? You could probably keep most of your code in a separate source file as is (in fact I'd recommend that), but tie it into mail-notification.c. Getting the voice options into the already-crowed configuration tab will be the trickiest part, but I already have some ideas on how to free up space. Roughly, the "play a sound" section would look something like this: [x] [_____ combobox with various sound options _____|v] +- - - - - - - - - - - - - - - - - - - - - - - - -+ | reserved space for any additional sound widgets | +- - - - - - - - - - - - - - - - - - - - - - - - -+ For example: [x] [ Play a Sound File ____________________________|v] +------------------------------------------+ +---+ | My Sound.wav (file-chooser button) | | > | +------------------------------------------+ +---+ Or in this case, perhaps: [x] [ Play an Announcement _________________________|v] [x] Say sender [x] Say subject [ Try It! ] [ Language / Voice Choices _____________________|v] The "Try It!" button would play some dummy announcement (something cute) so the user can play with the options and hear the different choices. Once this much is done, I can take care of the automake magic so these options are simply absent if the required libraries are not installed.
Thanks for the review. I modified the patch to integrate with the existing mail notification plugin, but first I did it by adding another option below the rest. Then I've modified the audio section to use a combo box, and now I have some questions about what might be preferred. The plugin uses both a struct _SoundConfigureWidgets and a GConfClient to find out the state of the same set of widgets (that is, which filename is set, whether beep is set, whether use theme is set, whether sound is enabled at all). I was wondering whether we couldn't just use GConfClient and check the key as set in gconf rather than also maintaining the struct of widgets. It would simplify the code. I'm wondering whether GConfClient is less efficient (perhaps it doesn't cache values already retrieved or set, and goes to the disk?) and that's why the mixture is used. Thanks.
Created attachment 157849 [details] [review] Patch adding Speech Dispatcher method for mail notification So I decided to go ahead with it anyway and am uploading an updated patch, though I'm not sure if this is the right direction. I consequently ended up modifying more of mail-notification than before. I'll be happy to break the patch up into a set if that makes it easier, or try to be less invasive. So, changes: * removed _SoundConfigureWidgets structure and now use GConfClient to determine values when we need them. Mail Notification's GConf directory gets watched by GConfClient to keep the values cached and readily available. It simplified the code for my usage (only having one place to read and write values, reducing duplication), and seemed recommended by GConfClient's documentation (suggesting GConfClient be an application's model). * refactored some sound selection and play back code into do_play_sound(), reducing the similar sound_play_cb() and sound_notify_idle_cb() * changes the notification sound UI into a drop down as suggested above. This might be one of the larger changes. * EvoAqua plugins' content is now a separate file with the speech code, as suggested above. I have a couple questions which are captured by TODO comments in the source: * I'm not sure what the best way to handle the error messages is for potential GConfClient errors. Are they best pushed to stderr and let the software try to handle the failure gracefully, making assumptions, or should we actually pop up warning messages to the user that some key could not be got or set for some reason. speech.c is printing them to stderr, while mail-notification.c currently just has a TODO comment until I get more feedback. * I think I want to move new_notify_sound()'s call to speech.c's speech_new_notify() into do_play_sound(), so it'll sit next to the rest of the actual-sound-doing code. That requires pushing more data into _SoundNotifyData which I think should be alright. Sorry if I've done anything terribly dumb. I'll be happy for any feedback.
Comment on attachment 157849 [details] [review] Patch adding Speech Dispatcher method for mail notification Evo does not use gconf anymore - patch needs rework
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.