Request: Add a setting to show file sizes in bytes, rather than automatically in kB/MB/GB depending on file size. Ideally with thousands dots in between. So e.g. Example.zip 1.024.580 ZIP archive rather than Example.zip 1.0MB ZIP archive This makes it easier comparing exact file sizes.
Created attachment 6847 thunar-size-label.patch +1 to this enhancement. The exact size would be useful also in directory properties dialog, e.g. for quick check when synchronizing directories, when updating a backup copy on a flashdisk. The human readable value is rounded and not very useful in this regard. Attached is a proposed patch (only) for the properties dialog. The patch is "quick and dirty", just to show what I have on mind. Looking at g_format_size_full function's GFormatSizeFlags https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#GFormatSizeFlags the G_FORMAT_SIZE_LONG_FORMAT is basically what I would like to see in the properties dialog - and, also, in the status line. But 1) the "LONG_FORMAT" is only with decimal units, there is no long format with IEC units (KiB MiB and the like, "file size in binary format") 2) Returning to the original request comment #1, there is no GFormatSizeFlags to get e.g. "1,024,580" output.
Created attachment 6848 thunar-size-label.patch screenshot
(In reply to Adam Purkrt from comment #1) > 1) the "LONG_FORMAT" is only with decimal units, there is no long format > with IEC > units (KiB MiB and the like, "file size in binary format") My bad, the flags are bitmasks, so G_FORMAT_SIZE_LONG_FORMAT | G_FORMAT_SIZE_IEC_UNITS -does- format in "binary format" (KiB, MiB, GiB). Updated the patch and filed my request as a separate bug 12858, since I feel it is separate, despite being related. Sorry for the mess here.
Created attachment 6851 thunar-exact-file-size.patch Here is a patch addressing the original request. The patch adds "Show exact file size" checkbox to Edit/Preferences/Display/Default View, which toggles between the exact bytecount (comma separated) and rounded ("human readable") format. I also renamed "Show binary size" checkbox to "Use binary prefix (KiB, MiB, ...)", since if left in, there would be two "Show [something] file size" options, which I found confusing. Note: The "Use binary prefix" option still has an effect even when "Show exact file size" is on, for example in the status bar.
Created attachment 6852 new Preferences dialog
Created attachment 6853 example screenshot
Created attachment 6854 thunar-exact-file-size.patch updated the patch (correction)
Thanks for the patch ! And sorry for letting you wait that long ! Generally I am ok with adding the option to show file sizes in bytes. I did not try the patch so far, however from checking the screenshots, it looks like there are a conceptual problems: - The "Display" preferences are general. So changing something there, I would assume to change it everywhere. ( E.g. as well on the file-size fore right-click-->properties ). So we need to as well change the displayed file-size there. - Like in bug 12858, the raw size-value should be prefixed with "bytes" - Like in bug 12858, I would rather add the "size in byte"-string to the existing size string, than replacing it. My assumption is, that even if a user is interested in the bytesize for specific files, for most files still the human readable value will be of more interest. - Considering that, I would suggest to rename the configuration to something like: "additionally show exact file size in bytes"
Oh my, I forgot I made this patch. I think for the properties dialog, the current state (after fixing bug 12858) i.e. always show exact size in bytes in properties dialog in addition to human readable value is fine. Adding an extra option for that would feel superfluous. There is plenty of space on "properties" anyway, and if one open the dialog (an extra step), it should always show as much info as possible. The reason why the patch only shows numbers without "bytes" (let alone adding it to it) in the file listing is to save horizontal space. The number is long in itself (usually, with GB sized files), and repeating "bytes" wastes space. The title of the column probably ought change, in that case, from "size" to "size (bytes)" to make it clear what does the number say. The patch here also added (iirc) showing the exact size in status line. E.g. "aclocal.m4" (439.3 kB) M4 macro would become "aclocal.m4" (439.3 kB (493,308 bytes)) M4 macro I did not like the double parentheses much, was contemplating it would be better to just show "(493,308 bytes)" and not "(439.3 kB (493,308 bytes))", but for that, one cannot use g_format_size_full function. All in all, probably time to update the patch.
> There is plenty of space on "properties" anyway, and if one open the dialog (an extra step), it should always show as much info as possible. I disagree. There is a ton of additional info we could display there. IMO file managers need to display the most important parts to dont mess the GUI too much. I am sure that there will be users which dont like the additional "noise". Same for the status bar. If a user is in need to see the exact size in bytes, he/she will quickly discover the configuration option. > The title of the column probably ought change, in that case, from "size" to "size (bytes)" to make it clear what does the number say. Than IMO it would be better to just add a new column in View-->Configure Columns... Like that there is still the option to have "size in byte" and "size human readable" at the same time. > The patch here also added (iirc) showing the exact size in status line. E.g. Ah, I did not recognize that. The bar provides sufficient space to display both in a good way. E.g: "aclocal.m4" - 439.3 kB (493,308 bytes) - M4 macro I dont know what is the best way in terms of implementation. But even if it's harder to implement, IMO we should go for the best possible outcome.
(In reply to alexxcons from comment #10) > > There is plenty of space on "properties" anyway, and if one open the dialog (an extra step), it should always show as much info as possible. > I disagree. There is a ton of additional info we could display there. IMO > file managers need to display the most important parts to dont mess the GUI > too much. I am too against clutter, but the exact size is imo important enough, to be always displayed in properties. As I have written, I am quite happy with the current state of the properties dialog (now, after fixing bug 12858). > I am sure that there will be users which dont like the additional > "noise". Same for the status bar. The status bar is different from the properties dialog, imo. The space is in tight supply here. Displaying exact size in status bar should be configurable. > If a user is in need to see the exact size in bytes, he/she will quickly > discover the configuration option. > > The title of the column probably ought change, in that case, from "size" to "size (bytes)" to make it clear what does the number say. > Than IMO it would be better to just add a new column in View-->Configure > Columns... > Like that there is still the option to have "size in byte" and "size human > readable" at the same time. Good idea! > > The patch here also added (iirc) showing the exact size in status line. E.g. > Ah, I did not recognize that. The bar provides sufficient space to display > both in a good way. E.g: > "aclocal.m4" - 439.3 kB (493,308 bytes) - M4 macro > I dont know what is the best way in terms of implementation. But even if > it's harder to implement, IMO we should go for the best possible outcome. This should not be too complicated. I will try to work on this.
Created attachment 7566 0001-Size-in-Bytes-column.patch Created a new patch, which adds "Size in Bytes" column as an option for detailed list in View/Configure Columns.
Created attachment 7567 0001-Size-in-Bytes-column.patch just a minor correction to the patch
Created attachment 7568 configure-columns
Created attachment 7569 size-in-bytes-detailed-view
Adam Purkrt referenced this bugreport in commit a5071b6a31d90c4686891ba4a79e9ff05944e3c0 Add setting to show file size in bytes in detailed view (Bug #11690) https://git.xfce.org/xfce/thunar/commit?id=a5071b6a31d90c4686891ba4a79e9ff05944e3c0
Wow, that was incredible fast and looks great ! Just tested & reviewed it .. --> Well done ! So let's close the bug ! Or do you want to go for some change in the status bar as well ?
Created attachment 7571 0001-Comment-correction.patch Thank you for the compliments. I unfortunatelly did not update one comment line properly, please find a correction attached.
Created attachment 7572 0002-Display-also-size-in-bytes-in-overwrite-confirmation.patch Yet another patch. This one adds displaying size in bytes to the overwrite confirmation dialog (alongside human readable value).
Created attachment 7573 overwrite-with-size-in-bytes.png Overwrite confirmation dialog after the patch. The human readable size is 1.0MiB in both cases, the exact size slightly differs. The size in bytes is valuable info in such case.
Created attachment 7574 0003-Show-also-size-in-bytes-in-statusbar.patch Finally, a patch for showing also the size in bytes in statusbar. I sticked with the parentheses in the end, they look the best.
Created attachment 7576 replaced outer parentheses with 2 spaces Good idea regarding the overwrite confirmation dialog ! Patch is fine for me. Regarding the statusbar I am still not happy with these double parentheses .. it just does not look right for me :) Attached I replaced outer parentheses with 2 spaces: (_("\"%s\" %s %s") .. what do you think ?
(In reply to alexxcons from comment #22) > Created attachment 7576 > replaced outer parentheses with 2 spaces > > Good idea regarding the overwrite confirmation dialog ! Patch is fine for > me. > > Regarding the statusbar I am still not happy with these double parentheses > .. it just does not look right for me :) > > Attached I replaced outer parentheses with 2 spaces: (_("\"%s\" %s %s") > .. what do you think ? Looks fine, I am ok with that.
I struggled across some more occasions where the statusbar still shows the old format: - Select multiple files - Select multiple files + folders - If no item is selected - If file is a symlink To provide a constant "look", I modified all of them accordingly. Before pushing this, I will ask some other dev(s), if they think it is fine without a setting to enable/disable the feature. And if there should be a setting, weather it should be opt-in or opt-out. Personally I dont have a strong preference on that.
Created attachment 7578 some more changes for statusbar argh, forgot to add patch ...
Alex, I am all for double spaces and to add this without a setting, but your patch is definitely wrong. You can not substitute g_format_size_full (size_summary, ...) with thunar_file_get_size_string_long (file, ...) the size_summary contains the size of all selected files (e.g.), whereas in the second case you are working with not well defined file Let me prepare a correct patch (with double spaces as separator).
Adam, Thanks for fixing my faulty patch ! Here a recap regarding considerations on showing size in byte on the statusbar as well for multiple files: Originally the text for multiple files/folders was: > 4 folders selected, 5 other items selected (61.9 kB) Possible option 1: > 4 folders selected, 5 other items selected (61.9 kB (61,897 bytes)) It looks like that if only thunar_file_get_size_string_formatted is replaced by thunar_file_get_size_string_long. The double parentheses IMO look a bit ugly Possible option 2: > 4 folders selected, 5 other items selected: 61.9 kB (61,897 bytes) Problem here is, that the colon is stonger than the comma, which looks like the size would include the recursive folder size. Possible option 3: > 4 folders selected, 5 other items with a total size of 61.9 kB (61,897 bytes) selected Meaning is fine this time, however it would have a bigger impact on the transifex team. Not sure if it is worth the effort. Possible option 4: Dont touch the statusbar string for multi-file selection at all. The downside here would be, that the displayed size-info is inconsistent. Adam is in favor of 4. I rather would go for 3, but as well could live with 4.
Here another pro argument for option 3 "4 folders selected, 5 other items with a total size of 61.9 kB (61,897 bytes) selected" ... still trying to convince you :P Since anyhow some transifex strings will be changed ( removed parantheses, added colons ), the i18n teams will need to adjust the language specific strings accordingly. ( I assume transifex will not automatically do that. Even if only special-characters are involved. ) So if we anyhow will trigger work for the i18n teams, option 3 would just mean "a little more work".
Created attachment 7585 0003-Size-in-bytes-in-statusbar.patch I have changed my mind. I now think the colons are ok and the best and the exact size should be included. Consider a folder with 24 files and 24 directories. The statusbar upon entering is 48 items: 238.3 kB (238,289 bytes), Free space: 55.9GB the statusbar after selecting everything is 24 folders selected, 24 other items selected: 238.3 kB (238,289 bytes) and when only files are selected it is 24 items selected: 238.3 kB (238,289 bytes) I think this is actually good enough, the user will quickly find what the numbers say (generally speaking, the folders are left out of the count, since they would take quite long to count). I think your version is a bit too long.
Created attachment 7586 statusbar with colon and size in bytes
Alexander Schwinn referenced this bugreport in commit b2d7b1e515e744c94eb45a3d31e7b1a0b48053b0 Add setting to show file sizes in bytes (bug #11690) - fix for overwrite confirmation dialog https://git.xfce.org/xfce/thunar/commit?id=b2d7b1e515e744c94eb45a3d31e7b1a0b48053b0
Alexander Schwinn referenced this bugreport in commit 23894cd9f8fe7157073263436050105fdb67d6ab Add setting to show file sizes in bytes (bug #11690) - fix for statusbar https://git.xfce.org/xfce/thunar/commit?id=23894cd9f8fe7157073263436050105fdb67d6ab
Ok, reviewed, tested and pushed. I squased the first 2 patches to dont mess the history to much ( apart from translation updates :X ) Thanks alot for your contribution !
Arg, I messed it, I forgot to add you as author :X ... that much about dont messing history :X Do you mind ? Should I revert & re-push ?
no problem, leave it as it is
ok, great, thanks ! At least in the very first one I did it correct :X