input methods and OSX (Qt bug? Or kkeyserver bug?)
Hamish Rodda
rodda at kde.org
Fri Sep 8 09:50:00 BST 2006
On Friday 08 September 2006 18:07, Simon Hausmann wrote:
> On Friday 08 September 2006 03:45, Benjamin Reed wrote:
> > It looks like non-US input seems to work just fine for most languages,
> > but anything that uses an input method rather than unicode/roman
> > characters silently does nothing.
> >
> > I don't know enough of how Qt interacts with the OSX input methods
> > (nor enough about input methods in general) to have any idea how to
> > start debugging this. Do you have any ideas where to start, or any
> > insights into what should be checked?
> >
> > If you'd like to see what I mean, I've got pre-made 10.4 binaries at:
> >
> > http://ranger.users.finkproject.org/kde/
> >
> > I've tried using kwrite and I spot checked it with various languages
> > (even arabic works, with right-to-left input) but chinese, japanese,
> > korean, and probably anything else with an input method doesn't work.
>
> Input methods work fine for me with QTextEdit and QLineEdit in 4.2. (apart
> from a bug in the simplified chinese input, which will be fixed in
> tomorrow's snapshot)
>
> Are you sure this is not a bug in kwrite/kate's input method handling code?
I wouldn't be surprised at this... we had some XIM code which hasn't been
ported yet.
Try testing with something other than katepart... and if anyone understands
XIM and would like to help kate, it would be welcome...
Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060908/f0bc4dfa/attachment.sig>
More information about the kde-core-devel
mailing list