Hi,
There was discussion about making use of ATK on KDE, rather than putting in another CORBA implementation to talk to AT-SPI (to avoid dependency on GNOME-related libraries).I'm not quite clear as to what was finally decided.
On a related note, is the gconf
Enrico Zini wrote:
Hello,
In the meantime, however, before I hurt my brain too much with this,
what's the overall situation? Is it worth the effort of fixing
gnome-speech, or is the effort better spend on making something else
work?
Hi Enrico,
I'm currently working on Speech Dispatcher
On Mon, Jun 26, 2006 at 07:14:01PM EST, Tomas Cerha wrote:
Hi Enrico,
I'm currently working on Speech Dispatcher backend for Orca. This
bypasses the Gnome Speech layer completely. Since Speech Dispatcher
offers several speech synthesizers not supported by Gnome Speech,
Mind I ask when
On 6/26/06, Bill Haneman [EMAIL PROTECTED] wrote:
On Mon, 2006-06-26 at 08:19, Ashu Sharma wrote: Hi, There was discussion about making use of ATK on KDE, rather than putting in another CORBA implementation to talk to AT-SPI (to avoid dependency on GNOME-related libraries). I'm not quite clear as
Hi Chris:
The answer is, don't implement sticky keys in your keyboard. You
should be using the system-wide StickyKeys settings and feature instead
(as GOK does).
Interfering with the normal operation of the system wide setting (i.e
clashing with it as your app does), is itself an accessibility
Hi Ashu:
Currently the state of KDE accessibility is somewhat limited. Other
than some important theming and keyboard-navigation support, which does
not require a complex interface such as AT-SPI, there are only a few
useful utilities like KMag, KMouth, and KMousetool. While these are
nice
On 6/26/06, Bill Haneman [EMAIL PROTECTED] wrote:
Hi Ashu:Currently the state of KDE accessibility is somewhat limited.Otherthan some important theming and keyboard-navigation support, which does
not require a complex interface such as AT-SPI, there are only a fewuseful utilities like KMag,
Thanks for your reply.
The system-wide StickyKeys is too inflexible for my needs. I have the
following gripes:
* A user might want the onscreen keyboard to be sticky but not the physical.
* It does not allow me to implement the functionality in a way that
is suitable for an onscreen
On Mon, 2006-06-26 at 21:43, Chris Jones wrote:
Thanks for your reply.
The system-wide StickyKeys is too inflexible for my needs. I have the
following gripes:
* A user might want the onscreen keyboard to be sticky but not the physical.
I am not convinced that users will really want this,
Bill Haneman wrote:
On Mon, 2006-06-26 at 22:28, Henrik Nilsen Omma wrote:
Bill, is it an accessibility violation to have unusable accessibility tools?
Are you going to say something helpful?
OK, I should have resisted that last line, sorry.
But there is a valid point under
On Mon, 2006-06-26 at 23:05, Henrik Nilsen Omma wrote:
Bill Haneman wrote:
On Mon, 2006-06-26 at 22:28, Henrik Nilsen Omma wrote:
Bill, is it an accessibility violation to have unusable accessibility
tools?
Are you going to say something helpful?
OK, I should
On Mon, 2006-06-26 at 22:28, Henrik Nilsen Omma wrote:
Chris Jones wrote:
...
In other words I cannot spend the summer making gnome-a11y suitable
for my needs. What I need is a temporary work around until after the
SoC when I could find time to work on this aspect of gnome-a11y and
But this very same thing makes it very awkward who want sticky keys on
the keyboard and non-sticky on a physical. Which would be true for
all non-a11y users and some a11y users.
In the end though the only manner it interferes with my keyboard is
the annoying dialogue that pops up, and the
Hi Chris,
One more thing. You write:
Using the system wide sticky keys means I need to have at least one
dialog box when my keyboard starts and is therefore completely
unacceptable.
Have you filed an RFE on this issue (seeking a way to invoke the
system-wide Sticky-Keys functionality
14 matches
Mail list logo
