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

[Zhe Su]

Hi,
  Alright. But Is it possible to add the ability to distinguish left
and right ctrl/alt/shift key events?

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
>