Sinzui

I read a good article (Why a New Filesystem Matters) about the importance of file metadata, and cool tricks like querying file content. In the example in the article, it is assumed you know what file your interested in. One crucial point of the article is that there is a cost for storing metadata, both loss of speed and disk space. Medusa might be a smarter option than I originally supposed for handling file metadata, because, while it's database takes up disk space, it is fast, and it's content indexers will be optional. Medusa will handle the disk space better because it uses a separate filesystem, it's database, which is optimized for small chunks of data. ReiserFS is great at handling files, but it doesn't know a lot about the relations between the files, nor does it help the user know about them. Medusa will know a lot about them, so it makes more sense to ask a Medusa for this information that using a filesystem plug in to query a file's metadata.

I've been trying to install Medusa on Solaris 8 Sun/GNOME 2 on an idle computer at work. It doesn't compile for all the stupid reasons. Sun ships with ancient libs, old developer tools, it's developer installation is missing pieces, etc…. Then there is the Medusa code itself. It dies for simple portability reasons, the basic UNIX libs aren't the same as Linux. Medusa's code often uses it's own methods to solve problems that specialized libs do fabulously well. Simple tests fail because native (not portable native) code is used to getpid(), and logging doesn't work calling setenv(). Using glib, and specialized libs for logging, testing, DB storage, system idle usage would let me focus on developing and perfecting Medusa's core features instead of making mediocre alternatives to libs that are already on the computer.

Medusa has a long way to go, and I'll need just as much time to factor out Medusa's private support code as well as develop it's core functions. As frustrating as this is, refactoring bad local code for proven, reusable code from other libs will get me more functionality now than simply start over.

I spent the weekend convincing my former boss that he can deliever a great e-commerce site built on open source software. He's used to million dollar budgets, he buys expensive hardware, server software, and over-priced frameworks. He then pays me to make things work, often at short notice, and integrate with something else. I always nicked stuff from an open source project because I could trust the code, and understood the standards it supported. I set his laptop up with linux a few months ago so he could get the feel of being what open source can do.

Time-Life laid my boss off, and his currect job prospect wants a first class site on a budget. I think it would be fun to do the site using only open source, so I'm helping him come up with a real plan as I would build a site. I hope he'll hire me and a few of the other ex-Time-Life e-commerce team to build it. Once, built there wouldn't be much for me to do, so I'll need another job in 12 months.

I made some minor text changes to the language bindings and cut the ratings. GNOME's libs are too complicated to be reduced to a simple rating for compliancy.

I created some new CSS rules that accomidate the h3 elements better. The way to get Moz-based and IE-based browsers to display alike is to explicitly set the margin-top and margin-bottom of block-level elements. I then set the headings to have variaions in there margins to pull them closer to the content that follows.

Checkout the reunion_medusa branch of nautilus from gnome cvs to see a some functionality already restored. Be warned though, Nautilus will go belly up if you try to close the search-list-view. There are serious issues with the complex search toolbar that must be addressed before this stage can be completed.

The most obvious problem is that the optionboxes don't display the active menuitems. I lost a lot of momentum trying to fix that before a, sinking to despair, and b, realizing fixing the issue wont make complex search usable. Complex search used a hacked version of the GTK+ 1.x hwrapbox from GIMP. GIMP updated it to GTK2 a few months ago, but a lot of refactoring is need to make it work in Nautilus/Medusa. Even is it were pursued, figure 1, illustrated that this does not work in a tool bar. Switching to a hbox as is in the current code and illustrated in figure 2 doesn't work in small windows.

Complex search is better suited in the side bar or in a modless dialog window. Consider gnome-search-tool in figure 3 as an example of how a dialog might behave. I like it's gui and as users are more accustomed to it then the original Medusa complex search, I think it's UI should be emulated when possible. I don't care for creating additional windows because it seperates the query from the results. The side bar would be an excellent choice if the width of the search criteria could be prevented from getting too wide (See figure 4).

figure 1: Nautilus complex search tool bar using hwrapbox.

figure 2: Nautilus complex search tool bar using hbox.

figure 3: gnome-search-tool.

figure 4: Nautilus complex search bar proposal.