Re: pluggable context menus ...

[Dave Fallon <davef tetsubo com>]

On Sat, Oct 26, 2002 at 03:53:27PM -0400, bordoley msu edu wrote:
> Manuel Clos <llanero eresmas net> said:
> > My idea is to have a "mime type" entry just after "open with..." that 
> > has all these options. So the menu will always be there and will never 
> > get empty.
> > 
> > So, for "image" mime type you get:
> > 
> > open
> > open in new window <--- remove this one please ;)
> > open with...
> > image ----> open  <--- this one is bold because is the default action
> >                     print
> >                     rotate
> >                     resize
> >                     show notes
> > 
> 
> The HIG also states that context menus should not have sub-menus so either way
> is a comprimise. also why would you have open in the context menu, I would
> find this rather confusing to have two open menu entries. Also in regards to
> archives, I don't think they should have any menu entries. We need seemless
> integration of archives into nautilus (via vfs) anything else is masking the
> problem.

While not dealing with the specifics of the menu, I definately agree with manuel - we should work out a good static structure of the right-click menu, then disable the unused entries, rather than not displaying 'em. For the pluggable entries, we have a sub-menu that contains the entries if they exist, or it's disabled (but still present) if they don't. 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.

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...
	* 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.
	* 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. 
	* Stretch icon
	* 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.

	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).
	* 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.

This all being said, rock! this is going to be very cool, and make a lot of naut script writers very happy. Go james!

dave