[Hardy] "File operations" window always on top and unminimizable

[Murat Gunes]

Binary package hint: nautilus

The "File operations" popup window in the new gvfs-enabled Nautilus in Hardy always stays on top, has no minimize button, and cannot be minimized by clicking on its window list entry. This results in having to view the progresses of the file operations in the forefront, which is not acceptable in a multitasking environment.

[A. Walton (awalton)]

The new file dialog places an icon in the notification area, and can be reduced to the notification area by clicking it. Is this unacceptable too?

[Murat Gunes (mgunes)]

In my experience (Nautilus 2.21.5) this didn't happen. I'll test the latest version and see how it handles things.

[A. Walton (awalton)]

Ooh, looks like I misspoke a bit; the notification icon is always there during a file operation, however, clicking the close button in the file move dialog closes it, leaving the icon in the tray until the action is finished. The dialog can then be restored by clicking the icon in the notification area to check the current progress.

It seems this might actually be a slight regression (or my memory is faulty this morning and it never did what I said earlier to begin with). Either way, if this feels too wrong, it's better to make this known now than to let it go undiagnosed.

[Mario Vukelic (kreuzsakra)]

I don't want to judge prematurely since I don't know the greater context, but on first glance this seems like the winner of the Window Operation Obfuscation Competition. It might make a bit of sense if this was done Gnome-wide, but if only in Nautilus I am afraid few people will get it.

I guess I have the most doubts about "clicking the close button in the file move dialog closes it, leaving the icon in the tray until the action is finished". I would _never_ click the window close button since I'd be afraid of canceling the copy. This might fly in a Mac world, since at least until OS9 (dunno about OSX) they had a quite consistent separation of window vs. application (though I think many people didn't get that either and consequently left applications running), but people used to Windows aver very much used to closing window == exit.

[Mario Vukelic (kreuzsakra)]

This is of "Low" importance? It's a major UI change! (Looks small but totally breaks consistency)

[Mario Vukelic (kreuzsakra)]

I thought about this some more. I think it's problematic if this stays as such an isolated case in Gnome window management as it is today. E.g., when I have discovered this feature (against all odds), can I then apply this knowledge to other windows and click their Close button to minimize them to the "tray" (notification area, in fact)?

If Nautilus alone is going to use this, then it definitely has to try and integrate more consistently. Wouldn't it make more sense, then, if the file copy window had no close or maximize buttons, but only a minimize button which would minimize the window to the notification area?

I understand that it saves on clutter in the panel's window list applet, but one thing I resent is that now I can't see the copy progress without mouse action (grabbing, moving, clicking). In the old version, the fill status of the button in the window list would give an indication by just looking. Maybe the notification area icon could at least show an overall progress in some way.

[Sebastien Bacher (seb128)]

Low because that's only an UI issue, that doesn't mean it should not be changed for hardy though

[Pedro Villavicencio (pedro)]

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=512778

[Sebastien Bacher (seb128)]

The bug has been fixed upstream now

[Launchpad Janitor (janitor)]

This bug was fixed in the package nautilus - 1:2.21.92-0ubuntu1

---------------
nautilus (1:2.21.92-0ubuntu1) hardy; urgency=low

  * New upstream version:
    - Build fixes
    - Fix crashes and leaks (lp: #190996)
    - Fix handling of desktop file launchers
    - Better handling of desktop file icons
    - Semitransparent DnD icon support
    - Avoid showing progress info when dialogs are shown (lp: #188259)
    - Allow minimize of progress window (lp: #185339)
    - Handle beagle >= 0.3.0
    - Close properties dialog on escape (lp: #54887)
    - Make custom icons work again
    - Fix fuzzy icons (lp: #186840)
    - Duplicate file if copies to the source directory (lp: #191138)
    - Support open with dialog for multiple selected files
    - Ressurect connect to server dialog
    - Allow theming of free diskspace chart colors
  * debian/control.in:
    - updated libglib requirement
  * debian/patches/90_from_svn_allow_setting_custom_icons.patch,
    debian/patches/90_from_svn_transparent_icons_when_composite.patch:
    - those changes are in the new version

 -- Sebastien Bacher <email address hidden> Tue, 26 Feb 2008 00:06:57 +0100