[Kde-accessibility] Kicker virtual keyboard to KDE-3.2+?
Bill Haneman
bill.haneman@sun.com
08 Jan 2003 11:15:50 +0000
On Wed, 2003-01-08 at 09:49, amth wrote:
> > -----Original Message-----
> > From: Bill Haneman [mailto:bill.haneman@sun.com]
> > Sent: Tuesday, January 07, 2003, 5:18 AM
> > To: amth@ziplip.com
> > Subject: Re: [Kde-accessibility] Kicker virtual keyboard to KDE-3.2+?
> >
>
> Ok, first of all I'm sorry to _again_ emailing you directly. Don't worry, not considering spamming you for eternity... ;-)
<snip>
No problem, I was the one who kept replying... I am CCing the
accessibility list though since I think some of my reply below might be
of general interest.
Sure, for the embedded device, KDE-only (or, perhaps, Qt-only scenario)
I agree that you don't need all these extra dependencies (even though
GOK can be easily made into an embedded window, etc.).
But if all you need is a "simple" OSK without predictive capabilities,
surely there isn't much code required? Couple hundred lines of code (or
less) should do the trick.
What I want specifically to avoid is "KOSK", "Kopernicus", "KATK", etc.
just for the sake of avoiding glib (and avoiding, if necessary, some
minor surgery to avoid the incidental gtk+ UI dependencies of GOK and
Gnopernicus), when the only existing assistive technologies will require
glib anyway, and an ORB, etc. Your embedded case is different, since
we're talking about a very small footprint device. This is also why I
think KOSK (even if it is created) is probably not a good fit for your
application, since a full-featured KOSK that worked for accessibility
would be too big for your need.
Of course from an accessibility point of view, embedded devices are
important too, maybe even more important since they can be very helpful
to disabled people. But I think such devices will need to be "next
generation" PDAs, etc. which have enough computing power and capacity to
run KDE itself, etc.
best regards,
Bill
> --
> amth
--
Bill Haneman <bill.haneman@sun.com>