Is your feature request related to a problem? Please describe.
Flatpak updates can be very large and it would be useful to be able to track how much data they pull in. This makes it easier to decide if having certain Flatpak apps is worth it or not.
Describe the solution you'd like
The simplest solution:
add a "Size" column in the history view.
A more elaborate solution:
additionally, allow range select, and even Ctrl+click to add other items outside of a range, to display the total size of the selected updates
An even more elaborate solution:
additionally, add buttons for update sizes based on type (All, or a specific type) and period of time (This Month, Past 3/6 Months, This Year, Specific Year, All Time)
The latter solution can cache its results for optimal performance, but a re-analyze button would serve well to recover from any data corruption with the existing stats, or if new types get added.
Optional (but useful and also nice to show off): Allow exporting the data to CSV, so people can make custom graphs. This would obviously be more useful to sysadmins (especially for data aggregation) and people who have network traffic constraints.
The complication with the CSV export is that there would be an obvious need for a new column to indicate which network was used to update. There's no perfect solution here because people can use different wired connections that can be metered or not. So it would be entirely up to them to correlate the network name with the date and time of the updates, but adding the network name would be useful.
Is your feature request related to a problem? Please describe. Flatpak updates can be very large and it would be useful to be able to track how much data they pull in. This makes it easier to decide if having certain Flatpak apps is worth it or not.
Describe the solution you'd like The simplest solution:
A more elaborate solution:
An even more elaborate solution:
All, or a specific type) and period of time (This Month,Past 3/6 Months,This Year,Specific Year,All Time)The latter solution can cache its results for optimal performance, but a re-analyze button would serve well to recover from any data corruption with the existing stats, or if new types get added.
Optional (but useful and also nice to show off): Allow exporting the data to CSV, so people can make custom graphs. This would obviously be more useful to sysadmins (especially for data aggregation) and people who have network traffic constraints.
The complication with the CSV export is that there would be an obvious need for a new column to indicate which network was used to update. There's no perfect solution here because people can use different wired connections that can be metered or not. So it would be entirely up to them to correlate the network name with the date and time of the updates, but adding the network name would be useful.