[openi18n-im:01449] Re: key release issue with iiimxcf
Federic Zhang <[email protected]> Thu, 30 Jun 2005 00:49:01 +0800
| Newsgroups | gmane.comp.internationalization.input-methods |
|---|---|
| Message-ID | <[email protected]> |
Kasha, Your suggestion and explanation are rather useful, we should take the compatiblity into consideration no matter whatever we commit, Thanks! -federic > Date: Wed, 29 Jun 2005 10:47:44 +0800 > From: Federic Zhang <[email protected]>: > > > > > Date: Wed, 29 Jun 2005 10:19:51 +0800 > > > From: Federic Zhang <[email protected]>: > > > > Kasha, > > > > > > > > >From LE and IM point of view, KEYEVENT data type isn't incompatibly > > > > changed, a new member 'member' is appended at end of the original > > > > KEYEVENT struct, those *existing* LE *binary* can work well with the new > > > > change. > > > > > > > > The root cause happens in client side, i already sent to alias, i just > > > > modified iiimgcf, other client frameworks such as iiimxcf and iiimqcf > > > > should be synced with the change as i amn't familiar with them, i hope > > > > someone can do it, but nobody step in, but i have to hack by myself to > > > > incompatibility issue. :( > > > > > > If client frameworks need to be updated, this is the problem. I > > > meant compatibility between old version and new version. > > > Existing client frameworks should be supported by updated server > > > framework, I'm suggesting. > > I should say: > > Existing client frameworks should work with updated server > framework, without the new feature. Existing server framework > should work with updated client frameworks, without the new > feature. > > +------------------------------------------------------------+ > | | existing | new | > | | server framework | server framework | > |------------------+--------------------+--------------------| > | existing | the feature is not | the feature is not | > | client framework | available | available | > |------------------+--------------------+--------------------| > | new | the feature is not | the feature is | > | client framework | available | available | > +------------------------------------------------------------+ > > All combination should work, I'm suggesting. > > > > > I see. Can we update server framework only in this case? IMHO, most of > > cases, server framework and client framework have to *chorus* together > > to support one feature. > > > > I mean both sides have to be updated. Correct me > > if my understanding is wrong. > > Yes, right. To support this feature, both of client frameworks > and server framework will be updated. > > Thanks, > -- > kasha > > > > > -federic > > > > > Thanks, > > > -- > > > kasha > > > > > > > > > > > Hope it can clarify. > > > > > > > > -federic > > > > > > > > > Date: Tue, 28 Jun 2005 22:01:54 +0800 > > > > > From: Federic Zhang <[email protected]>: > > > > > > > > > > > > It is caused by iiimxcf, if the attached patch is patched to > > > > > > iiimxcf/xiiimp.so/iiimp/KeyMap.c, it should work. > > > > > > > > > > I think I understand the root cause. The implementation of key > > > > > release feature breaks compatibility. KEYEVENT data type is > > > > > incompatibly changed. > > > > > > > > > > So the question is that whether this feature can be implemented > > > > > in a compatible way or not. > > > > > > > > > > Federic, how do you think? > > > > > > > > > > Thanks, > > > > > -- > > > > > kasha