Hi,
Back from new year party ...
On Fri, Dec 23, 2011 at 07:45:01PM -0600, Jonathan Nieder wrote:
> Osamu Aoki wrote:
>
> > Also, for such input method plugins, we have a hook and configuration script
> > "im-config" to initialize such input method environment while starting X.
>
> Could you spell this out more? What environment variables will
> im-config set that include architecture names? Which architecture
> should they name --- the architecture of the /usr/bin/X binary?
The environment variables set by im-config include no architecture
names.
When im-config sets valid environment variables which change program
behavior of keyboard input data processing, it looks for available
libraries and make choices. These days, they reside in an architecture
dependent path. Such environment variables are:
GTK_IM_MODULE
QT4_IM_MODULE
CLUTTER_IM_MODULE
Currently, for fcitx, I use lazy check with * as (an shortened example):
| QT4_IM_MODULE=xim
| # use immodule when available for Qt4 (Qt3 has been long dead)
| for IM_CONFIG_MARKER in /usr/lib/*/qt4/plugins/inputmethods/qtim-fcitx.so \
| /usr/lib/qt4/plugins/inputmethods/qtim-fcitx.so ; do
| if [ -e $IM_CONFIG_MARKER ]; then
| QT4_IM_MODULE=fcitx
| break
| fi
| done
In plain English, this means:
When qtim-fcitx is not available for Qt4 to directly communicate with
keyboard, get keyboard data via classic xim and process then with fcitx
conversion engine:
QT4_IM_MODULE=xim
When qtim-fcitx is available for Qt4 to directly communicate with
keyboard, get keyboard data directly and process then with fcitx
conversion engine. This provides better user experience like on-the-spot
display of converted keyboard inputs:
QT4_IM_MODULE=fcitx
The above code may pick some false positives but is good enough until I
see "dpkg-architecture -qDEB_HOST_MULTIARCH" equivalent in non -dev
package.
> > To update im-config for multiarch, I would like to have access to following
> > commands without depending on the dpkg-dev package since user program
> > depending
> > on -dev package is weired:
> >
> > * current-library-path
> > equivalent of
^^^^^^^^^^
> > $ dpkg-architecture|sed -n 's/^DEB_HOST_MULTIARCH=\(.*\)/\1/p'
Vincent Danjean's suggestion was better idea but still require -dev package.
$ dpkg-architecture -qDEB_HOST_MULTIARCH
> When building a new program, "gcc -print-multiarch" seems to be the
> usual way.
Well this is done when user starts X. I do not think it is desirable to
add dependency to gcc.
> > * installed-library-path
> > list all library-path
> > I do not know how to get this reliably
>
> ld.so does not expose that information. However, you can search for a
> library used by a binary on the library path with "ldd".
If only you know which program is calling which library when you start
X. That is impossible since user can start any programs under X.
> [...]
> > On Thu, Dec 22, 2011 at 08:01:24PM +0100, Goswin von Brederlow wrote:
>
> >> This is something that could use some native english speaker to write a
> >> proposal/specs for with some examples where it is needed. Any takers?
> >
> > Yes.
> >
> > (I guess since we are talking spec, there is no tools such as apt-get nor
> > aptitude to manage such dependencies.)
>
> While the kind of interfaces you are talking about would be welcome, I
> don't think they are what Ian and Goswin were looking for. I think they
> wanted a way to tell the packaging system "This package (fakeroot)
> depends on this library (libfakeroot) from all enabled architectures",
> or "This package (something-input-method-related) depends on this
> library (some-input-method-plugin) from the same architecture as this
> other package (some-daemon-that-will-dlopen-it)".
The more I think about this, this input method setting environment
variables should be set only for the architecture X is started by
im-config.
Whoever wishes to set another architecture program on X, must use the
same input method environment or he manually set it in its start up.
(Debian does not have such tool yet but FEDORA seems to ship the
IMSettings tool to dynamically change such environment. Then it is
possible to run different input method library for different
architecture.) Installing required libraries are another complication
since not everyone needs input method.
Osamu
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120102184039.gc6...@goofy.lan
