Client Feature Suggestions!

[Gibbz]

A few things id love to see added to filezilla... Which would save me a lot of hassle


* a seperate tab for currently downloading file(s)

* if i close the program, it should remember the download que

* option to resume/minimize to tray on startup

* limit to 1 download per ftp, but be able to download off multiple different ftp's at once( ie x transfer from each ftp at once)

* minmize to tray on close button

* move the explorer panes to tabs. So the whole interface is tabbed. IE i click the ftp tab to open the explorer view, or i click the que file tab to change back to the qued files tab, instead of having the interfaces spline into top and bottom half...

[botg]

* if i close the program, it should remember the download que

It already does.

[hairytony]

"minmize to tray on close button"

That would be misleading. If i press close I assume the application (process) is terminated and not running in the background.

[boco]

FileZilla 2 featured an extra button for Minimize to tray. For me that was the best solution, no ambiguity.

[botg]

Extra button conflicts with different themes and thus is unfit for FZ3.

[Brybo]

Hello everyone, I'm new to the forum and I love FileZilla.

A neat feature I would like to see is the ability to change the fonts, font color and
background color of the windows as well. What I am looking to do is change my font
to a "terminal" type of font, with a lime green color and a black background.

Basically make filezilla look like an old hacker terminal or something I guess is what
I'm trying to say?

If there's a way to do all this already, please point me in the right direction.

Thanks.

[botg]

You can do that already in your operating system settings. FileZilla will use the fonts and colors defined in your system settings.

[Brybo]

You can do that already in your operating system settings. FileZilla will use the fonts and colors defined in your system settings.

Yeah but that would affect all of my other programs though. I was just wanting to apply this to FileZilla only. I know FileZilla has "icon" packs, but I didn't find any font or color customization within the FileZilla settings anywhere.

[STEF]

When upload to a server :
=> option to automaticly create .sfv file / each folder to send
=> send the .sfv file in first of all files in the list to transfert

... to have the possibility to see the transfert status, rate, complet or incomplet files, with some FTP server understanding these .sfv files

Best regards

SteF

[botg]

When upload to a server :
=> option to automaticly create .sfv file / each folder to send
=> send the .sfv file in first of all files in the list to transfert

... to have the possibility to see the transfert status, rate, complet or incomplet files, with some FTP server understanding these .sfv files

Best regards

SteF

Won't ever happen, .sfv is not a standardized file format.

[dont]

Well who cares. The user want it, not some robot. SFV has been used for many years and is still used in thousands of releases daily. Standardized or not, its extremely useful, more useful then 99% of the standardized file formats.

[botg]

What is the semantic of an unstandardized syntax?

[tim242]

Hello there,

As STEF requested, I would also like to see some SFV functionality added to the FileZilla FTP client.

There may be some confusion but I believe the functionality desired by us both is just to have an ability so that if we flag a local directory and that directory happens to contain RARs, .nfo, .sfv, file_id.diz, and other files representing some kind of release that prior to upload the queue is scanned and (perhaps if the option to do so is turned on) the .SFV, .NFO, file_id.diz files (which are all generally no more than 10k in size) are uploaded FIRST before other files in this directory. We would want to do this as some FTP sites that we are sending files to may have file processing capabilities which trigger events on the server when these files are received.

RaidenFTPd and the phpZipScripts addon at this link is just one example of an FTP server that can process SFV files: http://www.raidenftpd.com/en/plugin.htm ... s%20v0.79b

Based on this request I don't think you'd need to worry about the standardization of the SFV file/etc as no processing should be taking place on the client end.

Thank you for your consideration!
Tim

[tim242]

Hi ho!

I would still like to hear some more about File_id.diz and .SFV support in FileZilla. Here's a bit of specification related info on both:

file_id.diz:

http://en.wikipedia.org/wiki/File_id.diz
http://www.textfiles.com/computers/fileid.txt

More regarding .SFV

http://en.wikipedia.org/wiki/.sfv


Thank you kindly. Let me know if you would benefit from additional info or would like any feedback regarding beta testing. Cheers!

--Tim

[boco]

I don't think these are formal specifications? I'll give you an example, as you mention SFV, which is used to verify a file has not changed:

The HASH command. It is meant as a way to check the hash values of remote files just like SFV (though directly and not through files). But its authors take the correct way: There exists a formal specification (currently in form of a draft, if it is accepted it will become an RFC and therefore an official standard). Current version can be found here: http://tools.ietf.org/html/draft-ietf-ftpext2-hash-02. An RFC then leaves no room for interpretations, every developer who wants to implement it, will know exactly how and all implementations will work together (unless there are bugs, ofc).

So unless SFV would be a formal standard (is it, I couldn't find anything?), everone could implement it as (s)he sees fit. Leads to confusion and non-interoperability brtween implementations.

The same for FILE_ID.DIZ. First, let me say that file is well known to me (along with descript.ion, files.bbs etc.), and I certainly recognize its usefulness. But let me quote one sentence from the Wiki article you posted:

Traditionally, FILE_ID.DIZ's should be "up to 10 lines of text, each line being no more than 45 characters long." according to the specification v1.9 — this restriction however is rarely observed nowadays.

What is a specification worth if it isn't formal and binding? Imagine one developer cares for the spec and another implements the loose format - the result is that the former software would fail to properly read the files created by the latter, and nobody can be blamed!