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

[Lars Knoll]

On Thursday 05 August 2004 14:58, Zhe Su wrote:
> Hi,
>   Alright. But Is it possible to add the ability to distinguish left
> and right ctrl/alt/shift key events?

That should be possible. I'll add it to my todo list.

Best regards,
Lars

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