nemo fails to start on wayland

Created on 26 Apr 2017  路  6Comments  路  Source: linuxmint/nemo

I'm trying to run nemo on wayland (sway) in the same way I run it under i3, but it fails to start:

$ /usr/bin/nemo --no-desktop
Could not parse arguments: Cannot open display:

Unsetting GDK_BACKEND makes it run, but using xwayland, which, amongst other things, breaks copy-pasting.

Most helpful comment

@mtwebster The nautilus commit I referenced was originally for the desktop process only, as I'm waiting for you to spilt nemo I applied to the whole of nemo to address fedora abrt reports.

https://github.com/linuxmint/nemo/issues/1343

https://bugzilla.redhat.com/show_bug.cgi?id=1278272

https://bugzilla.redhat.com/show_bug.cgi?id=1249761

https://bugzilla.redhat.com/show_bug.cgi?id=1332003

@hobarrera Once it's split it can be applied to the desktop only.

All 6 comments

It would seem that this commit deliberately breaks nemo so that it doesn't work on wayland (though the messages doesn't clarify why). Is it strictly unsupported? I'd rather see a warning that straight out halt and catch fire.

It was based on this nautilus commit

https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-22&id=94dcf03e5bc9cd1db83cf3016289e305e13694d4

The commit was tested under fedora wayland and it worked fine, whatever distro your using has broken gnome wayland.
You will need to set the DISPLAY env if you want it to work.
Fedora sets the DISPLAY env by default on wayland session.

screenshot from 2017-04-26 07-04-38

FTR nemo can draw desktop icons under wayland.

screenshot from 2017-04-26 07-09-04

The commit was tested under fedora wayland and it worked fine, whatever distro your using has broken gnome wayland.

I'm not using gnome, I'm using sway.
It's not sway that's broken, it's nemo that has explicit code to crash when using the wayland GDK backend. It explicitly marks itself compatible with x11-only.

You will need to set the DISPLAY env if you want it to work.
Fedora sets the DISPLAY env by default on wayland session.

This makes nemo use xwayland (which basically runs an X11 app inside wayland with a compatibility layer).
That's just a workaround for apps that don't work on wayland (eg: gtk2). I shouldn't need to hack around like that for nemo which uses gtk3. Removing the offending line makes nemo work perfectly on wayland.


To sum up, nemo currently marks itself as x11-compatibly, and then requires xwayland and users to export DISPLAY to run in a compatible-mode, when it's really capable of running natively under wayland.

The current hack only really makes sense when nemo is used to draw desktop icons. Maybe we could move the offending line and only execute that function call when not using --no-desktop, as a compromise? This way:

  • nemo would render the desktop on for users who want this, albeit, running via xwayland.
  • nemo would work without any extra hacks for any other wayland user.

Nemo will soon have two separate processes, one just for the desktop, and one for client windows. Would it be possible then to use that backend flag only for the desktop process?

@mtwebster That really makes sense, since there should be no need to force the non-desktop process to use x11.

@mtwebster The nautilus commit I referenced was originally for the desktop process only, as I'm waiting for you to spilt nemo I applied to the whole of nemo to address fedora abrt reports.

https://github.com/linuxmint/nemo/issues/1343

https://bugzilla.redhat.com/show_bug.cgi?id=1278272

https://bugzilla.redhat.com/show_bug.cgi?id=1249761

https://bugzilla.redhat.com/show_bug.cgi?id=1332003

@hobarrera Once it's split it can be applied to the desktop only.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ngabor7 picture ngabor7  路  6Comments

memeplex picture memeplex  路  6Comments

Hairybiker picture Hairybiker  路  5Comments

lucypol picture lucypol  路  6Comments

blueray453 picture blueray453  路  5Comments