Rename file behavior differs between List View and other Views

[f2404]

When a file or directory is selected in List View, and F2 gets pressed or "Rename..." menu action gets selected, this transforms the selection into a text input field which clearly indicates that the item is being renamed. However, when doing the same in Icon View or Compact View, the field does not appear. Also, the selection gets cleared, and the item font gets slightly changed. Is this done on purpose? I find it very confusing.

Arch Linux, nemo 3.0.1.

[kmkom]

For me it works on: Mint 17.3, Nemo 2.8.7 LMDE2, Nemo 3.0.0

[f2404]

For me, it looks as follows: http://imgur.com/a/Op4OI Same on 3.0.0 and 3.0.1.

[dglava]

I can confirm this with Nemo 3.0.5 and the default Adwaita theme (on GTK 3.20).

Some themes seem to work (Arc for example). Does this mean that all the themes have to implement custom styles? It's kind of tricky, since the default GTK3 theme, Adwaita, doesn't work properly (as seen above) and people who use Nemo outside of Mint/Cinnamon (without the themes provided by them) will be confused by this.

Is this a deliberate choice (to allow more fine-grained theming) at the expense of "default theme compatibility" or an actual bug with plans to potentially fix it?

[ChameleonScales]

I have the same issue on Debian 9.8 XFCE 4.12 I could partially fix it by installing the Ultimate Maia theme but it still doesn't work when I run Nemo as root. However I think this issue concerns the distro rather than nemo itself because I encountered it in other apps (e.g Xpad)

[mtwebster]

The list view uses standard 'widgets' for displaying the name column and the renaming operation. The icon view is a custom view, and requires its own theme elements.

As of Nemo 4.0 this shouldn't be a problem - at startup, if no nemo theme support is detected, it adds some 'best effort' elements so things like renaming are at least usable. It's not perfect but works for most themes I've tested. It's slightly improved in the forthcoming release.

[ChameleonScales]

Thanks. In that case I'd like to try out nemo 4.0.6 but I can't even get started on building it: https://forums.linuxmint.com/viewtopic.php?f=47&t=294378

[mtwebster]

On debian you can use dpkg-buildpackage (or debuild)

sudo apt-get build-dep nemo  # you may need to enable source repos on your system
dpkg-buildpackage  # or debuild - run this in the source folder
cd ..
sudo dpkg -i *.deb

This should work on any apt/dpkg-based system. We probably need to update the install/build instructions, we don't even use configure files anymore.

[ChameleonScales]

Thanks, it worked and fixed the issue! I downloaded and installed a bunch of debian 10 packages on pkgs.org to meet dependencies and added --no-sign to the dpkg-buildpackage command which is not ideal but that's a good start. Also someone told me that a fresh Debian 10 install doesn't have the issue at all.

[mtwebster]

The signing error at the end of the build can be ignored if you're building it yourself. The packages still built successfully, so no real need to add --no-sign. It just means you haven't your own gpg key to sign it with. (just for future reference).

I'm not too sure about Debian 10 not having the issue, from a quick package search, the latest available version is 3.8.5 (I don't see 4.0.x on anything yet there)

[ant9000]

Unluckily, Debian 10 still has the same issue. Can be solved by saving v4 fallback style in a place where nemo is looking for a css. Using strace, I've discovered that ~/.themes/Default/gtk-3.0/gtk-keys.css will do.

[ChameleonScales]

@ant9000 Hi, I'm quite interested in your solution. However, I've tried pasting the content of this css in a new file named gtk-keys.css and pasting that file in all these directories (concatenating the contents when the file already existed): ~/.themes/Default/gtk-3.0/ ~/.themes/Xfce4/gtk-3.0/ /usr/share/themes/Default/gtk-3.0/ /usr/share/themes/Xfce4/gtk-3.0/ then made sure to use the Xfce4 theme, then rebooted my computer but it didn't change anything. Any idea what I'm missing?

[ant9000]

I've launched nemo under strace, like this:

strace nemo 2>&1 | grep css

On Debian 10, the path I've shown works - on another platform, you'll likely find different files.

[ChameleonScales]

ok sorry I didn't get what strace was for. Unfortunately I'm still stuck. When I run the above command, the terminal shows that nemo is looking for gtk.css in all the possible places but that file doesn't exist in any of them (see full output. But if I rename gtk-keys.css to gtk.css, then nemo becomes all dark and is missing many design features or broken. Keep in mind this is a fresh and untouched Debian install, so all I can think of is that there's some default gtk.css I need to download somewhere.

[ant9000]

Well, your strace output looks very different from mine - that's strange. What happens if you comment out the "Inactive F3 pane shading" only?

[smurphos]

Try chucking it in ~/.config/gtk-3.0/gtk.css - this is intended for end-user .css and overrides both theme and application specific css.

[ChameleonScales]

@smurphos OMG yes that's it! Works on both Debian 9 and 10 (XFCE and Cinnamon editions) (I tried on some fresh VMs) Thank you so much, this removes a thorn from my foot (as we say in french)

[f0nzie]

Confirm paste the code in the .css file works in Debian 10. In my case, the file ~/.config/gtk-3.0/gtk.css wasn't there. I had to create first and paste the code.

[rddunphy]

Putting that code in ~/.config/gtk-3.0/gtk.css worked perfectly for me on Ubuntu 20.04 with Yaru-dark theme. I did have to reboot for it to take effect thought. Thanks!

[mtwebster]

This isn't still an issue is it? Nemo should inject its own fallback code at startup since: https://github.com/linuxmint/nemo/commit/21a960712bf4d7688babd6c65f3b4a1758543f79#diff-1c15327d60430ed9db5b4f9f3975e1da

I can confirm there's no issue with adwaita (a theme that's guaranteed never to have nemo support).

If anything is still missing, it should be added here: https://github.com/linuxmint/nemo/blob/master/gresources/nemo-style-fallback-mandatory.css.

[rddunphy]

That's odd - I have neither the rename text highlighting nor the F3 pane shading after installing Nemo 4.4.2. This is on a fresh install of Ubuntu 20.04 (Gnome 3.36.2), and seems to be the same with any of the three default window themes. I don't think there's anything missing from the blob - that's the exact code I added to ~/.config/gtk-3.0/gtk.css, which fixed it. Could it be that something in the Yaru theme is overriding it? With the fix commented out, this is what it looks like for me right after pressing F2 (so "Documents" is currently highlighted):

Output from strace here.

[mtwebster]

What does it say when you start nemo up from a terminal? Is it quiet or does it mention something about themes?

If a theme (the css) fails to contain the word 'nemo' in it, nemo injects that file into the css. If it finds it, it skips that step. That doesn't necessarily mean the theme has full or correct nemo support, however.

[rddunphy]

Yeah, there's no output when starting nemo from the terminal - it looks like Yaru has partial support for Nemo. I've just discovered there's actually an issue open in Yaru for this already; I'll link to here from there. Thanks for your help!