choe.hwanjin - Project Hosting on Google Code

User Profile		Updates

Earlier this year Jan 02, 2010 ibus issue 720 (ibus hangul input - incorrect syllable transitions) commented on - Please make sure that you use ibus-hangul. Ubuntu does not install ibus-hangul by default. The default input method for hangul is not ibus-hangul. It is han2 from ibus-m17n. I think it's a problem of default setting for korean in ubuntu. Please make sure that you use ibus-hangul. Ubuntu does not install ibus-hangul by default. The default input method for hangul is not ibus-hangul. It is han2 from ibus-m17n. I think it's a problem of default setting for korean in ubuntu. Jan 02, 2010 ibus issue 720 (ibus hangul input - incorrect syllable transitions) commented on - Issue 721 has been merged into this issue. Issue 721 has been merged into this issue. Jan 02, 2010 ibus issue 721 (Hangeul characters disappear/reappear while typing ) changed - Status: Duplicate Status: Duplicate Jan 02, 2010 ibus issue 720 (ibus hangul input - incorrect syllable transitions) commented on - Please ensure that you use ibus-hangul. Ubuntu does not install ibus-hangul by default. The default input method for hangul is not ibus-hangul. It is han2 from ibus-m17n. I think it's a problem of default setting for korean in ubuntu. Please ensure that you use ibus-hangul. Ubuntu does not install ibus-hangul by default. The default input method for hangul is not ibus-hangul. It is han2 from ibus-m17n. I think it's a problem of default setting for korean in ubuntu. Jan 02, 2010 ibus issue 721 (Hangeul characters disappear/reappear while typing ) commented on - Please make sure that you use ibus-hangul. Ubuntu does not install ibus-hangul by default. The default input method for hangul is not ibus-hangul. It is han2 from ibus-m17n. I think it's a problem of default setting for korean in ubuntu. Please make sure that you use ibus-hangul. Ubuntu does not install ibus-hangul by default. The default input method for hangul is not ibus-hangul. It is han2 from ibus-m17n. I think it's a problem of default setting for korean in ubuntu. Jan 02, 2010 ibus ibus-hangul-1.2.0.20100102.tar.gz (ibus-hangul (한국어) source code) file uploaded - Labels: Type-Source OpSys-Linux Korean Labels: Type-Source OpSys-Linux Korean Older Dec 13, 2009 ibus issue 689 (ibus-hangul missing right Ctrl for Hanja button [From Red Ha...) changed - Many korean users use 103key korean keyboards, which don't show hanja candidates on Control_R on MS-Windows. And most users dislike such key mapping. So it's not good to add Control_R for hanja key as default. But, for US keyboard users, I added hanja key configuration to ibus-hangul setup dialog. Now you can select hanja key that you want to use. It was applied on commit 877036598ea68dedbf684e0ab76f50016af847cb For Hangul/English change key, ibus-hangul cannot control Hangul/English change key mapping. It's a configuration of ibus. And I recommend you not to set Alt_R as default language change key for the same reason above. Status: Fixed Owner: choe.hwanjin Many korean users use 103key korean keyboards, which don't show hanja candidates on Control_R on MS-Windows. And most users dislike such key mapping. So it's not good to add Control_R for hanja key as default. But, for US keyboard users, I added hanja key configuration to ibus-hangul setup dialog. Now you can select hanja key that you want to use. It was applied on commit 877036598ea68dedbf684e0ab76f50016af847cb For Hangul/English change key, ibus-hangul cannot control Hangul/English change key mapping. It's a configuration of ibus. And I recommend you not to set Alt_R as default language change key for the same reason above. Status: Fixed Owner: choe.hwanjin Dec 11, 2009 ibus issue 688 (ibus-hangul Hanja arrow keys are wrong [From Red Hat bugzill...) changed - Lookup table is user configurable, so the orientatin may vary for each user. It's more resonable that the arrow key behave differently according to lookup table orientation. I added some codes to make it aware of lookup table orientation. Now, left and right key move the cursor in horizontal mode, and move the page in vertical mode. Up and down key move the page in horizontal mode, and move the cursor in vertical mode. Fixed on commit 4b0d4c69c8f03c286e41b484f676d34275c85427 Status: Fixed Owner: choe.hwanjin Lookup table is user configurable, so the orientatin may vary for each user. It's more resonable that the arrow key behave differently according to lookup table orientation. I added some codes to make it aware of lookup table orientation. Now, left and right key move the cursor in horizontal mode, and move the page in vertical mode. Up and down key move the page in horizontal mode, and move the cursor in vertical mode. Fixed on commit 4b0d4c69c8f03c286e41b484f676d34275c85427 Status: Fixed Owner: choe.hwanjin Dec 05, 2009 ibus issue 678 (ibus-qt does not show attribute background color correctly.) Status changed - Status: New Status: New Dec 05, 2009 ibus issue 678 (ibus-qt does not show attribute background color correctly.) Owner changed - Owner: --- Owner: --- Dec 05, 2009 ibus issue 678 (ibus-qt does not show attribute background color correctly.) reported - What steps will reproduce the problem? 1. select ibus-hangul 2. input some text qt widget with ibus-qt 3. preedit text background is not black What is the expected output? What do you see instead? Expected: black background color Result: white background color It's a typo problem. I made a patch. What steps will reproduce the problem? 1. select ibus-hangul 2. input some text qt widget with ibus-qt 3. preedit text background is not black What is the expected output? What do you see instead? Expected: black background color Result: white background color It's a typo problem. I made a patch. Dec 05, 2009 ibus issue 654 (Last Korean character follows the space) commented on - It works now. It works now. Dec 04, 2009 ibus issue 654 (Last Korean character follows the space) commented on - I also have tested it with Kate. When I use XIM: Kate works fine. When I use ibus-qt: Type: g k s r m f <space> Result: "한글" Expected result: "한글 " It looks like Kate omit the last 'space' key. I think it may be the bug of Kate and Qt. I also have tested it with Kate. When I use XIM: Kate works fine. When I use ibus-qt: Type: g k s r m f <space> Result: "한글" Expected result: "한글 " It looks like Kate omit the last 'space' key. I think it may be the bug of Kate and Qt. Dec 04, 2009 ibus issue 654 (Last Korean character follows the space) commented on - Typing sequence: g k s r m f <space> Result: "한 글" Expected result: "한글 " when I use ibus with ibus-qt on Qt widget, it makes "한 글". Check it with QLineEdit not Kate. Kate may reimplement input context handling routine. I've tested it with ibus-hangul HEAD ibus HEAD ibus-qt HEAD qtdemo of qt4-4.5.3 Typing sequence: g k s r m f <space> Result: "한 글" Expected result: "한글 " when I use ibus with ibus-qt on Qt widget, it makes "한 글". Check it with QLineEdit not Kate. Kate may reimplement input context handling routine. I've tested it with ibus-hangul HEAD ibus HEAD ibus-qt HEAD qtdemo of qt4-4.5.3 Dec 04, 2009 ibus issue 654 (Last Korean character follows the space) commented on - I've checked this problem. It seems that the problem is in ibus-qt. It was reproduced only when I used ibus-qt plugin. But it didn't happen when I used ibus via XIM for Qt widget. Huang, please check the ibus-qt implementation. I've checked this problem. It seems that the problem is in ibus-qt. It was reproduced only when I used ibus-qt plugin. But it didn't happen when I used ibus via XIM for Qt widget. Huang, please check the ibus-qt implementation. Dec 04, 2009 repairer issue 2 (Spanish translation of nautilus-filename-repairer) changed - Thank you. I've just commited your new po file(revision 67). Status: Fixed Owner: choe.hwanjin Thank you. I've just commited your new po file(revision 67). Status: Fixed Owner: choe.hwanjin Dec 04, 2009 repairer r67 (update spanish translation ) committed - update spanish translation update spanish translation Nov 01, 2009 repairer nautilus-filename-repairer-0.0.6.tar.bz2 (nautilus filename repairer 0.0.6) file uploaded - Labels: Type-Source Labels: Type-Source Nov 01, 2009 repairer nautilus-filename-repairer-0.0.6.tar.gz (nautilus filename repairer 0.0.6) file uploaded - Labels: OpSys-Linux Type-Source Labels: OpSys-Linux Type-Source Nov 01, 2009 repairer r66 (tagging nautilus-filename-repairer 0.0.6 release ) committed - tagging nautilus-filename-repairer 0.0.6 release tagging nautilus-filename-repairer 0.0.6 release Nov 01, 2009 repairer r65 (release 0.0.6 ) committed - release 0.0.6 release 0.0.6 Nov 01, 2009 repairer r64 (update document ) committed - update document update document Nov 01, 2009 repairer r63 (update documents ) committed - update documents update documents Nov 01, 2009 repairer r62 (add a rule to generate ChangeLog when the dist package is cr...) committed - add a rule to generate ChangeLog when the dist package is created add a rule to generate ChangeLog when the dist package is created Nov 01, 2009 repairer r61 (update po files ) committed - update po files update po files Oct 31, 2009 repairer r60 (update error handling message dialog routine ) committed - update error handling message dialog routine update error handling message dialog routine Oct 31, 2009 repairer r59 (Update library dependency. * use GIO * use new version of ...) committed - Update library dependency. * use GIO * use new version of libnautilus-extension * don't use libgnome (now we don't need workaround code) * remove version checking scripts. Update library dependency. * use GIO * use new version of libnautilus-extension * don't use libgnome (now we don't need workaround code) * remove version checking scripts. Oct 31, 2009 repairer r58 (We don't need workaround code anymore because now we use na...) committed - We don't need workaround code anymore because now we use nautilus 2.22.0 or upper version. --이 줄 이하 자동으로 제거됩니다-- M src/nautilus-filename-repairer.c We don't need workaround code anymore because now we use nautilus 2.22.0 or upper version. --이 줄 이하 자동으로 제거됩니다-- M src/nautilus-filename-repairer.c Oct 31, 2009 repairer issue 1 (Migrate to gio) Status changed - I've updated the source code as repair uses GIO. rev57. Status: Fixed I've updated the source code as repair uses GIO. rev57. Status: Fixed Oct 31, 2009 repairer r57 (migrating to GIO * use GIO instead of Gnome VFS which is no...) committed - migrating to GIO * use GIO instead of Gnome VFS which is not used anymore in Nautilus. * issue #1 Migrate to gio from http://kldp.net/tracker/index.php?func=detail&aid=305177&group_id=1205&atid=353052 migrating to GIO * use GIO instead of Gnome VFS which is not used anymore in Nautilus. * issue #1 Migrate to gio from http://kldp.net/tracker/index.php?func=detail&aid=305177&group_id=1205&atid=353052 Oct 31, 2009 repairer issue 1 (Migrate to gio) reported - from KLDP.net http://kldp.net/tracker/index.php?func=detail&aid=305177&group_id=1205&atid=353052 Serkan Kaba (serkan) wrote: Please migrate to from gnomevfs to GIO api introduced in newer glib. Here's a migration document that can be used. http://library.gnome.org/devel/gio/unstable/ch15.html Thanks. from KLDP.net http://kldp.net/tracker/index.php?func=detail&aid=305177&group_id=1205&atid=353052 Serkan Kaba (serkan) wrote: Please migrate to from gnomevfs to GIO api introduced in newer glib. Here's a migration document that can be used. http://library.gnome.org/devel/gio/unstable/ch15.html Thanks. Oct 31, 2009 ibus issue 578 (Korean input does not function on Western keyboards) Status changed - I've released ibus-hangul new version 1.2.0.20091031. It has new feature of hangul romaja method. You can use romaja method by selecting 'Romaja' in Setting window. Status: Fixed I've released ibus-hangul new version 1.2.0.20091031. It has new feature of hangul romaja method. You can use romaja method by selecting 'Romaja' in Setting window. Status: Fixed Oct 31, 2009 ibus ibus-hangul-1.2.0.20091031.tar.gz (ibus-hangul (한국어) source code) file uploaded - Labels: Korean 1.2 Labels: Korean 1.2 Oct 12, 2009 ibus issue 578 (Korean input does not function on Western keyboards) commented on - Most native korean don't use romaja method. So it is not important. Anyway I will add romaja method to libhangul. In the meantime, we can provide romaja method by ibus-table. Most native korean don't use romaja method. So it is not important. Anyway I will add romaja method to libhangul. In the meantime, we can provide romaja method by ibus-table. Oct 12, 2009 ibus issue 578 (Korean input does not function on Western keyboards) commented on - SCIM's hangul romaja method is supported by scim-tables method not scim-hangul. It has HangulRomaja method. You may convert SCIM's hangul-romaja table to ibus-table's format. SCIM's hangul romaja method is supported by scim-tables method not scim-hangul. It has HangulRomaja method. You may convert SCIM's hangul-romaja table to ibus-table's format. Oct 11, 2009 ibus issue 578 (Korean input does not function on Western keyboards) commented on - Current version of libhangul does not support hangul-romaja method. So it will take some time to support romaja method in ibus-hangul. Current version of libhangul does not support hangul-romaja method. So it will take some time to support romaja method in ibus-hangul. Mar 29, 2009 ibus issue 318 (Using different trigger keys for each language engines.) commented on - Answer to the previous question: 1. b 2. b (and c) I don't have much idea about switching between language engines. Getting several trigger keys and switching between language engines are different problem. I didn't specifiy any method to switching between language engines in my proposal. Anyway, I'm explain again about my idea. Let's make several 'engine set' which share the trigger keys. Then we can rewrite above example configs as follows: [1st engine set] trigger keys = ctrl+space ibus-default ibus-pinyin [2nd engine set] trigger keys = shift+space ibus-default ibus-hangul [3rd engine set] trigger keys = ctrl+shift ibus-pinyin ibus-hangul ibus-anthy A user can add a new engine set or more. A user can add an engine or engines to any engine set. Then a user may add 4th engine set which have a list of all engines that are installed. A user can enable 1st engine set by pressing trigger key of 1st engine set. I don't know which engine should be enabled when the 1st engine set is enabled. It may enable engines in 1st engine set in turn or just current selected one. (You may want to change current engine to another in 1st engine set by 'ctrl+shift') A user can enable 2nd engine set by pressing trigger key of 2nd engine set. Same as 1st set case. If a user wants to use ibus-hangul with ctrl-space, he/she can add ibus-hangul to 1st engine set. Then ibus-hangul can be enabled by ctrl+space and shift+space. Answer to the previous question: 1. b 2. b (and c) I don't have much idea about switching between language engines. Getting several trigger keys and switching between language engines are different problem. I didn't specifiy any method to switching between language engines in my proposal. Anyway, I'm explain again about my idea. Let's make several 'engine set' which share the trigger keys. Then we can rewrite above example configs as follows: [1st engine set] trigger keys = ctrl+space ibus-default ibus-pinyin [2nd engine set] trigger keys = shift+space ibus-default ibus-hangul [3rd engine set] trigger keys = ctrl+shift ibus-pinyin ibus-hangul ibus-anthy A user can add a new engine set or more. A user can add an engine or engines to any engine set. Then a user may add 4th engine set which have a list of all engines that are installed. A user can enable 1st engine set by pressing trigger key of 1st engine set. I don't know which engine should be enabled when the 1st engine set is enabled. It may enable engines in 1st engine set in turn or just current selected one. (You may want to change current engine to another in 1st engine set by 'ctrl+shift') A user can enable 2nd engine set by pressing trigger key of 2nd engine set. Same as 1st set case. If a user wants to use ibus-hangul with ctrl-space, he/she can add ibus-hangul to 1st engine set. Then ibus-hangul can be enabled by ctrl+space and shift+space. Mar 23, 2009 ibus issue 318 (Using different trigger keys for each language engines.) commented on - > No, it is not. Ctrl-Space (and Shift-Space if you like) is meant to switch between > the default IME and English, > while Ctrl-Shift switch between IMEs. I maybe wrong, but from my impression it is > pretty close to what you describe. Yes, you can use ctrl+shift for language engine switching. But, this is not about the language engine switching keys. This is about multi trigger keys. Eventually, multi trigger key may serve the similar feature to change language engine. Language engine switching key may need or need not. But this feature is for solving conflict trigger keys between several languages. > A great idea. Actually back to DOS era we do the similar among Chinese input methods, > Ctrl-Alt-1 for Cangjie, Ctrl-Atl-2 for Easy Cangjie, Ctrl-Atl-3 for Zhuyin, and so > on. But please bear in mind that iBus is designed as internationalized input method, > which imply there might be Indic (which is already there), Vietnamese, German, > French, and other language we might not be aware of. They might be somewhat > disappointed if their language is not in default list. You don't understand my idea. Above list should be updated when the new engine is installed. There is not such hard-coded default engine list. The important point is that the trigger key is registered by the engine not the framework. So if the user install another language engine, new trigger keys which are used to natives are automatically registered by the new engine. On current system, user should add their trigger keys or system should have the every kind of trigger key first. Think about that, if there may be a new language engine in the future and we still don't know what trigger key the engine will want to use, the framework can't provide the correct trigger key. But if the engine can register the trigger key then we don't need to worry about that. > No, it is not. Ctrl-Space (and Shift-Space if you like) is meant to switch between > the default IME and English, > while Ctrl-Shift switch between IMEs. I maybe wrong, but from my impression it is > pretty close to what you describe. Yes, you can use ctrl+shift for language engine switching. But, this is not about the language engine switching keys. This is about multi trigger keys. Eventually, multi trigger key may serve the similar feature to change language engine. Language engine switching key may need or need not. But this feature is for solving conflict trigger keys between several languages. > A great idea. Actually back to DOS era we do the similar among Chinese input methods, > Ctrl-Alt-1 for Cangjie, Ctrl-Atl-2 for Easy Cangjie, Ctrl-Atl-3 for Zhuyin, and so > on. But please bear in mind that iBus is designed as internationalized input method, > which imply there might be Indic (which is already there), Vietnamese, German, > French, and other language we might not be aware of. They might be somewhat > disappointed if their language is not in default list. You don't understand my idea. Above list should be updated when the new engine is installed. There is not such hard-coded default engine list. The important point is that the trigger key is registered by the engine not the framework. So if the user install another language engine, new trigger keys which are used to natives are automatically registered by the new engine. On current system, user should add their trigger keys or system should have the every kind of trigger key first. Think about that, if there may be a new language engine in the future and we still don't know what trigger key the engine will want to use, the framework can't provide the correct trigger key. But if the engine can register the trigger key then we don't need to worry about that. Mar 23, 2009 ibus issue 318 (Using different trigger keys for each language engines.) commented on - With this multi trigger key system, the current single trigger key system can be imitated by registering only one trigger key: trigger key 1: ctrl+space, shift+space, hangul key, kana key ibus-default ibus-pinyin ibus-hangul ibus-anty ibus-another (list every registered engine) With this multi trigger key system, the current single trigger key system can be imitated by registering only one trigger key: trigger key 1: ctrl+space, shift+space, hangul key, kana key ibus-default ibus-pinyin ibus-hangul ibus-anty ibus-another (list every registered engine) Mar 23, 2009 ibus issue 318 (Using different trigger keys for each language engines.) commented on - The current 'monolithic trigger key' system also has the same problem. But in new multi trigger key system, it is possible to select several language engine by several keys. For example, think settings like this: trigger key 1: ctrl+shift+F1, ctrl+space ibus-default ibus-chinese trigger key 1: ctrl+shift+F2 ibus-korean trigger key 1:ctrl+shift+F3 ibus-anthy A user can change her/his language engine by press ctrl+shift+F[1-3]. In this case, a user can sure which is the current language engine when she/he press the trigger key. Individual engine developer don't need to care about other engines. Each engine registers their default trigger keys which is widely used in their language desktop environment. So the general users don't need to reconfigure the input system to use the trigger key which they are used to. And users may change the default trigger key also. However, the multi language users can select their trigger key for the language engine. If they want to use shift+space as full/half shape toggle key, they can remove the shift-space key engines from the shift+space engine list like this: trigger key 1: ctrl+space ibus-default ibus-chinese trigger key 2: shift+space (empty) trigger key 3: hangul key ... trigger key 4: kana key ... or completely remove the trigger key 2. And shift+space key never be used as a trigger key if he/she don't install a language engine which has shift+space as the default trigger key. The current 'monolithic trigger key' system also has the same problem. But in new multi trigger key system, it is possible to select several language engine by several keys. For example, think settings like this: trigger key 1: ctrl+shift+F1, ctrl+space ibus-default ibus-chinese trigger key 1: ctrl+shift+F2 ibus-korean trigger key 1:ctrl+shift+F3 ibus-anthy A user can change her/his language engine by press ctrl+shift+F[1-3]. In this case, a user can sure which is the current language engine when she/he press the trigger key. Individual engine developer don't need to care about other engines. Each engine registers their default trigger keys which is widely used in their language desktop environment. So the general users don't need to reconfigure the input system to use the trigger key which they are used to. And users may change the default trigger key also. However, the multi language users can select their trigger key for the language engine. If they want to use shift+space as full/half shape toggle key, they can remove the shift-space key engines from the shift+space engine list like this: trigger key 1: ctrl+space ibus-default ibus-chinese trigger key 2: shift+space (empty) trigger key 3: hangul key ... trigger key 4: kana key ... or completely remove the trigger key 2. And shift+space key never be used as a trigger key if he/she don't install a language engine which has shift+space as the default trigger key. Mar 22, 2009 ibus issue 318 (Using different trigger keys for each language engines.) changed - Status: New Owner: --- Status: New Owner: --- Mar 22, 2009 ibus issue 318 (Using different trigger keys for each language engines.) reported - We still suffering from lack of a feature to change input method. For koreans, we need trigger key as shift+space or hangul key, for chinese, ctrl+space, for japanese, shift-space or kana key. Current solution is to register every trigger key and enable a input method engine when the trigger key is pressed and change input method engine to another when needed. But let's think about that in a slightly different way. If each input method engine can have its own trigger keys, framework can toggle the specified engine when the matched trigger key is pressed. Then we can assign different trigger keys to different language engines. Let's think of an example. ibus-pinyin registers toggle key as ctrl+space. ibus-hangul registers toggle key as shift+space and hangul key. ibus-anthy registers toggle key as shift+space and kana key. If a user press ctrl+space, ibus-pinyin will be enabled, then the user can press hangul key, this time ibus-hangul will be enabled. After that, if the user press kana key, then ibus-anthy will be enabled. Of course, pressing ctrl+space twice will toggle ibus-pinyin engine However, the shift+space is conflict. The language engine may be enabled in turn. But, in most cases, users don't install ibus-hangul and ibus-anthy at the same time. So it is not so critical. Framework may provide some options to select language engines for a toggle key. Then, a user can select several engines for a toggle key. Something like this: toggle key: ctrl+space ibus-default ibus-pinyin toggle key: shift+space ibus-default ibus-hangul ibus-anthy toggle key: hangul ibus-default ibus-hangul toggle key: kana ibus-default ibus-anthy ibus-default will be the default language engine so that the user can change the default engine from english. We still suffering from lack of a feature to change input method. For koreans, we need trigger key as shift+space or hangul key, for chinese, ctrl+space, for japanese, shift-space or kana key. Current solution is to register every trigger key and enable a input method engine when the trigger key is pressed and change input method engine to another when needed. But let's think about that in a slightly different way. If each input method engine can have its own trigger keys, framework can toggle the specified engine when the matched trigger key is pressed. Then we can assign different trigger keys to different language engines. Let's think of an example. ibus-pinyin registers toggle key as ctrl+space. ibus-hangul registers toggle key as shift+space and hangul key. ibus-anthy registers toggle key as shift+space and kana key. If a user press ctrl+space, ibus-pinyin will be enabled, then the user can press hangul key, this time ibus-hangul will be enabled. After that, if the user press kana key, then ibus-anthy will be enabled. Of course, pressing ctrl+space twice will toggle ibus-pinyin engine However, the shift+space is conflict. The language engine may be enabled in turn. But, in most cases, users don't install ibus-hangul and ibus-anthy at the same time. So it is not so critical. Framework may provide some options to select language engines for a toggle key. Then, a user can select several engines for a toggle key. Something like this: toggle key: ctrl+space ibus-default ibus-pinyin toggle key: shift+space ibus-default ibus-hangul ibus-anthy toggle key: hangul ibus-default ibus-hangul toggle key: kana ibus-default ibus-anthy ibus-default will be the default language engine so that the user can change the default engine from english. Mar 07, 2009 ibus issue 304 (IBusConfig does not call "value-changed" callback) reported - I'm testing ibus-hangul engine code. I wrote the code like below: ... connection = ibus_bus_get_connection (bus); config = ibus_config_new (connection); g_signal_connect (config, "value-changed", G_CALLBACK(ibus_config_value_changed), NULL); ... And I changed the value of config item "/desktop/ibus/engine/Hangul/HangulKeyboard". I used gconf-editor to change the config item value. But the callback fuction ibus_config_value_changed() wasn't called. I tested it on python implementation also, and it worked. It seems that there is a bug in IBusConfig C implementation. Ibus Hangul engine already has the code above, so you can test it with Ibus Hangul code. And it has setup tool also. You can change the value easily. Lookup my ibus-hangul git repository: http://github.com/choehwanjin/ibus-hangul/tree/master I'm testing ibus-hangul engine code. I wrote the code like below: ... connection = ibus_bus_get_connection (bus); config = ibus_config_new (connection); g_signal_connect (config, "value-changed", G_CALLBACK(ibus_config_value_changed), NULL); ... And I changed the value of config item "/desktop/ibus/engine/Hangul/HangulKeyboard". I used gconf-editor to change the config item value. But the callback fuction ibus_config_value_changed() wasn't called. I tested it on python implementation also, and it worked. It seems that there is a bug in IBusConfig C implementation. Ibus Hangul engine already has the code above, so you can test it with Ibus Hangul code. And it has setup tool also. You can change the value easily. Lookup my ibus-hangul git repository: http://github.com/choehwanjin/ibus-hangul/tree/master Jan 18, 2009 repairer nautilus-filename-repairer-0.0.5.tar.bz2 (nautilus filename repairer 0.0.5) file uploaded - Labels: Type-Source Labels: Type-Source Jan 18, 2009 repairer nautilus-filename-repairer-0.0.5.tar.gz (nautilus filename repairer 0.0.5) file uploaded - Labels: Type-Source Labels: Type-Source Jan 18, 2009 repairer nautilus-filename-repairer-0.0.4.tar.bz2 (nautilus filename repairer 0.0.4) file uploaded - Labels: Type-Source Deprecated Labels: Type-Source Deprecated Jan 18, 2009 repairer nautilus-filename-repairer-0.0.4.tar.gz (nautilus filename repairer 0.0.4) file uploaded - Labels: Type-Source Deprecated Labels: Type-Source Deprecated Jan 18, 2009 repairer nautilus-filename-repairer-0.0.3.tar.bz2 (nautilus filename repairer 0.0.3) file uploaded - Labels: Type-Source Deprecated Labels: Type-Source Deprecated Jan 18, 2009 repairer nautilus-filename-repairer-0.0.3.tar.gz (nautilus filename repairer 0.0.3) file uploaded - Labels: Type-Source Deprecated Labels: Type-Source Deprecated Jan 18, 2009 repairer nautilus-filename-repairer-0.0.2.tar.bz2 (nautilus filename repairer 0.0.2) file uploaded - Labels: Type-Source Deprecated Labels: Type-Source Deprecated

issue 318 (Using different trigger keys for each language engines.) commented on - > No, it is not. Ctrl-Space (and Shift-Space if you like) is meant to switch between > the default IME and English, > while Ctrl-Shift switch between IMEs. I maybe wrong, but from my impression it is > pretty close to what you describe. Yes, you can use ctrl+shift for language engine switching. But, this is not about the language engine switching keys. This is about multi trigger keys. Eventually, multi trigger key may serve the similar feature to change language engine. Language engine switching key may need or need not. But this feature is for solving conflict trigger keys between several languages. > A great idea. Actually back to DOS era we do the similar among Chinese input methods, > Ctrl-Alt-1 for Cangjie, Ctrl-Atl-2 for Easy Cangjie, Ctrl-Atl-3 for Zhuyin, and so > on. But please bear in mind that iBus is designed as internationalized input method, > which imply there might be Indic (which is already there), Vietnamese, German, > French, and other language we might not be aware of. They might be somewhat > disappointed if their language is not in default list. You don't understand my idea. Above list should be updated when the new engine is installed. There is not such hard-coded default engine list. The important point is that the trigger key is registered by the engine not the framework. So if the user install another language engine, new trigger keys which are used to natives are automatically registered by the new engine. On current system, user should add their trigger keys or system should have the every kind of trigger key first. Think about that, if there may be a new language engine in the future and we still don't know what trigger key the engine will want to use, the framework can't provide the correct trigger key. But if the engine can register the trigger key then we don't need to worry about that.

> No, it is not. Ctrl-Space (and Shift-Space if you like) is meant to switch between > the default IME and English, > while Ctrl-Shift switch between IMEs. I maybe wrong, but from my impression it is > pretty close to what you describe. Yes, you can use ctrl+shift for language engine switching. But, this is not about the language engine switching keys. This is about multi trigger keys. Eventually, multi trigger key may serve the similar feature to change language engine. Language engine switching key may need or need not. But this feature is for solving conflict trigger keys between several languages. > A great idea. Actually back to DOS era we do the similar among Chinese input methods, > Ctrl-Alt-1 for Cangjie, Ctrl-Atl-2 for Easy Cangjie, Ctrl-Atl-3 for Zhuyin, and so > on. But please bear in mind that iBus is designed as internationalized input method, > which imply there might be Indic (which is already there), Vietnamese, German, > French, and other language we might not be aware of. They might be somewhat > disappointed if their language is not in default list. You don't understand my idea. Above list should be updated when the new engine is installed. There is not such hard-coded default engine list. The important point is that the trigger key is registered by the engine not the framework. So if the user install another language engine, new trigger keys which are used to natives are automatically registered by the new engine. On current system, user should add their trigger keys or system should have the every kind of trigger key first. Think about that, if there may be a new language engine in the future and we still don't know what trigger key the engine will want to use, the framework can't provide the correct trigger key. But if the engine can register the trigger key then we don't need to worry about that.

Earlier this year

Older