From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Trying to fix IBus Date: Wed, 10 Aug 2016 23:09:21 +0200 Message-ID: <87lh04covy.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXakk-0002xl-H6 for guix-devel@gnu.org; Wed, 10 Aug 2016 17:09:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXakg-000342-9k for guix-devel@gnu.org; Wed, 10 Aug 2016 17:09:29 -0400 Received: from sender163-mail.zoho.com ([74.201.84.163]:24361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXakg-00033i-1W for guix-devel@gnu.org; Wed, 10 Aug 2016 17:09:26 -0400 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel Hi Guix, IBus is still broken. That’s primarily because we don’t generate an input method modules cache file that GTK+ looks for. The cache file for GTK3 can be generated with gtk-query-immodules-3.0 /path/to/profile Then we point the environment variable GTK_IM_MODULE_FILE to the file. I tried this, rebooted, and noticed that now any GTK2 application crashes. That’s because GTK_IM_MODULE_FILE is used by both major GTK versions, but the input method modules are not compatible with both versions. NixOS encountered the same problem: https://github.com/NixOS/nixpkgs/pull/14568 I don’t like their solution to set a variable NIX_PROFILES and let GTK look for immodule files in each of the directories. Instead, I think we should patch both GTK versions to respect GUIX_GTK2_IM_MODULE_FILE and GUIX_GTK3_IM_MODULE_FILE, and generate the immodule cache files in a profile hook. We did something similar before with GUIX_GTK2_PATH and GUIX_GTK3_PATH. Upstream doesn’t want to accept patches like this because they are moving away from dynamically switchable input method modules. Instead they will just support a single input method system per platform. This means that ultimately we will be able to drop these patches. What do you think? Is this acceptable/reasonable? ~~ Ricardo