auto-resize of copy dialog box

Bug #387869 reported by Lenny on 2009-06-16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released
One Hundred Papercuts

Bug Description

When copying a file, initially the time left for the copy is unknown as is the transfer speed and so the copy dialog box showing the transfer process is drawn small. When these values are determined, the box is resized to fit the new info, jumping to a larger size. This seems unprofessional. It would be better to have the box initially drawn large enough so that when the parameters are filled in there is no eye-shocking redraw every time a copy is performed.

Martin Albisetti (beuno) wrote :

A great papercut to fix!

Changed in hundredpapercuts:
status: New → Confirmed
Martin Albisetti (beuno) wrote :

I thing the fix proposed is good enough

Changed in hundredpapercuts:
status: Confirmed → Triaged
pranith (bobby-prani) wrote :

or better, do not draw the window until you have the required info. This should be more aesthetic than drawing an empty shell and filling the gaps

that would also work to eliminate the resizing, but might create another
undesirable situation...

The reason I proposed what i did over a solution akin to this is that while
the same thing is happening in the background in both cases (the file is
starting to copy), the delayed visual feedback of the copy window popping up
might be interpreted by the user as "slow-ness". By drawing the window as
soon as the operation begins, the OS earns more "snappiness" points with the
user, always a good thing.

On Mon, Jun 22, 2009 at 10:36 AM, prani_bobby <email address hidden> wrote:

> or better, do not draw the window until you have the required info. This
> should be more aesthetic than drawing an empty shell and filling the
> gaps
> --
> auto-resize of copy dialog box
> You received this bug notification because you are a direct subscriber
> of the bug.


Martin Albisetti (beuno) on 2009-07-21
Changed in hundredpapercuts:
milestone: none → round-8
status: Triaged → Confirmed
Milan Bouchet-Valat (nalimilan) wrote :

GTK+ allows somewhere to get the size required to show some text (I forgot where, maybe only in GtkLabels). So you can get the size of the string, using zeros instead of the real numbers, and using three or four of them so that the real speed does not take more space. Then, the dialog will be wide enough not to resize itself.

BTW, update-manager has the same problem when downloading packages, so the same trick could be applied when it's written.

Changed in hundredpapercuts:
milestone: round-8 → lucid-round-3
Luke Symes (allsymes) wrote :

Attached is what I get for a copy dialog, and as you can see I get a dialog that is more than big enough to handle the addition of the transfer speed.
Looking at the code, I found this (libnautilus-private/nautilus-progress-info.c:355,356):
 label = gtk_label_new ("status");
 gtk_widget_set_size_request (label, 500, -1);
So, the whole dialog will be stretched to at least 500 pixels. Isn't that more than enough?
I'm thinking this bug should be marked Fix Released. What do people think?

Changed in hundredpapercuts:
status: Confirmed → Incomplete
Vish (vish) wrote :

Luke Symes, Thanks for reminding this.

Yes , it has been fixed in nautilus. I'm not noticing this bug anymore.

Changed in nautilus:
status: New → Fix Released
Changed in hundredpapercuts:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers