Re: pluggable context menus ...

[<bordoley msu edu>]

Dave Fallon <davef tetsubo com> said:

> 
> The one thing I don't like about about manuel's suggestion is having "open" 
>in the pluggable context menu, as we already have a sub-menu dealing with all 
>the "open" options.

nod

> 
> Some questionable entries:
> 
> 	* Open in new window - this one seems not really very useful as most 
>everything that opens in an external application by definition opens in a new 
>window. It's more debabtable than some of the other,s,b ut might be better 
>somehow moved into open with...

One idea i've seen mentioned in bugzilla is the use of a modifier key
(alt,ctrl) to switch the open mode, ie. if you use open in same window,
modifier +clk opens in a new window, if you use open in new window mode,
modifier+click opens in the same window. This is a little hidden and we would
need a keynav equivalent, but since this feature is so unused i would guess it
would be ok. 

> 	* Duplicate - This seems pointless, as daveb points out, as it's just 
>the same as copying/pasting in the same folder. While I think the vi thought 
>process rocks (having a shorter way to do everything), this seems not worth 
>the space.

Well for the sake of being fare, the mac has this, although i'm not sure if
its in the context menu or not. I don't think context menu use is as prevalent
on the mac though either.

> 	* Remove Custom Icon - of any of these, this is the one I'd vote to 
>remove first. It's fairly rare (if not really rare), and more importantly, you 
>can't *set* a custom icon from the context menu, just from the properties 
>page... where there's a remove custom icon button. 

I removed this from head already awhile ago.

> 	* Restore icon's original size - these don't seem to be that useful, 
> but I don't see a better way to fit them into the context menu, so we may as 
>well keep 'em. If we did something where we hovered over the icon, and that 
>displayed the resize icon handles, then maybe we could drop it, but we need to 
>figure out how to reset the icon at that point. Might be a future thing to 
>work on.
> 

The problem is accessibility. We need to have an accessible way to resize
icons, so I don't think the hover over = resize handles is an acceptable
solution to this problem, although it would be nice for the general ui as it
makes this feature more directly manipulative == good :)


> 	and for the right click with nothing selected:
> 
> 	* clean up by name - this seems like another extra entry to save a 
>click, since arrange icon -> by name does the exact same thing, and does it 
>"better", as that works in both automatic and manual layout, while clean up by 
>name is greyed out most of the time. note that if we get rid of this, it's >
>also in the view menu (and should be booted from there as well).

The ui review had mentioned this and I've tried to bring it up a few times as
well. The real solution imo opinion is for manual mode to use the same arrange
menu items as sorted mode. However this poses problems as well, since sorted
mode is currently hard sorted, hence the radio buttons in the menu. Dave and I
have talked about this on IRC a bunch of times before, and we've never really
came up with a good solution. Some ideas, we could have two modes auto arrange
and manual (ala windows), the current solution is very macish, perhaps layout
could always be manual but have some sort of automatic snap to grid (I sort of
like this idea, only problem is what do you when a icon view window is
resized? perhaps automatically adjust the layout, don't adjust it just add
scrollbars? not sure).

> 	* Use default background - this is debatable. It's not very useful, but 
>it makes sense where it is. It's not quite the same redundancy of the remove 
>custom icon. I'd probably keep it, but I'm bringing it up for completeness's 
>sake.

I agree with you and awhile back proposed a patch that removed this. However
Alex uses the feature so I at least got him to change the menu entry from
"reset background" to "use default background." Actually my prefered solution
is a change background menu entry that brings up a dialog similar to the
background capplet, for which you could choose to set the background for the
folder, or choose the new background to affect all directory backgrounds (I
even think code exists to do this already in the nautilus gconf keys).


anyway food for thought

dave