Ubuntu

Ubuntu's change to g_format_size_for_display() causes inconsistency

Reported by Charles Kerr on 2010-03-14
28
This bug affects 7 people
Affects Status Importance Assigned to Milestone
glib2.0 (Ubuntu)
Medium
Martin Pitt
Lucid
Medium
Martin Pitt

Bug Description

This is in reference to https://bugzilla.gnome.org/show_bug.cgi?id=554172#c32

> Since this violates the recently instated units policy in Ubuntu
> (https://wiki.ubuntu.com/UnitsPolicy) we applied this patch in Ubuntu to make
> g_format_size_for_display() standards conformant (original patch by Benjamin
> 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_size_for_display()
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_size_for_display() + "/s"
as recommended by Benjamin Drung (the author of the g_format_size_for_display()
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_size_for_display().

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_size_for_display() in order to see
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_size_for_display() *should* be base 10, but
doing it downlstream as Ubuntu has done puts application developers
in a tough situation.

Related branches

Benjamin Drung (bdrung) wrote :

According to the units policy, user inputs of file sizes should be in base-10, too (or give the user an option for the preferred prefix).

Charles Kerr (charlesk) wrote :

> According to the units policy, user inputs of file sizes should be in base-10, too (or give the user an option for the preferred prefix).

I already addressed this in paragraph three. 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_size_for_display().

In short, this change forces Transmission to decide whether it wants to be consistent with upstream or with Ubuntu. My preference would be for Transmission to integrate on all platforms, so this is a suboptimal choice caused by Ubuntu's fork of g_format_size_for_display().

Benjamin Drung (bdrung) wrote :

Now I am aware of the full problem. In my opinion you should work internally with bytes, assume upstream's implementation of g_format_size_for_display(), and use helper functions for conversion. Full description here: https://bugs.launchpad.net/transmission/+bug/538504/comments/17

Benjamin Drung (bdrung) on 2010-03-14
tags: added: units-policy
Charles Kerr (charlesk) wrote :

And all similar applications should do this too?

Benjamin Drung (bdrung) wrote :

How many applications are affected?

Martin Pitt (pitti) wrote :

I think your programs shouldn't use g_format_size_for_display() at all, due to its brokenness. Many other programs (gnome-system-monitor, gvfs, palimpsest, etc.) don't use it either for that reason.

Martin Pitt (pitti) wrote :

Also, wrt. the bug title, the function causes inconsistencies either way (without the patch they are in e. g. nautilus).

However, I'm willing to revert the glib change and instead just fix nautilus. Now is not the right time to spend long hours arguing about things like that, we need to get to actual bug fixing in lucid.

Changed in glib2.0 (Ubuntu):
status: New → In Progress
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

I uploaded a new glib which reverts the patch for lucid. Please see my followups in bug 369525 and https://bugzilla.gnome.org/show_bug.cgi?id=554172 for details.

Changed in glib2.0 (Ubuntu Lucid):
importance: Undecided → Medium
milestone: none → ubuntu-10.04-beta-1
status: In Progress → Fix Committed
Charles Kerr (charlesk) wrote :

Benjamin Drung wrote

> How many applications are affected?

You've been pushing for this change for over year. Why are you asking me? ;)

Martin Pitt wrote:

> I uploaded a new glib which reverts the patch for lucid.

Thank you, Martin. Hopefully we can get some programmatic solution upstream in glib that satisfies everyone.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package glib2.0 - 2.23.5-1ubuntu3

---------------
glib2.0 (2.23.5-1ubuntu3) lucid; urgency=low

  * Disable 05_file_size_units.patch. It is still being debated upstream
    (since it can be considered an ABI change), and causes inconsistencies in
    other applications such as transmission. (LP: #538783). This reopens
    LP #369525.
 -- Martin Pitt <email address hidden> Mon, 15 Mar 2010 12:25:27 +0100

Changed in glib2.0 (Ubuntu Lucid):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.