GNOME Bugzilla – Bug 518410
Improve the design of the File Operations dialog
Last modified: 2017-03-06 12:54:34 UTC
the file operations dialog looks kinda bad. maybe the button should be the same size as the progress bar or sth like that but it should definately be improved, imho.
Created attachment 105859 [details] screenshot
-> GIO. Confirming, although we're in UI freeze and I'm not sure we can modify this for 2.22.
In fact this is a very visible UI regression from 2.20. I would make it a top priority to get some HIG people to redesign this dialog and request breaking the UI freeze.
I don't think this is top priority stuff for 2.22, I quite like the structure of the new dialog, and overall it's a big improvement over the old one...the missing bits are IMHO a nicer status icon and maybe some kind of context menu for it and some HIG fixes like the one described here.
Several things that look like regressions to me and could be improved: * The Cancel button is too small of a target (try it on a notebook); * No label on the Cancel button (no keyboard shortcut for you mister); * Doesn't show the current file; * No way to see the full path of the file or directory
We should try to fix these issues for 2.24.
I've published a proposed design on the wiki. <http://live.gnome.org/Nautilus/ProgressWindow> It's probably easiest if any comments on the design are added to that page, rather than in this bug report.
Just found this bug, looks interesting. But I see that 2.24 is now also in UI freeze. Something for 2.26, then?
*** Bug 550000 has been marked as a duplicate of this bug. ***
*** Bug 555810 has been marked as a duplicate of this bug. ***
This bug haven't seen some activity in a while. Looking at the wiki page linked to by mpt it seems like an entirely new design is in the works. Until this design is finalized, could we change the relief of the 'stop' button into 'GTK_RELIEF_NONE'? That way, the height of the progress bar and the button would at least appear to match.
Isn't mpt's design finalized already? MPT: is there anything currently missing in the spec or is it ready to be implemented?
Five months later I've reviewed it and only had one WTF moment, which I've corrected. <http://live.gnome.org/action/info/Nautilus/ProgressWindow?action=diff&rev2=42&rev1=41> So yes, I think it's ready. One thing I haven't specified in detail is how times greater than one hour should be rounded -- but really, there should be a standard round_off_time_estimate() function for that somewhere, it shouldn't be specific to Nautilus.