Meld displays nothing in right pane when comparing directories

[mhwombat]

Describe the bug

The meld command displays nothing in the right pane when comparing folders. It was working fine until recently. I'm not sure when I last used meld, but I suspect the problem started sometime in the last few months.

To Reproduce Steps to reproduce the behavior:

$ rm -rf a b
mkdir a
echo "hello" > a/hello.txt
mkdir b
echo "hello again" > b/hello.txt
meld a b

The contents of the a folder are displayed in the left pane, but the right pane is empty.

Expected behavior

I expect the contents of the a folder to be displayed in the left pane, and the contents of the b folder to be displayed in the right pane.

Screenshots

A screenshot is attached.

Additional context

Here is the output of the meld command.

$ meld a b
Traceback (most recent call last):
  File "/nix/store/aaxl1lylcpijq8ipfz35prpkm3i1fc5k-meld-3.21.0/lib/python3.8/site-packages/meld/ui/emblemcellrenderer.py", line 100, in do_render
    pixbuf = self._get_pixbuf(self.emblem_name, self._emblem_size)
  File "/nix/store/aaxl1l
![Screenshot_20201213_185732](https://user-images.githubusercontent.com/1899200/102021251-77c88f80-3d76-11eb-96f9-19eaebffcf30.png)
ylcpijq8ipfz35prpkm3i1fc5k-meld-3.21.0/lib/python3.8/site-packages/meld/ui/emblemcellrenderer.py", line 64, in _get_pixbuf
    pixbuf = icon_theme.load_icon(name, size, 0).copy()
gi.repository.GLib.Error: gtk-icon-theme-error-quark: Icon 'emblem-new' not present in theme breeze (0)
Traceback (most recent call last):
  File "/nix/store/aaxl1lylcpijq8ipfz35prpkm3i1fc5k-meld-3.21.0/lib/python3.8/site-packages/meld/ui/emblemcellrenderer.py", line 100, in do_render
    pixbuf = self._get_pixbuf(self.emblem_name, self._emblem_size)
  File "/nix/store/aaxl1lylcpijq8ipfz35prpkm3i1fc5k-meld-3.21.0/lib/python3.8/site-packages/meld/ui/emblemcellrenderer.py", line 64, in _get_pixbuf
    pixbuf = icon_theme.load_icon(name, size, 0).copy()
gi.repository.GLib.Error: gtk-icon-theme-error-quark: Icon 'emblem-new' not present in theme breeze (0)
cairo.Error: Context.restore() without matching Context.save()

Notify maintainers

@jtojnar @mimame

Metadata Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.80, NixOS, 20.09.2205.65c9cc79f1d (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.9`
 - channels(root): `"nixos-20.09.2205.65c9cc79f1d"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: meld
# a list of nixos modules affected by the problem
module:

[mhwombat]

[jtojnar]

Interesting. Does it happen if you install/enable adwaita-icon-theme?

[mhwombat]

Interesting. Does it happen if you install/enable adwaita-icon-theme?

Yes! Installed the theme, and now it works again. Thank you!

[jtojnar]

I think that is probably still a bug in Meld. At worst, it should show image-missing icon instead of a failure.

[rdw20170120]

I just installed Nix on macOS 11.0.1 (Big Sur), then installed the 'meld' package. When I invoke 'meld', I get a working application with no icons. I tried installing the 'adwaita-icon-theme' package, but that did not fix the issue. I have found Meld to be buggy when installed via Homebrew as well (and in general). Very disappointing. Time to learn how to diff in Spacemacs.

[jtojnar]

For icons, you might need something like https://github.com/NixOS/nixpkgs/pull/112325.

[rdw20170120]

@jtojnar, thank you for the suggestion. I tried nix-env -i gdk-pixbuf. I got a message that there were multiple derivations. When I ran meld, I saw no difference. I may have to try some other derivations. I did this while still having the adwaita-icon-theme still installed.

I must confess that I am a bit surprised. It has been my understanding that Nix derivations are exhaustive, so dependencies cannot be missed like this. However, it seems to me now that it depends heavily on how thorough was the writer of the derivation. Apparently it is still possible to pick up undeclared dependencies that make installation appear to work. Am I correct? I assume a strict sandbox is then the answer, which not everyone will take the trouble to invoke properly.

[jtojnar]

@rdw20170120 Installing libraries like that will not help you with Nix. You would need to edit the meld expression to disable strictDeps.

It has been my understanding that Nix derivations are exhaustive, so dependencies cannot be missed like this.

That is true for dependencies the project’s build system checks at build time (e.g. linking of C libraries and other similarly static environments). More dynamic ecosystems like gobject-introspection or gdk-pixbuf will only fail at runtime when a dependency is missing.

However, it seems to me now that it depends heavily on how thorough was the writer of the derivation. Apparently it is still possible to pick up undeclared dependencies that make installation appear to work.

Right, dynamic dependencies are influenced by environment variables so they require wrappers, which can be forgotten or not noticed due to contaminated environment (e.g. when running the project in a terminal emulator that itself is wrapped). Or strict hermeticity would not be practical. And then there is the strictDeps bug that makes the wrappers inefficient.

I assume a strict sandbox is then the answer, which not everyone will take the trouble to invoke properly.

Missing sandboxing is not the issue (our CI is sandboxed, probably even on Mac but I am not familiar with the platform) as all dependencies checked at build time are there. The run time is the problem – compare static and dynamic programming languages.

[rdw20170120]

Ah, thanks for filling in that crucial bit. The issue is the intentional dynamic nature of (GUI) applications, which were designed and built for traditional Linux systems. Meld is my first foray into using Nix to manage GUI applications, which I now understand is still a wild beast. Most likely, fixing that will never be truly possible without a complete (and perhaps undesirable) redesign. I am switching my tooling from Vim to Emacs (Spacemacs), so it is time for me to also embrace using that for working with diffs. I was being lazy with Meld.

[jtojnar]

@rdw20170120 It is not that bad. It mostly works if hooks are properly specified, which Meld package has. The problem you were seeing was caused by a bug that is easy to bypass: https://github.com/NixOS/nixpkgs/commit/f02fc10d0dd79559de62e265da091d58f251a030 (Though, I am not sure if Mac does not need some extra considerations.)

[rdw20170120]

I see. Thanks for clarifying. I am very impressed with Nix, and I strongly believe that it is the way to go. But nothing is perfect, and there is no silver bullet.

[stale[bot]]

I marked this as stale due to inactivity. → More info

[tobim]

Both bugs described in this issue still persist (at least on macOS): The log is full of:

cairo.Error: Context.restore() without matching Context.save()
Traceback (most recent call last):
  File "/nix/store/w53f712qg889j8gbb5r33b2w0a0g1jw8-meld-3.22.0/lib/python3.10/site-packages/meld/ui/emblemcellrenderer.py", line 100, in do_render
    pixbuf = self._get_pixbuf(self.emblem_name, self._emblem_size)
  File "/nix/store/w53f712qg889j8gbb5r33b2w0a0g1jw8-meld-3.22.0/lib/python3.10/site-packages/meld/ui/emblemcellrenderer.py", line 64, in _get_pixbuf
    pixbuf = icon_theme.load_icon(name, size, 0).copy()
gi.repository.GLib.GError: gtk-icon-theme-error-quark: Icon 'emblem-new' not present in theme Adwaita (0)
cairo.Error: Context.restore() without matching Context.save()

[nejucomo]

I also still see this buggy behavior as of 'github:nixos/nixpkgs/aa9d4729cbc99dabacb50e3994dcefb3ea0f7447' (2023-12-14) on nixos.

I searched for "gi.repository.GLib.GError: gtk-icon-theme-error-quark: Icon 'emblem-symbolic-link' not present in theme Adwaita (0)" nix meld and found only one link which is an upstream bug filed with the exact same symptoms:

• https://gitlab.gnome.org/GNOME/meld/-/issues/741

That ticket explains that the symptom is caused by missing adwaita icon theme, as suggested in https://github.com/NixOS/nixpkgs/issues/106844#issuecomment-744059825 yet when I looked at https://github.com/NixOS/nixpkgs/commit/f02fc10d0dd79559de62e265da091d58f251a030 I noticed that both revisions explicitly include gnome3.adwaita-icon-theme (right before the diff's change).

So now I'm confused why I am still seeing this symptom (almost 3 years after the patch).

I found that when I explicitly install gnome3.adwaita-icon-theme in my profile this bug goes away.

My installation method:

Am I seeing this problem because of my unusual approach to installing nix packages? I have a flake which selects a set of packages to install which I then install/upgrade with nix profile, so the broken version looks sort of like this:

{
inputs.nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
# …
outputs = { nixpkgs, ... }:
  with nixpkgs.legacyPackages."x86_64-linux";
  symlinkJoin {
    name = "my-user-env";
    paths = [
      # …
      meld
  }; 
}

I modify this file in a local git repo, then do nix profile install . (or nix profile upgrade …).

If I include gnome3.adwaita-icon-theme in the symlinkJoin paths, then the bug goes away. Is there something about this installation method that prevents meld from properly including its runtime dependencies?

So I cannot tell if there's a nixpkgs bug for meld for the nix-env -i style flow or if the problem is only my installation method. If I devote more time to this, my next step is to read the nixpkgs source for meld to learn if my installation method deviates from say nix-env -i in some substantial way.

[jtojnar]

I found that when I explicitly install gnome3.adwaita-icon-theme in my profile this bug goes away.

That is the proper fix – adwaita-icon-theme being listed in buildInputs actually does not do anything.

[nejucomo]

Hm, my understanding of buildInputs is that it should include runtime dependencies, in which case I would expect the meld derivation to wrap or patch binaries to ensure those dependencies are met at runtime. Is my understanding incorrect?

[jtojnar]

buildInputs only declares dependencies. It is the responsibility of the builder to ensure the application can access them. We no longer do this for icons since they are big and user specific.

But in this case, it is sufficient to add an empty hicolor-icon-theme to XDG_DATA_DIRS so maybe we should make wrapGAppsHook do it automatically.

[scintill]

Just to add another data point: I put meld in my NixOS environment.systemPackages. I had right-hand side of git difftool -d --symlinks displaying wrong, and similar error messages as listed above about emblem-symbolic-link, until I added gnome.adwaita-icon-theme in systemPackages.

nixpkgs commit 9b5328b7f761a7bbdc0e332ac4cf076a3eedb89b.