Re: `New' sub-menu in desktop's rightclick-menu

[Alex Larsson <alexl redhat com>]

On 22 May 2002, Dave Bordoley wrote:

> On Wed, 2002-05-22 at 14:34, Alex Larsson wrote:
> > The symlink doesn't sound all that useful, and what would it do? bring up 
> > a wizard? Doesn't sound like a good ui. Drag and drop, or paste as symlink 
> > seem much more natural to me.
> 
> The symlink thing might be a bad idea. However, I was talking with seth
> about the new launcher dialog, and there is a good chance that post 2.0
> it is going to be divided into seperate mini apps to create each
> different type of .desktop file (ed. application, link, fs device...etc)
> since users don't really need to know the specifics (that these are all
> different types of .desktop files), and the current create launcher ui
> is well damn near impossible to use. So these would probably be in the
> menu too.

Why would someone want to create a FS device desktop file? They are 
internal implementation specifics of how we handle mounted devices.
And as I said above having a create link menu that brings up a dialog 
where you select where the link goes (file selector?) seems like a bad way 
of doing it. Drag and Drop (with shift hold down to create a link) or 
"Paste as Link" (for accesibility) seems like much more natural operations 
to me.
 
> create => folder
>        => application launcher
>        => link (the .desktop type) etc.
> 
> Also there have been requests for functionality similar to that of
> windows to create new files (see bug 41787) that could also be in here.

Now, this is something I would want.

> Regardless if we create a subfolder or not we need to change the wording
> as new window/new terminal are completely different types of operations
> than new folder and new launcher. I think create is a better word since
> the metaphor is really strong, the user is creating something.

I agree that Create is probably the right word to use.
 
> > I am not sure we want the possiblility to create application launchers 
> > anywhere. For the desktop it makes sense, and maybe we can look at the uri 
> > and allow it for some of the vfolder directories. But it doesn't make much 
> > sense for e.g. /tmp.
> 
> It is possible that i'll want to add other .desktop files like links to
> other directories in my home dir. I see no reason for us to tell users
> where they can and can't make .desktop files, that's really their
> decision, especially when they can just drag and drop them there from
> the panel anyway.

It is possible, but it may not be very likely. And for links you could 
just use symlinks. That makes more sense than .desktop file links.
 
> Let me admit a bias, I think the desktop should be $home. If it's $home
> well than new window doesn't make so much sense, since it simply open's
> the file manager to the directory your currently looking at anyway, so
> it's repetitive. i guess this also leads to my opinion that for the vast
> majority of users on multi users systems where gnome is most likely to
> be used (like large college installations) most users will only have
> access/interest in $home anyway (I know this is the case on my school's
> unix machines). I would rather add a filesystem launcher on the
> desktop,that opens nautilus in the / directory, similar to the macs
> system launcher (i think thats what it's called). This is is actually a
> much better ui since it immediately give power users access to the whole
> file system, they don't need to traverse up from $home to /, they are
> already there, and they now have access to any location on the file
> system.

In a perfect world $HOME as the desktop may make sense. But the fact is 
that we live in a hetrogenous environment, and a lot of apps write random 
stuff in $home that the user are not really interested in, and that are 
potentially dangerous to move/remove. Therefore I don't see 
home-as-desktop being the default in the near or medium term. I would like 
to make the desktop directory a visible directory though.

I think your argument that the new window would load the same directory, 
and therefore the new window operation is not needed is wrong though. The 
reason you're opening a new window is probably not to navigate $home, but 
to do some other file management that is not possible with on the desktop 
window (because it can't change directory, because it's covered with 
windows, because it has no menus, etc.).

They are not only interested in $HOME. They are also interested in the 
subdirectories of $HOME (and the folder icons for them are covered with 
app windows), other peoples homedirs, university-course specific 
directories, etc. 

On the other hand I think $HOME is a great place to start the new window, 
since it's often a good starting place for what you want to do, whereas 
you basically never want to go to /. Staring in / would also force 
newbies to immediately learn the unix one-combined-filesystem-hierarchy 
idea, which I think makes it harder to understand initially. A lot of  
people I know that use computers don't even really get the filesystem 
hierarchy idea.

> however this issue obviously pushes deeper into the discussion of is
> nautilus going to just be a file manager, or is it going to aim higher
> and become a full desktop realization of the shell. I can't make that
> decision, but we need to think about it.

This is just throwing around the fluffy expression "full desktop 
realization of the shell". What does that mean, and why can't a file 
manager be that. 
 
> Well at least in the file manager view, open with terminal would appear
> in the sidebar for folders. I'm not convinced that new terminal has to
> be in the context menu, especially when the default panel has a terminal
> launcher on it. Why should we clutter the context menu with this when it
> actually takes less work (one click vs. two) to launch this from the
> panel using the launcher.

Having it in the sidebar makes some sense, although a lot of people are 
hiding the sidebar. :)

There is an important difference between the context menu terminal and the 
panel terminal icon though. The context menu starts the terminal in the
particular directory the file manager is viewing, and therefore it in some 
sense lets you combine the best aspects of the terminal and the file 
manager. Starting the terminal from the panel loses the context you've 
build up in the window manager.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a time-tossed flyboy matador who hides his scarred face behind a mask. 
She's a provocative goth mechanic with an MBA from Harvard. They fight crime!