On Tue, Apr 21, 2015 at 03:06:37PM +0100, Allan Day wrote:
Hi all, I've been taking another look at the "add drive" designs for Nautilus, which will hopefully be worked on as a GSoC project this summer. There are a few elements to the design, and there are some open questions about it (both design and technical), so I wanted to lay it all out in writing. There are a couple of goals for the design: 1. Retire the existing "Browse Network" part of Nautilus - it's clunky, seems rather old fashioned, and overlaps with "Connect to Server". 2. Stop showing all internal volumes in the sidebar - they're not relevant a lot of the time, and clutter the sidebar. The design aims to address these goals by: * Merging "Browse Network" into the "Connect to Server" dialog. Where you currently see a list of recent servers, there would also be a list of servers that have been discovered on the network. * Instead of showing all internal volumes in the sidebar, hide them by default but add controls to allow the user to configure which ones are displayed. A further step could involve merging Connect to Server with drive configuration, into a generic "Add Drive" dialog (which could be called something else, such as "Add Drives and Servers") [1]. As far as I'm concerned, there are a number of open questions which could influence the final design. These are: 1. Is it possible to discover servers on the network, in order to present them in a list? Are there scenarios where this wouldn't work for UX reasons (say, in environments where there are a lot of servers)?
This is going to be tricky. At the moment, network:/// shows avahi-published services (e.g. afp, sftp, ftp) and windows servers. Some of them may be directly mountable (equivalent to a "drive"), others may be a server that needs to be logged into before you can even see what "drives" are available to mount. The windows section can show multiple different workgroups/domains, each with tens of servers, each with several shares. I'd imagine this to be common on an office network. Presenting this as some sort of tree may be possible, although I'm not sure if it's any better than the existing implementation, which is just a filesystem tree. From a technical perspective, enumerating all the windows share to show in the Connect dialog would be problematic since it isn't really an asynchronous process. But hey, technical problems can be fixed :-) -- Ross Lagerwall
Attachment:
pgpJnHXrUtpyc.pgp
Description: PGP signature