So, would you mind explaining why you find it useful and important to have?
1 Like
My daily driver is Fedora Workstation and therefore Gnome, I use it at work and at home.
Now for example I’m writing a driver for an SD Card… and to check whether a part of it was working I was constantly inserting, checking, formatting and removing it from the computer. When inserting the disk, I click on the gnome desktop’s notification and enter the folder, and to avoid having to open the terminal and type “ls -l”, I was relying on the properties window, but I want to know the specific size in bytes which is now hidden.
So first, could I change my workflow there? Yes, definitely, but if it wasn’t broken on Files 42.2, it probably should not be on 43.
Second, it’s now harder to know the exact size than it was before because:
- There’s honestly nothing that indicates I can hover my mouse over the human readable size. I’d really not
have found out if it weren’t for jensgeorg. - When you do show the size after the hover, you don’t use the thousands separators.
Before:
Mouse to Notification → Click → Mouse to Directory → Click → Mouse to File → Click → Read it.
Now:
Mouse to Notification → Click → Mouse to Directory → Click → Mouse to File → Click → Mouse to Size → Read it without the thousand’s separators.
Just the fact that I need to get the cursor above the little text is actually enough for it to be annoying.
Now don’t get me wrong, I think the new interface is beautiful… This is in fact the only thing that got me worked up about the desktop up to this day. I considered applying a patch and build my own “Files”.
Thanks for explaining!
I’d say that writing and testing a kernel driver is a use case where using the command line is not unreasonable.
1 Like
It’s not actually a kernel driver. I’m an embedded developer, it’s an SD card driver used by a firmware. Either way, yes, it’s not unreasonable… And I actually spend most of my time on CLI…
It’s just that in this scenario I find it faster to click on the desktop notification and show the properties of the file.
I see.
Then, maybe for your use case the most useful thing would be writing an extensions which adds a new column to the list view to display size in bytes for every file in the directory.
Here is an example of such an extension (actually an extension of the nautilus-python extension). examples/block-size-column.py · 3cfb7b8f3454a419eea23abcfe784c8a8842d10e · GNOME / nautilus-python · GitLab
That’s cool, I’ll probably take a look or build my own nautilus.
Either way, I’d definitely consider at least adding digit separators to the size that shows up after hovering the human size, it’s currently hard to find and hard to read.
Oh, right, I forgot that point. I believe it depends on your locale settings whether to display numbers with separators and which separator is used.
In theory it should.
In Gnome’s settings, my language is set as “English (United States)” and formats as “United States (English)”. It should use commas as separators, but it doesn’t.
I guess we are not taking the locale into account when making this size a string.
Btw, I just found out that France’s Format doesn’t use separators… I had though the entire world used it. 
I’ve fixed the issue. Now the tooltip shows thousands separators depending on the locale: https://gitlab.gnome.org/GNOME/nautilus/-/commit/21a6a7ed12d78f6d972e17d91820270c08e201a6
43.2 is going to include this enhancement.
3 Likes
I had noted the change too but I saw this discussion only now. I want to bring my take on this:
In my workflow I often make backup copies of files, and comparing the exact number of bytes for checking if there is already a backup of the current version of a file is faster than launching diff on a terminal. Without the exact number of bytes that becomes impossible.
I am happy to find out that there is a tooltip (so, problem solved), but I have to confess that I would have never found out about it without reading this thread (and I would have probably considered it a regression too).
1 Like
Awesome! Thank you for your hard work and your attention 
Thanks for your input.
For your user case, I would suggest an extension which provides hashes of the files. Hashes provide an even better way to make sure tge file contents are the same.
I mean, i recall one such extension. I don’t know whether it has been ported to libnautilus-extensions-4.
This extension? https://gitlab.gnome.org/GNOME/nautilus-python/-/blob/4.0/examples/md5sum-properties-model.py
It runs just fine.
Edit 0: Earlier I got the source for the older version of nautilus and it didn’t work.
Edit 1: This only calculates the MD5 of the filename, not it’s contents. Don’t know if it’s useful.
It uses GThreadPool, so calculations are made in parallel and the extension is non-blocking.
This is the first time I use the new NautilusPropertiesModel and NautilusPropertiesItem objects. I have two thoughts:
- If a file is particularly big I wanted to show the “Calculating…” content until the calculator thread terminates the computing and finally replace it with the checksum, but
NautilusPropertiesItem:valueis construct-only, and so the only thing I can do with big files is showing an empty window until the checksums are ready. Do you think it could be possible to removeG_PARAM_CONSTRUCT_ONLYfromNautilusPropertiesItem:valueand update the API accordingly?
(With very big files the window gets populated after a few seconds)
- In my opinion this is linked to what I was saying in this post, i.e. that it is not needed to move the extension API to a separate process: when something works better asynchronously – like this case of checksums – developers already know how to start new threads/processes, and will do that on their own.
My two cents
―madmurphy
I think it would make more sense to have NautilusPropertiesModel provide a new “loading” property.
Likewise, I would like to explore the idea of providing a set of properties to have an empty state and/or and error state. Right now the built-in extensions pass error message as a NautilusPropertyItem when no actual property item could be created. That’s not not ideal.
1 Like
Another thread in the same process can still crash the application. We have had a number of crashes caused by the built-in audio-video properties extension. My concerns are isolation and resilience.
1 Like
That would be of course better 
Please let the crashes happen until the bug is found and the code gets fixed! Otherwise it sounds a bit like using a signed integer in a decreasing loop of positive numbers only for the fear or not doing i-- with i == 0: you must avoid that that ever happens, not avoid the infinite loop when that happens.
Already now the extension API sits in a tight box, please do not make the box even smaller.
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.