Re: [Usability] Interacting with open folders, part 2.

[Maurizio Colucci <seguso forever tin it>]

Maurizio Colucci wrote:
> <old stuff>
>
> Some time ago we were discussing whether Gnome should allow interacting 
> with open folders. What does it mean? In real life, if I see an open box 
> of chocolates on my table, I can still act upon it: I can move it into a 
> drawer, on in another box, or throw it in the trashcan. The fact that 
> it's open does not limit my actions in any way.
>
> OTOH, in gnome, if I see an open nautilus window/folder on my desktop, I 
> cannot act on it. I can only act on its *content*. If I want to act on 
> the folder itself, I must go to the parent folder.
>
> What we need IMO is
>
> 1. Introduce a way to act on the open folder itself. Mind you: not only 
> to drag it, but also to copy it, move it, delete it, create a link to 
> it, etc. Simply adding a drag handle is not enough.
>
> 2. do it in a way that does not lead to menu item duplication (e.g. one 
> menu for the folder and one for the contents).
>
> Then I pointed out that the cleanest and simplest way to fulfill the 
> requirements is to add a way to *select the open folder itself*. Then, 
> the "edit menu" could continue to work unmodified.
>
> For example, a button which, once pressed, selects the folder itself. 
> Then you keep using the existing menu.
>
> </old stuff>
>
> <new stuff>
>
> I went on a bit with my reasoning.
>
> So we should be able to select the folder itself. But in spatial 
> nautilus this means selecting the window! (since folders and windows are 
> strongly indentified)
>
> So, what we really need is a button to select the open window.
>
> Where should this button be? Logically, it should be in the window's 
> title bar.
>
> But then, we have the problem that the edit menu is located inside the 
> window frame. To a user, it would not be intuitive what the scope of the 
> menu is. A menu cannot act on something that is outside of it.
>
> So the new proposal is: move the nautilus menu, (at least the "File" and 
> "edit" items) OUTSIDE the nautilus window. So the user can select the 
> window and/or its contents, and then use any kind of action without any 
> logical problems.
>
> </new stuff>
>
> Any comments?


In fact, I do have a comment, which I also posted here:

http://bugzilla.gnome.org/show_bug.cgi?id=129421

The day you decided that Spatial Gnome should identify windows and folders 
(with a bijection), it seems you did not realize the harsh implication of 
this choice: THAT THE USER SHOULD BE ABLE TO ACT ON WINDOWS JUST LIKE HE ACTS 
ON FOLDERS.

And with the same techique, if you want to avoid redundancy.

So, for example, we should be able to *select* windows. Also, we should be 
able to *delete* them, or *rename* them, as we do on folders. By means of 
some kind of *menu*, not only via dragging.  Possibly the *same* menu we use 
on folders! (Otherwise we have redundancy and clutter.)

Requirements that clash with the current tecnhical limitations of the
window manager.

So the day you decided for spatiality, in some sense you condamned yourself 
to the problem of having to rewrite the window manager itself to make the 
system logically sound once again.

Maurizio