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

[Lars Knoll]

On Thursday 05 August 2004 04:27, Zhe Su wrote:
> 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.

I do as well think that this is the form that is most easily maintainable in 
the future. 

By the way, if you need any changes to QKeyEvent in Qt 4 to make your work 
easier, please tell me. We can still do changes in the way we set up our key 
events to make things easier for you. Like that we have a good chance that 
you will not need to use the x11EventFilter.

Regards,
Lars

>
> 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
>
> _______________________________________________
> immodule-qt mailing list
> immodule-qt at freedesktop.org
> http://freedesktop.org/mailman/listinfo/immodule-qt