Ubuntu's change to g_format_size_for_display() causes inconsistency
This is in reference to https:/
> Since this violates the recently instated units policy in Ubuntu
> Drung, I adapted the test cases accordingly).
> The obvious other alternative would be to keep the 1024 multiplicator, and fix
> the units to be KiB, MiB, etc., but I'm strongly convinced that this would just
> lead to more confusion (everything except RAM size is commonly written in
> standard base-10 prefixes these days, after all).
The problem occurs when applications using g_format_
also allow user input of file sizes. For example, let's say an application
allows users to set the size of a disk cache. What units should the GUI
use when accepting user input?
Transmission's preferences dialog lets users specify speed limits in KiB/s.
If Transmission were to display speeds with g_format_
as recommended by Benjamin Drung (the author of the g_format_
patch), Transmission will appear to end users to be exceeding the limit.
Conversely, if Transmission fully adopts Ubuntu's Unit Policy, its speeds
will be off in the other direction (never reaching the speed limit) on distros
using the upstream implementation of g_format_
In *both* cases, Transmission's input and display units will be inconsistent
with one another on at least one platform. Every application in this situation
would need to pass test input to g_format_
if it's the base 2 or base 10 version, and then tailor its input dialogs accordingly,
as well as massaging sizes and speeds entered by the user.
In short, this change was introduced to make things more consistent and
intuitive, but has unintended side-effects that do the exact opposite.
It's likely that g_format_
doing it downlstream as Ubuntu has done puts application developers
in a tough situation.