Nemo search results default columns

[stefan_o]

Hello,

whenever I search for files, I'll get the columns Name, Location, Last Modified. I can enable other columns using the context menu, but Nemo won't remember that. I couldn't figure out how to configure the columns that are shown by default, is that possible somehow?

Best regards
Stefan


OS: Linux Mint 21.1 Cinnamon Edition

[tonywhelan]

I can't see a way to do it in nemo's Preferences dialog.

But the settings are in the gsettings database that you can access via Dconf-editor

Install Dconf-editor and go to /org/nemo/search/search-visible-columns - you can edit the list of columns you want displayed and save it and it will be "sticky" for the future.

I have mine set to: ['name', 'size', 'where', 'date_modified']

The disadvantage is you have to know the column header names to use. The nemo column names are as follows:
'name', 'size', 'type', 'date_modified', 'date_created_with_time', 'date_accessed', 'date_created', 'detailed_type', 'group', 'where', 'mime_type', 'date_modified_with_time', 'octal_permissions', 'owner', 'permissions'

[stefan_o]

Thanks for that tip, but it didn't work (I would like to have it exactly like you): Even after restart it's still only the three default columns. I checked dconf-editor again, it shows the string exactly as you wrote at it as current value.
I checked if Nemo reports any errors to stderr regarding to that when starting from the the console: It doesn't. Also nothing in syslog.
Any clue what I might be doing wrong?

[sanmig]

Funny, in 19.3 Nemo (4.4.3) remembers what one selects in the search view
In Dconf-editor (/org/nemo/list-view/search-visible-columns) I can immediately see any changes done in Nemo-search.
Thanks for the Dconf tool-tip!

[stefan_o]

The entry /org/nemo/list-view/search-visible-columns doesn't exist for me. It seems that dconf-editor also doesn't allow me to create new entries.
I'm not to sure, but I also think that Nemo did remember that in the past or maybe the default was different (it never annoyed me until recently that size is not shown)

[sanmig]

Maybe a Win “feature” in 21.1 or Nemo version?
When testing the Mint 21 Cinnamon 64 (Nemo 5.4.2) .ISO from my Ventoy-drive the search columns are sticky, strange

[stefan_o]

Ok, I just tried another device: It will remember the setting and store it in /org/nemo/search/search-visible-columns
Why does my system doesn't do that? It was a clean install of Mint 21 (updated to 21.1). The other system is a clean install of 21.1. Some bug in updating 21 to 21.1?

[tonywhelan]

Your replies seem a bit contradictory so lets clarify.

On the "problem" machine, open a terminal window and type (or paste):

Code: Select all

gsettings get org.nemo.search search-visible-columns

and tell us what response that gives you. On my machine it returns:

Code: Select all

['name', 'size', 'where', 'date_modified']

[sanmig]

As I understood, the “problem” machine simply would not store changes in the gsettings?
Both are 21.1.
So what about the Nemo versions in the updated and installed machine?

[stefan_o]

gsettings returns what I expected (because I set this using dconf-editor:

Code: Select all

['name', 'size', 'where', 'date_modified']

Unfortunately Nemo completly ignores that. Nemo is version 5.6.3

[stefan_o]

Had a look at the source code and found the problem, there is a bug (feature???) in Nemo that prevents it from using that setting:

I have the option "ignore-view-metadata" turned on, because I do not want Nemo to use/remember any folder-specific settings. If you have a look at src/nemo-list-view.c in the function get_visible_columns will first check if "ignore-view-metadata" is turned on and if yes return a default value and only if this option turned off check if we are in search and return the setting or if not read the metadata.

I think this is a bug and the if/else should be the other way around, first check if this is a search and second check the option "ignore-view-metadata", because the option is labeled "ignore folder-specific views" (or something similar, in German it's "Ordnerspezifische Ansichtseinstellungen ignorieren")

[tonywhelan]

So that's set by the nemo dialog checkbox "Ignore per-folder view preferences", something that I have never used.

Well done figuring it out by checking the source code, I never thought to do that! And I have never learned C programming so its all a bit mysterious.

I agree with your view that this should be reviewed.

[sanmig]

Nemo is version 5.6.3

So the only difference between the devices is in the option setting?

... the function get_visible_columns will first check if "ignore-view-metadata" is turned on and if yes return a default value and only if this option turned off check if we are in search and return the setting or if not read the metadata.

Not a programmer I can’t parse that but I’ll trust you

However, your set option to “ignore …whatever” prevents you from (GUI) storing the search column settings:
Having it set, the changes (in visibility and order) are not written back to the gsettings and thus are lost when closing Nemo.

-> Try to unset, search + make the changes in Nemo GUI, and set the option again.
Close / open Nemo and check the search columns - ?

… Probably Nemo will ignore changes made by dconf-editor ?
—> Did you dconf-edit both, custom and current array?

Rem:
In my Nemo (g)settings for list-view there are
- default (guess from compile, called “Default”) values and
- current values (user changed and stored settings, named “Current value”).
And then there is an array “Custom value” …
Only with the “ignore…” option not set, (GUI) changes done by the user are stored in the “Current value” and “Custom value” array.

I don’t know why double is necessary, but it is there, take care, the dconf editor will immediately show changes in “Current” but not in “Custom”, likely a bug, close+reopen the editor to see the changed custom array!

[stefan_o]

Yes, the only difference is the setting. It can be reproduced directly, just turn it on and you'll get the three default columns only.

This also means you cannot set unset -> change -> set, because not only the code that stores the custom columns checks that option, also the one that reads it. That's why my change dconf-editor was ignored. Once I disabled that setting, it became immediately active like I put it in dconf-editor. I assume somebody tried to fix a bug where "per-folder view preferences" that were written before the setting was activated were still used after the setting was activated.
I opened a bug on GitHub for this: https://github.com/linuxmint/nemo/issues/3178
I think it should be easy to fix, all it takes is swap some nested if/else around, so first check if this is a search view and second check if "per-folder view preferences" is active, not like now, where before checking if it's a search immediately return default if the option is active.

C is in my opinion not that mysterious, it's probably one of the easier languages to read (if the code is well structured), because syntax is rather simple (ok, pointers and function pointers can get tricky) and there is only a very limited number of special words like if, else, for, while...
Figuring this out was not hard at all: I just searched the nemo source for the string "search-visible-columns", that string was defined in a constant, so I searched for the constant, found less than 10 occurrences, most of them in functions with names like "get_visible_columns", had a look at them and I could see that "ignore-view-metadata" was checked first and if enabled "search-visible-columns" is not even read. Took me less time than to write this post

[sanmig]

With Nemo 5.4.2 (21.1 live) the option is called “Ignore per-folder view preferences” and the unset -> change -> set trick works (as it does with my old Nemo version).
However, with that option set, changes made in search columns are transferred to the “normal” folder view when ending the search.
So there are custom settings for both views, but the search remains - I don’t like it

As I said, I don’t have access to Nemo 5.6.3 so can’t reproduce (but I understand) your issue #318.
Thanks for your persistence!