Re: gtk.immodules generation in cross-compile systems

[Owen Taylor <otaylor redhat com>]

Tor Lillqvist <tml iki fi> writes:

> J. Ali Harlow writes:
>  > The built gtk-query-immodules-2.0 runs quite happily but produces
>  > output that differs from Tor's version in a number of respects:
> 
> The gtk.immodules I distribute is hand-edited... the /target/blahblah
> prefixes are edited there so that the code recognizes the compile-time
> prefix and knows to replace it with the run-time installation prefix.
> 
> I think the intention hardly was that a gtk.immodules file intended
> for inclusion in a binary distribution would be generated in a
> distribution-ready form by running gtk-query-immodules. I rather think
> that distribution builders are expected to set it up "manually",
> perhaps even automatically editing it at install-time depending on
> what locales and/or input methods the end-user has chosen to install
> on a particular machine.

gtk.immodules was intended _entirely_ as a cache file to avoid
having to query the input modules on program startup; the
idea for Unix/Linux is the contents can always be regenerated
with:

 gtk-query-immodules-2.0 > /etc/gtk/gtk.immodules

Regeneration is necessary if, say, a third party input method
module was installed.

Binary packages (at least correct packages) on Linux/Unix don't include 
the immodules file but generate it at install time.

While it's up to Tor to determine what's right for GTK+ on Win32; 
I think it would certainly be better if gtk-query-immodules
generated the correct output.

Regards,
                                        Owen