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

[Zhe Su]

Hi,
  In my point of view, a sourc code form table is better than others.
Because it's cheaper, easy to realize. And I don't think the X's
Compose table will be updated frequently.
  So we can write a script (or program) to convert X's Compose table
into the source code form (maybe a header file) automatically, then we
can just include this file in QSimpleInputContext. When the Compose
table is updated, we just need to re-generate the header file.

Regards
James Su

On Thu, 05 Aug 2004 10:48:15 +0900, YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 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
> _______________________________________________
> immodule-qt mailing list
> immodule-qt at freedesktop.org
> http://freedesktop.org/mailman/listinfo/immodule-qt
>