Re: Volume handling proposal
- From: Alexander Larsson <alexl redhat com>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: Nautilus <nautilus-list gnome org>, "desktop-devel-list gnome org" <desktop-devel-list gnome org>
- Subject: Re: Volume handling proposal
- Date: 17 Sep 2003 12:17:09 +0200
On Tue, 2003-09-16 at 17:55, Rodrigo Moya wrote:
> On Tue, 2003-09-16 at 15:40, Alexander Larsson wrote:
> > Network mounts are typically used in two ways:
> > The most common one is when a person is working in a group or a
> > project and they share some server where they store their files, or
> > you work alone but often use a particular storage server. In this
> > case you typically get told exactly what share to use, and you never
> > really use any other shares.
> > The less common case is in more ad-hoc style network such as
> > university dorms where lots of people have machines set up and you
> > want to browse them all looking for some file. Once you've found the
> > file you typically aren't interested in that server anymore.
> >
> That is a reason for having an easy way for users to navigate the
> network, easily accessible from their normal navigation program.
Yeah. But it also means that we have to cater to the other group, which
is done via the "connect to server..." thing.
> Also, what about network mounts that are mounted at system boot time? In
> some cases, those are shared storages, so it makes a lot of sense to
> have an icon/toolbar/whatever to easily access them. But, in other
> cases, like NFS-mounted homes, it doesnt make too much sense to do so, I
> guess. So, I think there should be an easy way to know which kind of
> network mounts each one is.
The way we solve this currently (user mounts are visible) doesn't work
well, so the way i proposed it is that you have to connect to the
locally mounted filesystem to get the icon for it on the desktop etc.
However, in work environments such things could also be set up by the
sysadmin for new users, to avoid the user having to do this himself.
> > Second one is the MacOS X concept of connected network
> > volumes. You select "Connect to server" in a menu, and then using
> > either manual typing or a browser for some types of servers you select
> > a server and directory. This location is then saved between sessions
> > and easily accessible. This allows you to quickly access commonly used
> > shares, and is also a way to introduce a way to intelligently handle
> > non-discoverable network shares. At the very least you only have to
> > figure out/get told that strange ssh: uri once.
> >
> With a little bit of work in the nautius-add-server tool, we could have
> this in network://. The problem I see with the current network: view is
> its simplicity, since the only way to access a network volume is by
> knowing in advance its name+path.
Nah, it has to be done at a lower level so these things can be made to
appear on the desktop, file-selector etc. I think just using gconf to
store the connected servers would work fine. Then gnome-vfs and nautilus
just has to use this. network: at the moment is a vfolder, with all the
problems vfolders have.
> > Third one is the "Network" location. Ideally this contains all the
> > servers in the current windows workgroup, all zeroconf webdav servers
> > on the local net and all other discoverable network shares. It also
> > contains a "Windows Network" icon linking to smb://.
> >
> hmm, you mean having all discovered servers, regardless of the protocol
> in the Network's root view? If so, that sounds really nice, and I guess
> would help a lot users, since they just dont need to know which
> protocols are used.
Yes. Thats what i mean.
> > Windows XP does
> > this a little bit different, they list every share on every server in
> > the workgroup as "<share> on <server>". There might be quite a lot of
> > these though, and querying for them requires you contact each
> > computer, so this is probably not a good idea.
> >
> I think it's much cleaner to show the server names, and when clicked,
> show the shares for the selected server.
Yeah.
> > I'm not sure what roots we want in the fileselector. At the minimum we
> > want the desktop ones, but do we want e.g. unmounted floppies/CDs there?
> >
> I'd vote yes
Yeah, i'm leaning towards yes too, but it depends on how easy it will be
to have the file-selector actually mount stuff.
> > "Network" is a bit hard, since it has to be a combination of data from
> > various vfs backends. It needs some thinking, but I think its implementable.
> >
> are you thinking on a gnome-vfs module for this? Or a view as it is now?
> I am looking forward to implement this.
A gnome-vfs module i think, since it has to be browsable by the file
selector too. (And its not currently a view). Since its sort of a
collection of other vfs modules its a bit complicated to implement
though. I think it will be a lot easier once we get the gnome-vfs
daemon.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a deeply religious bohemian master criminal who hides his scarred face
behind a mask. She's a psychotic renegade advertising executive living on
borrowed time. They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]