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

[Lars Knoll]

On Thursday 05 August 2004 13:07, Zhe Su wrote:
> Hi,
>   I know little about QT. But I think using the same value as X11's
> keysyms should be the best solution, at least for X window based
> system. Just like what gtk2 does.

That is unfortunately impossible. We have to support 4 different Qt versions, 
and out key events have to look the same on all platforms (including the 
numerical values of enums). Otherwise we would loose the source code 
portability between the platforms. This is the whole reason why we translate 
every X key event into a QKeyEvent.

A second point is that XKeySyms need decoding tables to convert them to 
Unicode which makes them rather difficult to use directly in application 
programming. 

Regards,
Lars

>
> Regards
> James Su
>
> On Thu, 5 Aug 2004 13:04:19 +0200, Lars Knoll <lars at trolltech.com> wrote:
> > 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