Size of file in bytes in Nautilus

[madmurphy]

@antoniof

I mean, i recall one such extension.

We have one now

It uses GThreadPool, so calculations are made in parallel and the extension is non-blocking.

@antoniof

This is the first time I use the new NautilusPropertiesModel and NautilusPropertiesItem objects. I have two thoughts:

1. 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:value is 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 remove G_PARAM_CONSTRUCT_ONLY from NautilusPropertiesItem:value and update the API accordingly?

(With very big files the window gets populated after a few seconds)

2. 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

[antoniof (António Fernandes)]

@madmurphy

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:value is 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 remove G_PARAM_CONSTRUCT_ONLY from NautilusPropertiesItem:value and update the API accordingly?

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.

[antoniof (António Fernandes)]

@madmurphy

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.

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.

[madmurphy]

@antoniof

I think it would make more sense to have NautilusPropertiesModel provide a new “loading” property.

That would be of course better

@antoniof

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.

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.