Inconsistent behaviour switching to last application window of copy dialog

confirmed, the issue happens here. Subscribed 3v1n0.

This is actually a wanted behavior, so setting it as invalid.

Basically, not user-visible flagged windows (like the copy dialog is) have lower priority, so they can be selected only choosing them in the switcher or using the proper quicklist.

@Marco: How would you explain to a user, that a perfectly visible window is a "not user-visible flagged window"?

And of lower priority copy operations are mostly not. Have you never been already late and need to copy a big vmware image, a bunch of fotos etc?

In many, many cases copy operations are holding me (or other people) back from leaving and so it is high priority to see the status.

The indicator in the launcher is nice, but doesn't tell me about estimated remaining time and files which is often important just to know if I should go for a coffee, continue on another work or just wait the last 20 seconds to have it finished.

In any case for a user it is inconsistent because the normal user does not know your design logic. To have the user feel comfortable, effects must be foreseeable which means: Simple rules. Switch to last active window should therefore include the copy dialog.

Oh, and I found several other applications displaying small copy-like dialogs, e.g. compressing files or clone-dialog in Virtualbox - just to give a few examples. Those behave exactly as any other window - as desired.

The user cannot distinguish why and whether some dialogs are "counted" as last active window and others not.

So, these applications should be fixed then.
The nautilus progress dialog, is quite an exception btw, because it's actually a window (that can run even when the parent window has been closed). This behavior has been added to fix bug #784804 and it won't be fixed unity side.

Feel free to set as affected here the applications that should follow this policy as well.

On Tue, Jun 19, 2012 at 1:29 PM, Marco Trevisan (Treviño)
<mail@3v1n0.net> wrote:
> So, these applications should be fixed then.

Sorry, but you cannot put such a demand on the others. Apart from the
fact that you cannot expect an application to consider each window
manager around (and this is in fact the job of the window manager or
desktop environment) what rules apply? When is what window to be
skipped and when not? - And then you need to instruct these rules to
the user because the normal user expects the same behaviour for all
windows as the user cannot guess your motivations and rules which are
not visible by looking on the window.

> The nautilus progress dialog, is quite an exception btw, because it's actually a window
> (that can run even when the parent window has been closed).
> This behavior has been added to fix bug #784804 and it won't be fixed unity side.

It is good to stay visible even if nautilus parent window is closed.
But appearently it is "counted" to the list of nautilus instances (as
displayed in that group when switching windows) so it should be
threated as such.

And an "exception"? There are plenty of other applications running
operations in asynchronously displayed windows.

> Feel free to set as affected here the applications that should follow
> this policy as well.

The policy of nautilus threating the copy dialog differently is the
unwanted behaviour here!
All the other apps are doing fine!

Best regards.

As said, most of other apps have dialogs for such operations, but they have a parent window, so when they get focused, even the parent window would be. This won't happen for nautilus, that's why it's special.

However, according to design this is currently the wanted behavior. Probably that dialog should be re-engineered, more than fixing unity.

I think, I now understood why you are concentrating so much on the parent.

And I am now not sure if this is a unity or nautilus problem, however:

When you click on the nautilus launcher with several windows open, you can see all windows (including the copy progress window) as separete instances that can be switched to. So somehow unity or nautilus "knows" that the progress dialog is a separate instance of nautilus.

I compared that now to behaviour in gedit, geany or LibreOffice when opening the File open dialog with the following result: App window and file dialog were displayed as separate windows when clicking on the launcher, but: Whatever I clicked of the both windows, the file dialog came to foreground - which is ok, because it is displayed modal/synchroneously/blocking.
ALT+TAB brings back to that window - ok.

When the dialog is displayed asynchroneously/non-blocking there is no problem in switching to the application window instead (new browser window is such an example or several different email detail windows opened from Thunderbird). I do consider Thunderbird as comparable with Nautilus here. A copy dialog is not much different from a details or copy progress window in Nautilus.

And indeed here we see another difference: Press ALT+ENTER on a file in Nautilus. A seperate window opens. You can now use the launcher icon to switch back to the main nautilus window and either open another file details with ALT+Enter. The only difference here is that (for whatever reason) the details dialog has the stay-on-top-flag set. Anyway you can focus the main window in the background.

How ever should a dummy-user understand why what behaviour?

The behaviour of Thunderbird or Firefox in displaying new windows mostly asynchroneously is the way which is most common sense I would say. There are application dialogs that need to be displayed synchroneously, but oft course copy dialog or file details window make sense to be displayed asynchroneously without blocking the main application window and hence: Both should be switchable to and considered as last active Window when switching windows.

Thank you for understanding - I know this is great advantage in Ubuntu community that arguments count. Experienced differently with several commercial software.