Fossil knows how big the files are. That info is in a field in the database. So you could adjust some SQL for one of the screens to also supply the file size and display it. But that has not yet been done, as far as I recall.

Patches will be thoughtfully considered.

So, is it possible to display this in Fossil?

"The problem" is that those data are not readily available in those views and that getting that data would require an additional query per file. Fossil's "manifests," from which those listings are made, do not hold a file's size, they only indirectly reference the file by its hash. Getting the size requires doing a query for that hash, against data which fossil does not otherwise require to exist for those views (namely, it does not require that the content actually be in the database for those views). If it were to show the sizes, it would be required to show some silly value, like "-1", for content which it knows exists but which is not in this copy of the database (either it was shunned or has not yet synced in).

i.e. it's not simply a matter of adding an existing in-hand data field to the output.

Also, these pages have non-intuitive menu...

As to the menu layout i can't say anything useful off hand.

"The problem" is that those data are not readily available

It's just a JOIN against the BLOB table. The BLOB.SIZE field contains the original size of the artifact, after it has been undeltaed and uncompressed. If you are concerned about artifacts that have not yet been synced, make it a LEFT JOIN.

You've highlighted one of the great advantages of Fossil over Git, which is that the content is held in a relational database. Git also knows the size of all artifacts, but you have to write C code to go dig around in Git's bespoke data formats to find that size. With Fossil, that information is just a LEFT JOIN away. Yes, the database engine has to go through all kinds of gyrations to process the LEFT JOIN, but it ends up being surprisingly fast, and (more importantly) it is simple for a developer to implement correctly. Simple things are more likely to get done and done correctly.

It's just a JOIN against the BLOB table.

Okay, i missed the part where the manifest is only being used to populate a temp table which is within easy reach of the blob table, and assumed it was being used to create the remainder of the output.

... Git also knows the size of all artifacts, but you have to write C code to go dig around in Git's bespoke data formats to find that size.

Git 'ls-tree -l' command shows the blob size in the 4th column.

For example,

$ git ls-tree -r -l --full-name HEAD

100644 blob bd3b3836307915d03e57b98b8d7ab5a8b65d8e8f     894	.gitignore
100644 blob a48239967d00b377ed6fd86c44ae0f93a10054fe    9927	AUTHORS
100644 blob 7c0a6059cfc1d9cb803e2760870265f81a179969     232	ChangeLog
100644 blob 3c369828a8feaa1cbf9f394a9991480aaaed90ab    2917	src/Makefile.am

....

Please try the latest trunk.