Ricardo Wurmus <rek...@elephly.net> writes: > Chris Marusich <cmmarus...@gmail.com> writes: > >> Ricardo Wurmus <rek...@elephly.net> writes: >> >>> 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. >> >> Why don't you like their solution? Why do you believe that your >> proposed solution is better than their solution? We should make sure to >> choose the best solution available, and right now I'm not sure which one >> is better. > > I find it very inelegant to ask users to specify a list of directories > containing profiles. A mechanism like that also seems like a hack to > me, and I’m afraid that we would begin to rely more and more on this to > “solve” other problems. > > Splitting a variable that GTK is already using anyway into two different > versions just seems a lot cleaner to me. The variable won’t even need > to be exposed to most users; we could set it automatically when > generating profiles. > > Eventually this will disappear once the GTK devs retire support for > separate input method modules (I guess this would make IBus a hard > dependency on GNU systems). At that point we can easily drop our > patches and the profile hook; a generic GUIX_PROFILES variable, on the > other hand, would be more difficult to deprecate if it becomes more > popular (as it has a much broader scope).
That makes sense. I think these are good reasons to favor your solution instead of the NixOS solution. I think your plan is good. >>> 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. >> >> I believe you are referring to this thread: >> >> https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00046.html >> >> Did that patch actually get committed? If so, why didn't it solve the >> problem? I've read all the relevant discussions I could find [1], and >> it isn't clear to me why we need to do what you're suggesting ("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") if we've already committed the patch presented in the >> thread above. > > Yes, that patch got committed and it actually solved a problem. It is a > different problem, though. GTK really assumes modules to be in one > place, which means that with immutable directories we have no other way > to make things work. I see. I guess I just wasn't familiar with the other issue. Thank you for explaining. One last thing: it seems that the NixOS devs' choice of solution was influenced by a desire not to require users to rebuild programs that were previously installed in their profiles [1]. They almost chose a solution like the one you are proposing, but they changed their minds to avoid requiring users to rebuild existing programs in their profiles. GuixSD is still Beta, so I don't think that's an issue for us at all. [1] See abbradar's comment on April 8th, 2016: https://github.com/NixOS/nixpkgs/pull/14417#issuecomment-207362530 "This patch would break all such software that uses old (unpatched) GTK+3." This appears to be the primary reason why they chose to patch GTK+2 and GTK+3 to search NIX_PROFILES for an immodules.cache file instead of patching it to use separate environment variables for GTK+2 and GTK+3. -- Chris
signature.asc
Description: PGP signature
