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

[YamaKen]

At Thu, 5 Aug 2004 15:34:48 +0200,
lars at trolltech.com wrote:
> 
> On Thursday 05 August 2004 14:58, Zhe Su wrote:
> >   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.

I had heard that some platform cannot distinguish the left and
right one. So I regard the unified modifier keys of Qt is
intended feature to ensure sourcecode portability. Isn't it?

Or you are meaning introducing some flags in QKeyEvent that
indicates left or right in addition to unified Key_Shift?

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