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

[YamaKen]

Hi James,

At Thu, 5 Aug 2004 10:27:40 +0800,
james.su at gmail.com wrote:
>   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.

I don't know whether the Compose table is already usable enough
for any language in the world or not, so I want to make it
configurable to avoid possible future work.

On the other hand, device dependencies may require configurable
composing table. For example, suppose a mini-keyboard of PDA. It
often lacks dozen of keys from standard QWERTY keyboard, so some
different composing rule may be required.

>   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.

I know. But I want to avoid the maintenance, release and user
support cost about table configuration. I want to make it
maintenance-free. I can't support the development of the
immodule for Qt long enough, so I want to 'finish' the work.

But the conversion is useful as short term solution, so I did it
in response to Kazuki's request. We will include it in next
patch release.

> 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