[immodule-qt] Re: Re: A "deadline" for development?

YamaKen yamaken at bp.iij4u.or.jp
Thu Aug 5 04:48:15 EEST 2004


Hi Kazuki,

At Thu, 5 Aug 2004 08:27:31 +0900,
mover at hct.zaq.ne.jp wrote:
> I have a tough time to port X's parser to Qt.
> I've already created the sample program (attached), but have some problems.

Your experience will turn into your programming skill. Be happy :)

> The parsed result comes as X's "KeySym", so it needs to exchange "KeySym" to 
> Qt's keycode.
> Since Qt's doesn't distinguish Qt::Key_A, and Qt::Key_a, I decided to use 
> character code based composing tables like this. (NOTE that this is of course 
> test table). This means it nees to convert Qt's keycode to character code.
> 
>    117 |static const ComposeTableElement defaultTable[] = {
>    118 |    // test entries                                                                                                                   
>    119 |    { {'A' , ' ', 0, 0, 0, 0}, 'a' },
>    120 |    { {'a' , ' ', 0, 0, 0, 0}, 'b' },
>    121 |}

I've read almost code of QSimpleInputContext. One question. What
TODO items are remaining except for table translation?

At least, you have to ensure that there is no conflict between
Qt::Key and Unicode. For example, deadkeys are conflicting with
Ethiopic Unicode characters for now.

To ensure it, you should use a macro such as following. It
ensures that the unitized qkey will not conflict with any
Unicode or Qt4 keycode.

#define UNITIZE(qkey) (0x02000000 | qkey)

> One solution to deal with this is to prepare the hash table of keyname and 
> character code like /usr/lib/X11/XKeysymDB but this requires to maintain this 
> list, so the merit of importing parser becomes subtle.

I don't think that maintaining the DB is hard. Because keysym
definition is highly stable than composing table.

> To conclude, I think it costs high to merge X's parser to Qt.
> Any opinion?

I think it is a most cheaper way.

- Inventing another table syntax will greatly costs us anything

- Adopting another composing table syntax from another product
  will cost us something as same as X

- Convert some composing table into sourcecode form statically
  for QSimpleInputContext is a possible alternative way. But it
  will cost us updating and extending the composing table
  forever

I'll try to the importing if you are not being happy with doing
it.

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp



More information about the immodule-qt mailing list