Hi, On Tue, Dec 06, 2011 at 11:46:41AM +0900, Changwoo Ryu wrote: > 2011-12-06 (화), 00:22 +0900, Osamu Aoki: > > Package: imhangul-common > > Version: 1 > > Severity: normal > > > > This package ships im-config related package. That is wrong. Please > > send patch to im-config package (if needed NMU carefully). > > > > Any undocumented way of usage is prone for problem. > > > > In new 0.6, I added support for imhangul and other related packages. > > (Besides internal configuration file names and code has changed > > significantly...) > > Should im-config have all required configurations of the input methods > packages in Debian, rather than registering themselves by input methods?
Yes. > Then I think it is a wrong design choice. I understand one can make a valid argument. Since I may not be always up to date with each IM's internals. But this was sure way to quickly change from im-switch to im-config. This was a practical solution step at this moment for me. The first step is having a working solution which ensures to have both GTK2 and GTK3 installed before enabling them. You can not do it intuitively with im-switch. Also this ensures quick adoption of multiarch. If you have time, please check /usr/share/im-config/data/50_hangul.rc to see what I did for Korean is right choice. The code Oops, I have wrong comment text... s/gtk-im-libthai/imhangul-gtk2 and imhangul-gtk3/ I hope this start-up code is much more natural than the over engineered im-switch one. The other reason of centrarized data is ease of transition. Once we stabilize to be version 1.0, we can certainly discuss such idea. I think we need to at least impliment gettext translation. > Consistency in different packages will easily break. Hmmmm... Actually, we had and still have quite a bit of mess on *consistency* with im-switch. Different subpackage owner places their hook scripts and fight for the higher priority. Also there are some cross package interaction which makes it impossible to have linear ordering. (scim-pinyin and scim having hook script in each may have been the case I thought to be bad.) Managing such case was needed and instead of having many such -common packages, I made this to be a single point. > But if it is the current design, please NMU. OK. Osamu -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
