Re: New ftp dialog patch

[Pavel Roskin <proski gnu org>]

Hi, Walery!

> Here is the patch to make ftp dialog with ftp links, like in far manager.

I have tried your patch.  When I select "FTP link..." it shows a message
"Failed to open: /home/proski/.mc/ftplinks"

This is very unfriendly.  When you first use e.g. the hotlist, you are not
getting any such message - mc creates the hotlist for you.  Why should it
be different for the FTP list?

Please test your patches, especially on the new accounts that don't have
~/.mc directory yet.  Put yourself into the position of a new user who
doesn't know about ftp list.

I personally keep all my favorite locations on vfs filesystems (fish and
ftp) in the hotlist.  I don't know why you want to duplicate its
functionality of the hotlist.

Anyway, I don't think we should add new functionality apart from fixing
bugs and implementing already documented features before releasing 4.5.55.

Some comments about the implementation.

1) Please don't mix malloc() and g_malloc().  I believe that MC has little
chances to work on systems that use different memory pools for those
functions, but some day we'll have to clean it up.  So it's better that
all new code uses g_malloc() unless the existing code uses free() on the
result.

2) Try to reuse the existing error messages.  Don't forget that there are
30 translations for MC, and every your message will be translated into 30
languages.  Why use non-translated "Failed to open: %s" instead of already
translated " Can't open file %s \n %s ", which by the way is better
because is gives the error string.

3) Please be very careful with all translatable texts.  Message "There is
no valid links in %s" should have "are" instead of "is".  Actually, I
doubt that this message will be useful.  There are no links - so what?
Why do you consider this an error?  If the hotlist is empty it's not an
error.

4) Please separate messages from "decorative elements".  There is no
reason every translator should translate both " Error " and "Error", not
to mention your fancy "<<" and ">>".  If the dialog doesn't look well
without spaces, fix the dialog to add them when needed.

5) New dialogs should be documented in the help.  I understand that you
were trying to do it, but we should avoid adding undocumented dialogs
just before the release.

I would prefer if you fixed the charset support as I asked you (i.e. the
terminal output settings should be restored).  It's not the right time to
push new half-baked features - MC has enough of them already.

-- 
Regards,
Pavel Roskin