[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    [Bug 129681] kttsd plugin feature request for kmail
From:       david powell <achiestdragon () gmail ! com>
Date:       2006-06-25 23:36:17
Message-ID: 20060625233617.17844.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=129681         




------- Additional Comments From achiestdragon gmail com  2006-06-26 01:36 -------
the knotificaton for new mail  works in kttsd  but could do with a bit better \
formating 

the kmail kttsd filter removes the text /local/inbox from the new mail notification \
message and the qt formating but could do to give a more friendly format for kttsd \
also , tend to think this will need more notification options  as notifications for  \
new mail in some folders will need to be selectable , for example  you may want to \
turn off notifications for new mail in /local/inbox/spam etc   

i use a custom spoken message for the new mail knotify event that speaks "you have \
new mail"  and it works well but does not distinguish what folders have new mail  so \
sort of a work around for a full implimentation of that atm 

qt4 and a screen reader when available should solve most of the problems but think it \
may miss being able to pickup the difference betwen read and unread mail so that may \
need to be addressed when the time comes 

i put the feature request for it to read out the content of the mail 
as a first instance , for a number of reasons , 

firstly it needs it  
secondly although other kttsd features are needed in kmail  i was partly hoping that \
the kmail devs may think of adding other kttsd functions or come up with a better way \
to handle new mail events  thirdly should be easy enough to impliment and expanding \
it to the other things  should be easyer than thowing them in the deep end and \
wanting it all at once 

also atm we dont have a screen reader so tend to think that it may be better wating \
to find out what the screen reader will and will not handle without duplicating the \
function

the abilaty to read out emails is probablay going to take the longest to get right \
with the filtering of unwanted html and formating  etc  although a lot of that could \
be handled with kttsd filters, the sooner we can get the function to read out the \
message content the more time we have to test and create filters  needed for it and \
tweak them 

at least then even if the function gets replaced eventualy with a screen reader the \
filters should be ready and tested for it and should be mature by then 

dave
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel


[prev in list] [next in list] [prev in thread] [next in thread]