headers
Hideki Hiura | 1 Nov 2004 01:30

[openi18n-im:01116] Re: SC_TRIGGER_OFF_NOTIFY vs. preedit

Hi Akira,

> From: Akira TAGOH <tagoh <at> redhat.com>
> which requires ctrl+shift+space or so - since it works under
> the hotkey protocol, we can provide any way to change the
> super hotkey as well, right?

Surely, and it probably is on your shoulder :-) We need to define
additional directives in XML configuration files for system, and
also for user, as the next step of what you've done for 
/etc/iiim/htt.xml.conf.

Would it be possible for you to look into this?

Where currently define the fallback default is in the file 
IIIMP_hotkey_profile.spp, IIMP_hotkey_profile::add_default_hotkey_profiles().

The add_default_hotkey_profiles() should consult with the info from
/etc/iiim/htt.xml.conf for system and the $HOME/.iiim/≤htt.xml.conf> 
for per-user.

> BTW can we have the special hotkey to be only closing the
> language switching menu say? I mean if Escape key works for
> closing the window anyway, it would be nice.

Sounds good to me. We should have them also defined from the beginning and
until the XML directive is defined and incorporated in /etc/iiim/htt.xml.conf
The Escape sounds like a good choice for fallback default.
We'll add this quickly.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Akira TAGOH | 1 Nov 2004 12:57
Picon
Favicon

[openi18n-im:01117] Re: SC_TRIGGER_OFF_NOTIFY vs. preedit

>>>>> On Sun, 31 Oct 2004 16:30:53 -0800 (PST),
>>>>> "HH" == Hideki Hiura <hiura <at> openi18n.org> wrote:

HH> Hi Akira,
>> From: Akira TAGOH <tagoh <at> redhat.com>
>> which requires ctrl+shift+space or so - since it works under
>> the hotkey protocol, we can provide any way to change the
>> super hotkey as well, right?

HH> Surely, and it probably is on your shoulder :-) We need to define
HH> additional directives in XML configuration files for system, and
HH> also for user, as the next step of what you've done for 
HH> /etc/iiim/htt.xml.conf.

HH> Would it be possible for you to look into this?

Yes, I'll do that as well when I'll send the updated XML
configuration proposal. I'll find some times to do that.

HH> Where currently define the fallback default is in the file 
HH> IIIMP_hotkey_profile.spp, IIMP_hotkey_profile::add_default_hotkey_profiles().

HH> The add_default_hotkey_profiles() should consult with the info from
HH> /etc/iiim/htt.xml.conf for system and the $HOME/.iiim/≤htt.xml.conf> 
HH> for per-user.

>> BTW can we have the special hotkey to be only closing the
>> language switching menu say? I mean if Escape key works for
>> closing the window anyway, it would be nice.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Akira TAGOH | 1 Nov 2004 13:02
Picon
Favicon

[openi18n-im:01118] Re: SC_TRIGGER_OFF_NOTIFY vs. preedit

>>>>> On Sat, 30 Oct 2004 02:25:05 -0700 (PDT),
>>>>> "HH" == Hideki Hiura <hiura <at> openi18n.org> wrote:

>> From: Yu Shao <yshao <at> redhat.com>
>> >>>From: Akira TAGOH <tagoh <at> redhat.com>
>> >>>ctrl+space was delivered as the usual key event. is it the
>> >>>expected bahavior?
>> >HH> No it's not.
>> Just some information, this was ok before, at least on version 
>> 11.4-66.svn1772.

HH> Isn't it already fixed in svn2024(trunk)/2025(r12_1_1)?

Yes, it has been fixed in 2024 :)

--
Akira TAGOH
Permalink | Reply | 0 comments |
headers
Jens Petersen | 2 Nov 2004 04:40
Picon
Favicon

[openi18n-im:01119] "From" field on openi18n-svn-notify list

Is it possible that openi18n-svn-notify list could be changed
so that the "From:" field shows the name of the committer rather than just
"svn <at> openi18n.org"?  Currently it isn't possible to see in one's mail summary
who the committer of a patch is, which is rather useful IMHO.

Jens
Permalink | Reply | 0 comments |
headers
Leon Ho | 9 Nov 2004 01:30
Picon
Favicon

[openi18n-im:01120] httx trigger hotkey

Hi,

Currently by default iiimf in iiimgcf can able to be activated by ctrl-
space and shift-space. 

httx can able to activate through ctrl-space, but not shift-space. Is it
a normal behavior?

Regards,
Leon
Permalink | Reply | 1 comment |
headers
Hideki Hiura | 9 Nov 2004 03:04

[openi18n-im:01121] Re: httx trigger hotkey

> From: Leon Ho <llch <at> redhat.com>
> Currently by default iiimf in iiimgcf can able to be activated by ctrl-
> space and shift-space. 
> 
> httx can able to activate through ctrl-space, but not shift-space. Is it
> a normal behavior?

No, it's a bug :-).

Hideki
Permalink | Reply | 0 comments |
headers
Jens Petersen | 9 Nov 2004 06:55
Picon
Favicon

[openi18n-im:01122] Emacs bad interaction with httx

Hi,

For a long time now, running Emacs in CJK locale with XIM enabled
has caused httx to segfault on Fedora Core at least.
Does anyone know anything about this issue?

I can supply more details if necessary, but see for example
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125413>.
I'm not aware of this problem happening with any other XIM
apps: eg XEmacs works fine.

Jens
Permalink | Reply | 0 comments |
headers
Yu Shao | 17 Nov 2004 17:41
Picon
Favicon
Subject: [openi18n-im:01123] iiimcf/iiimgcf/compose keys

[openi18n-im:01123] iiimcf/iiimgcf/compose keys

Right now, european dead keys are not handled in iiimgcf, seems only in 
unit LE, I am just wondering should we put this part of code into 
iiimcf, so both gtk and qt will be able to handle compose keys correctly?

Regards,
Shao
Permalink | Reply | 3 comments |
headers
Hideki Hiura | 17 Nov 2004 18:23
Subject: [openi18n-im:01124] Re: iiimcf/iiimgcf/compose keys

[openi18n-im:01124] Re: iiimcf/iiimgcf/compose keys

Hi Shao,

> From: Yu Shao <yshao <at> redhat.com>
> Right now, european dead keys are not handled in iiimgcf, seems only in 
> unit LE, I am just wondering should we put this part of code into 
> iiimcf, so both gtk and qt will be able to handle compose keys correctly?

UNIT has a capability of handling necessary composition, so just
passing through to UNIT would do the necessary operations for compose 
keys/dead keys.
We've recently encountered the problem that some keys seem not being
passed to libiiimcf regarding deadkey operation.

By using the LE specific hotkey, UNIT will designates Compose key and dead 
keys as hotkeys so that the composition can be done dynamically, while
conversion is off.

Is your suggestion to put the composition logic itself to libiiimcf?

Thanks!
Hideki
Permalink | Reply | 2 comments |
headers
Owen Taylor | 17 Nov 2004 19:09
Picon
Favicon
Subject: [openi18n-im:01125] Re: iiimcf/iiimgcf/compose keys

[openi18n-im:01125] Re: iiimcf/iiimgcf/compose keys

On Wed, 2004-11-17 at 09:23 -0800, Hideki Hiura wrote:
> Hi Shao,
> 
> > From: Yu Shao <yshao <at> redhat.com>
> > Right now, european dead keys are not handled in iiimgcf, seems only in 
> > unit LE, I am just wondering should we put this part of code into 
> > iiimcf, so both gtk and qt will be able to handle compose keys correctly?
> 
> UNIT has a capability of handling necessary composition, so just
> passing through to UNIT would do the necessary operations for compose 
> keys/dead keys.
> We've recently encountered the problem that some keys seem not being
> passed to libiiimcf regarding deadkey operation.
> 
> By using the LE specific hotkey, UNIT will designates Compose key and dead 
> keys as hotkeys so that the composition can be done dynamically, while
> conversion is off.
> 
> Is your suggestion to put the composition logic itself to libiiimcf?

I don't have the full background here, but I think the concern was when
the selected language engine was something other than UNIT ... a
Chinese, or Japanese language engine, say. 

Are (latin) dead keys and compose key handling expected to work when
conversion for such a language engine is off?

Regards,
						Owen
(Continue reading)

Permalink | Reply | 1 comment |

Gmane