FileZilla 3 development diary

[botg]

Some progress report:

- Comparing directories works fine
- Listings will be aligned side-by-side (depending on used layout)
- Scrolling is synchronized between local and remote listing

Currently I'm refactoring the code a bit, I'm trying to get rid of the high amount of code duplication between local and remote file listing

[lwc]

Please stop v3 from loading my floppy drive on each load. It drives me nuts...

Some notes about editing:

* The remote editing is impossible to work with because it keeps asking me if I want to keep/delete the local temp file.

* Please add v2's local "view/edit" and "open" commands.

[botg]

Ask Microsoft to fix it, it's a problem with Windows.

[lwc]

Are you talking about the first issue? How come it doesn't happen in v2?

[botg]

No idea, it shouldn't even happen with FZ 3. All that FileZilla does is to enumerate all drives and to get the labels of all drives. For some stupid reason Windows doesn't remember the labels of floppy drives and checks all the time...

[lwc]

What about my notes? Will you give them some thought?

[botg]

When it's done.

[botg]

While implementing the directory comparison code I've noticed again how similar local and remote file list are. Yet still they are very difference, sometimes quite obvious, sometimes more subtle.

So far I could factor out the following code into a common base class, which also gets used by the queue in some cases:
- Scroll event handling
- Prefix search navigation

So far that's rather generic list control code, hence I named the class wxListCtrlEx in lack of a better name.

I'll try if I can also factor out the sorting code somehow, as it's again rather similar between the local and remote file lists.

[botg]

Ah, this day started so well. Could not possibly become any worse.

A nice mail in my inbox about a new security updates available for Debian Etch.

So I logged into filezilla-project.org (which is running Etch) and started the update procedure. One of the updates available was a kernel update. Installing it was simple and afterwards it wanted me to reboot. So I did. But the server did not come up again. Panic!
Even though Debian told me that I was about to install the same kernel version, I figured out it must have changed and that I forgot to tell the boot loader about the new kernel version.

So I went to the server administation interface of the hosting company, enabled the rescue system and initiated a hardware reset. 15 seconds later the rescue system was up and running. Lucky me I then did the usual mount sequence (root partition, and proc, binding dev). And of course it's using the terrible lilo boot manager. Anyhow, one command and it was fixed again. One more reboot and the server was back up and running.

What's the problem with nearly all operating systems? They absolutely love to piss you off by overwriting your custom bootloader. But if you perform a simple update inside the system, they fail to detect and update the very same bootloader they have written themselves.

[sonu1234]

can you plz describe here what all new features or bug fixes each newer versions haves this will give all the File Zilla user an idea that why should they update to the newer version....

[eyebex]

This is not the right place to post a changelog. The changelog can be obtained for each release from the project download page:

http://sourceforge.net/project/showfile ... p_id=21558

Simply click on the brown-ish "Notes" icon for a release. Alternatively, see:

http://www.filezilla-project.org/changelog.php

[eddan]

In addition to the links eyebex gave, check out http://wiki.filezilla-project.org/FileZilla_FTP_Client which probably is the best changelog for the average user.

[botg]

A few days ago, Vadim Zeitlin, one of the wxWidgets lead developers, proposed to refactor large parts of the wxWidgets socket class. (See http://thread.gmane.org/gmane.comp.lib. ... vel/95761/ for the discussion).
The primary reason is that nobody is able to understand the socket code fully anymore. I have tried myself a few times in the past to investigate a few bugs. It was a rather painful experience. As such, adding new features to wxSocket, e.g. sockets for GUI-less programs, has become increasingly difficult.

Naturally I've been very interested in this discussion. Without a good socket class, FileZilla cannot function.

Amongst other things, we were discussing the semantics of the various socket events. While looking through the code, I've noticed a problem in the way wxWidgets did reuse socket message ids on Windows. (For use with WSAAsyncSelect).
There is a chance that a socket ID can be reused while there are still pending messages to be processed. As a result, a new socket can receive messages intended for a previously destroyed one. After discussing a possible solutions I came up with a patch for this problem as well as a test case: http://sourceforge.net/tracker/index.ph ... tid=309863

[botg]

I've spent some time to improve FileZilla's support for right-to-left languages on wxGTK (e.g. Linux and the likes).

I've fixed the following problems:

• Positioning of message log
• Send/recv indicators
• Queue tab navigation buttos
• Queue tab display

To fix the last problem, I had to create another patch for wxWidgets, see http://sourceforge.net/tracker/index.ph ... tid=309863

Other than that I've fixed a problem with the keepalive timer under wxGTK leading to crashes. I've also changed the code so that errors while writing to a file are now critical since they almost always require user interaction to be resolved.

[botg]

Happy new year everyone.

Yesterday I did release FileZilla 3.0.5-rc1. The most important new features are directory listing comparison and the ability to open/edit local files. In addition, lots of bugs have been fixed.

The most important one is regarding the language selection in the settings dialog.
Under Unix(-like) systems, it never really worked. Reason is that at the point wxWidgets sets the locale, the C/C++ runtime library, GTK+ and others have already been initialized with the system's default locale (or whatever locale had been specified with the LC_* environment variables). I did write some code that to set proper environment variables and to call setlocal before initializing wxWidgets itself. As part of the changes, I've added a way to use the default system locale. The only expected side effect is that the language will be reset to the default system language for all users if upgrading to this version. Hopefully there won't be any unexpected side effects.

Besides that I've updated the build scripts to use an unofficial NSIS branch with full Unicode support written and maintained by Jim Park (http://www.scratchpaper.com/). Lots of users, mainly from Asia, were having problems installing FileZilla. This was caused by them running the installer from a directory containing non-English characters. Unfortunately the official NSIS installer is not Unicode aware, and to make things worse, Windows does not use a sane character encoding like UTF-8, but actually some other horrible MBCS encodings, causing quite some problems.
Adapting the patched NSIS wasn't easy, since all FileZilla builds are packaged automatically on a Debian based server and unfortunately, the patched NSIS compiler cannot be built on a POSIX platform anymore. I've briefly looked at the source, but gave up quickly. It's nothing hard, just lots and lots of work, requiring time I don't want to spend on something "trivial" as an installer. After all I've got some other project to lead (guess which one ). Took me a while, but I've found a solution. I've installed the Windows binaries of the patched NSIS and am running them through Wine now.
Starting with tomorrow's nightly, FileZilla's installer should be fully Unicode aware.

Now to something completely different. I did something very stupid a couple of days ago. While tinkering with my backup scripts which make daily backups of almost everything (SVN, CVS, wwwroot, forum and wiki databases and so on), I've made a typo while typing in an rm command. As the result, my backup scripts were gone. And somehow it didn't occur to me to also backup the backup scripts.
As you might imagine, I had some fun recreating my scripts. Obviously, the first thing I've implemented is making backups of my backup scripts.