Re: ftp and Nautilus



Laszlo, Calum:

Great work.  IMO, Dialog 1 and Dialog 2 work perfectly.

Naturally, the ideal situation would be that the check mark for
anonlogin shouldn't show up if anon login isn't possible at all.

Gnomevfs could check if anon login was possible by trying to log in
anonymously before showing the password box (Dialog 1), and hiding the
checkmark in Dialog 1 before showing it if anon login was not possible.

This has a con: the dialog 1 would show up with a bit of a delay caused
by the anon login test.  It also has a pro: if by any chance the user
wants to log in anonymously and intends to use the checkbox, gnomevfs is
already logged in and thus there is no problem or delay once the dialog
appears, it would be even faster since gnomevfs is already anon logged
in.

El jue, 20-05-2004 a las 09:24, Laszlo Kovacs escribió:
> Hi All,
> 
> Calum was kind enough to put together a proposal for going ahead.
> 
> It is all here:
> 
> http://www.gnome.org/~calum/usability/specs/ftp-login/
> 
> This needs changes in gnome-vfs (I have some of this code already) and 
> in gnome-keyring.
> 
> There are a couple of things to think about:
> 
> 1. With dialog2 we are proposing that the user will see the 
> authentication dialog coming back until they log in successfully or 
> press cancel. This is different from what we have now. Right now if the 
> authentication fails there is a warning dialog and that's it. The 
> proposal provides a better user experience. I am not sure yet where this 
> change needs to be made. It would be ideal if all vfs modules that 
> require authentication would nehave like this, but I think every module 
> would need to be changed separately for that.
> 
> 2. We are also proposing to change the authentication dialog for the ftp 
> protocol only, for other protocols it will stay as it is.
> 
> 3. If the uri contained a username the username field in the 
> authentication dialog (implemented in gnome-keyring) is not editable. I 
> think the reasoning behind this is that if the user wants a different 
> username or no username at all then they need to create a new launcher. 
> This is quite inflexible in general and creates a complication for this 
> situation as well. If we follow this thinking then if the user used 
> anonymous for the username in the uri then the tickbox should be ticked 
> in the dialog and the user should not be able to untick it. If we don't 
> do this then we don't have a consistent behaviour, however having a tick 
> box that can not be unticked is not good at all. Any suggestions 
> (particularly from the gnome-keyring maintainer) are welcome. I 
> personally think it might be good to make that username field always 
> editable again.
> 
> Any thoughts about this?
> 
> Thanks,
> 
> Laszlo
-- 
	Manuel Amador (Rudd-O)
	GPG key ID: 0xC1033CAD at keyserver.net

Attachment: signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]