Bug#644254: im-config: problems in IM Module settings

2011-10-07 Thread Osamu Aoki
Hi,

Please clarify.

Your patch :
  for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so 
  /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so ; do
  for IM_CONFIG_MARKER in /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 
  /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so ; do

I see only /usr/lib32/ directory on my amd64.

Please confirm you did not mean:
  for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so 
  /usr/lib*/gtk-2.0/*/immodules/im-ibus.so ; do
  for IM_CONFIG_MARKER in /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 
  /usr/lib*/qt4/plugins/inputmethods/libqtim-ibus.so ; do

Regards,

Osamu




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#644254: im-config: problems in IM Module settings

2011-10-07 Thread Aron Xu
On Fri, Oct 7, 2011 at 21:48, Osamu Aoki os...@debian.org wrote:
 Hi,

 Please clarify.

 Your patch :
  for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so 
  /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so ; do
  for IM_CONFIG_MARKER in /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 
  /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so ; do

 I see only /usr/lib32/ directory on my amd64.


/usr/lib32/ comes from ia32-libs, which is to be removed after
Multi-Arch is okay, and Ubuntu 11.10 has already done this.

Multi-Arch libraries will be installed at architecture dependent
locations like /usr/lib/i386-gnu-linux/, /usr/lib/x86_64-linux-gnu/ ,
etc. Using /usr/lib/*/ is the recommended approach to cover all the
possibilities. See details at:
http://wiki.debian.org/Multiarch/TheCaseForMultiarch

 Please confirm you did not mean:
  for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so 
  /usr/lib*/gtk-2.0/*/immodules/im-ibus.so ; do
  for IM_CONFIG_MARKER in /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 
  /usr/lib*/qt4/plugins/inputmethods/libqtim-ibus.so ; do


The patch does not need modification, as explained above. See:
http://packages.debian.org/sid/amd64/libgtk2.0-0/filelist
http://packages.ubuntu.com/oneiric/i386/libqtcore4/filelist


-- 
Regards,
Aron Xu



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#644254: im-config: problems in IM Module settings

2011-10-07 Thread Osamu Aoki
Hi,

On Fri, Oct 07, 2011 at 10:34:32PM +0800, Aron Xu wrote:
 The patch does not need modification, as explained above. See:
 http://packages.debian.org/sid/amd64/libgtk2.0-0/filelist
 http://packages.ubuntu.com/oneiric/i386/libqtcore4/filelist

Right.  I now recall seeing .. triplet /i386-linux-gnu/ at 
debian-devel discussion.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#644254: im-config: problems in IM Module settings

2011-10-05 Thread Osamu Aoki
Hi,


On Wed, Oct 05, 2011 at 07:37:01AM +0800, Aron Xu wrote:
 On Wed, Oct 5, 2011 at 04:25, Osamu Aoki os...@debian.org wrote:
  [...]
  By the way, where is doc on how to use version specific QT4_IM_MODULE,
  GTK2_IM_MODULE or GKT3_IM_MODULE?
 
 
 QT4_IM_MODULE was added in QT 4.5.0, see:
 http://qt.nokia.com/products/changes/changes-4.5.0/
 In Squeeze, the version of libqt4* is 4.6.3, so there is no problem as
 far as I can see.
 
 It works like QT4_IM_MODULE=ibus
 
 There is no variables like GTK2_IM_MODULE or GKT3_IM_MODULE to the
 best of my knowledge, and after some small tests I am confident that
 these two variables don't exist. We may contact the GTK package
 maintainer and/or file an upstream bug report, to add a GTK3_IM_MODULE
 variable.

It sounds like good idea.  
 
  Further more, we should deal with Multi-Arch of those libraries, which 
  means:
   for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so 
   /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so ; do
  and
   for IM_CONFIG_MARKER in 
   /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 
   /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so ; do
 
  This is needed because transition to Mult-Arch is in progress, we need
  to take care of all the situations.
 
  Multi-Arch is black magic for me now. patch welcomed.
 
  Osamu
 
 
 I'll do this for you in a few days.

Let's fix ibus case first then follow other IMs.

 -- 
 Regards,
 Aron Xu



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#644254: im-config: problems in IM Module settings

2011-10-04 Thread Aron Xu
Package: im-config
Version: 0.4
Severity: serious
X-Debbugs-CC: pkg-ime-de...@lists.alioth.debian.org

Dear maintainer,

After doing some research, we found that current IM Module settings
have some severe problems:

In 20_ibus.im:
 GTK_IM_MODULE=xim
 # use immodule when available for GTK
 for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so ; do
 if [ -e $IM_CONFIG_MARKER ]; then
 GTK_IM_MODULE=ibus
 fi
 done

Here it means when GTK2 IM Module is present, GTK_IM_MODULE will be
set to ibus. But when there are GTK3 applications present in the
system, while at the same time GTK3 IM MODULE isn't, user cannot input
anything in those GTK3 applications. We were expecting that when the
IM Module does not exist it will fallback to XIM, but it simply
doesn't work - we may need to file another bug and/or contact upstream
if appropriate, but we should deal with it by applying some workaround
at least.

Tested that GTK2_IM_MODULE or GKT3_IM_MODULE does not exist.

Another similar but smaller issue, in 20_ibus.im:
 QT_IM_MODULE=xim
 # use immodule when available for QT
 for IM_CONFIG_MARKER in /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so ; do
 if [ -e $IM_CONFIG_MARKER ]; then
 QT_IM_MODULE=ibus
 fi
 done

When QT4 IM Module is present, then set QT_IM_MODULE=ibus. But what if
there are QT3 applications like K3b? Should we use QT4_IM_MODULE
instead?


Further more, we should deal with Multi-Arch of those libraries, which means:
 for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so 
 /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so ; do
and
 for IM_CONFIG_MARKER in /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 
 /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so ; do

This is needed because transition to Mult-Arch is in progress, we need
to take care of all the situations.

-- 
Regards,
Aron Xu



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#644254: im-config: problems in IM Module settings

2011-10-04 Thread Osamu Aoki
Hi,

On Tue, Oct 04, 2011 at 09:56:53PM +0800, Aron Xu wrote:
 Package: im-config
 Version: 0.4
 Severity: serious
 X-Debbugs-CC: pkg-ime-de...@lists.alioth.debian.org
 
 Dear maintainer,
 
 After doing some research, we found that current IM Module settings
 have some severe problems:
 
 In 20_ibus.im:
  GTK_IM_MODULE=xim
  # use immodule when available for GTK
  for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so ; do
  if [ -e $IM_CONFIG_MARKER ]; then
  GTK_IM_MODULE=ibus
  fi
  done
 
 Here it means when GTK2 IM Module is present, GTK_IM_MODULE will be
 set to ibus. But when there are GTK3 applications present in the
 system, while at the same time GTK3 IM MODULE isn't, user cannot input
 anything in those GTK3 applications. 

TRUE.

We were expecting that when the
 IM Module does not exist it will fallback to XIM, but it simply
 doesn't work - we may need to file another bug and/or contact upstream
 if appropriate, but we should deal with it by applying some workaround
 at least.
 
 Tested that GTK2_IM_MODULE or GKT3_IM_MODULE does not exist.
 
 Another similar but smaller issue, in 20_ibus.im:
  QT_IM_MODULE=xim
  # use immodule when available for QT
  for IM_CONFIG_MARKER in /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so ; 
  do
  if [ -e $IM_CONFIG_MARKER ]; then
  QT_IM_MODULE=ibus
  fi
  done
 
 When QT4 IM Module is present, then set QT_IM_MODULE=ibus. But what if
 there are QT3 applications like K3b? Should we use QT4_IM_MODULE
 instead?

YES.  

By the way, where is doc on how to use version specific QT4_IM_MODULE,
GTK2_IM_MODULE or GKT3_IM_MODULE?

 Further more, we should deal with Multi-Arch of those libraries, which means:
  for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so 
  /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so ; do
 and
  for IM_CONFIG_MARKER in /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 
  /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so ; do
 
 This is needed because transition to Mult-Arch is in progress, we need
 to take care of all the situations.

Multi-Arch is black magic for me now. patch welcomed.

Osamu



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#644254: im-config: problems in IM Module settings

2011-10-04 Thread Aron Xu
On Wed, Oct 5, 2011 at 04:25, Osamu Aoki os...@debian.org wrote:
 [...]
 By the way, where is doc on how to use version specific QT4_IM_MODULE,
 GTK2_IM_MODULE or GKT3_IM_MODULE?


QT4_IM_MODULE was added in QT 4.5.0, see:
http://qt.nokia.com/products/changes/changes-4.5.0/
In Squeeze, the version of libqt4* is 4.6.3, so there is no problem as
far as I can see.

It works like QT4_IM_MODULE=ibus

There is no variables like GTK2_IM_MODULE or GKT3_IM_MODULE to the
best of my knowledge, and after some small tests I am confident that
these two variables don't exist. We may contact the GTK package
maintainer and/or file an upstream bug report, to add a GTK3_IM_MODULE
variable.

 Further more, we should deal with Multi-Arch of those libraries, which means:
  for IM_CONFIG_MARKER in /usr/lib/gtk-2.0/*/immodules/im-ibus.so 
  /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so ; do
 and
  for IM_CONFIG_MARKER in /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so 
  /usr/lib/*/qt4/plugins/inputmethods/libqtim-ibus.so ; do

 This is needed because transition to Mult-Arch is in progress, we need
 to take care of all the situations.

 Multi-Arch is black magic for me now. patch welcomed.

 Osamu


I'll do this for you in a few days.

-- 
Regards,
Aron Xu



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org