Been rather slow development past few days due to real life responsibilities taking priority. Perhaps the most notable change was proper support for global searching in cgcomm protocol level, as well as in user interface.
A lot of thought has been given to the front page of the user interface, which is still missing. Basically, so far the plans for it include a statistics/overview-related information bar (~100px wide) on the right side, where there'll be a small statistics graph, plugin status(es) and current/overall transfer statistics. On the left side, there is planned RSS feed from yet-to-be-determined websites. One small block of the front page will also be dedicated to Hydranode-related news feed (probably the developer's diary, at least initially).
I was also playing around a bit with Qt skinning (styling, as Qt calls it) support, and the results have been very positive. With just a few lines of code, I was able to add support for Plastique, Windows and WindowsXP theme under WindowsXP; the theme changes happen instantly, there's no delays whatsoever.
A user asked in previous blog post comment whether there'll be OSX support in next release, so I did a test on my Mac. Took 10.5 hours to compile Qt, plus another 1.5 hours to compile Hydranode, the latter of which failed due to some build system issues. At that point, I gave up for the time being - those compile times aren't really workable.
On Windows, I was wondering why on earth are we leaking ~100mb/day memory during heavy usage. If you remember, I mentioned a memory leak in VS2005 C++ runtime library, however I believed that we had worked around it. It seems there are still some cases which aren't handled. In any case, recompiling Hydranode with mingw on Windows resulted in ~30mb memory usage after 24 hours runtime and nearly two times lower CPU usage (note: CPU usage is somewhat related to memory usage - higher memory usage directly results in higher CPU usage). If you remember some of my past posts when I switched to VS2005 from Mingw, I documented lowered memory and CPU usage, so VS still produces faster code, but it could really use SP1 (and we can't use VS2003, since there's no free version available - VS2003 Toolkit lacks some important components).
Madcat, ZzZz