Category Archives: meta

Medusa has secret mime-type search

While fixing the mime-type validation in the query optimization code, I realized that search URLs with mime-type clauses would pass through to the query engine. A quick test of msearch proves it. It looks like someone's good efforts to optimize the clauses before performing the query inadvertently added a useful feature. The cause takes the form of 'mime-type type/subtype'

eg. msearch -u 'search:[file:///]file_name contains resume & mime_type is application/pdf'

returns all the PDF files that have resume in their name.

I will add this to msearch-gui. I may need to create an option menu listing all the registered mime-types on the system, but that will be one unruly list. I planned to introduce this feature after I replaced the backend. I don't use the file open dialog, preferring to use Nautilus, but I see an application's need for a smart open-file-dialog. The file-open-dialog could use search to display all the possible files it can open. The user could restrict the list by adding additional criteria like name, emblem (keyword), or location.

Medusa search improvements

Having flu inspired me to work feverishly on Medusa. I've completely restructured msearch-gui. It's much more stable, and I squashed some bugs in the process. I cut some features I felt were frivolous. I don't think apps should be making private solutions for public problems: gnome-vfs needs a gnome_vfs_uri_is_valid, GDate should handle time. I'll need to spend some time on other libs and Storage soon to advance Medusa.

A word to the wise. Just because Medusa supports 'emblems do not include …' doesn't mean you should use it. I accidentally searched for anything that wasn't and application. The result set of more 200,000 files was returned in seconds, but displaying that many files in a window crippled my machine to 30 minutes before I could kill it. I think I'll add a sanity to msearch-gui to clamp the results to no more than a few hundred files.

Medusa objects and architecture

msearch-gui quickly became a jumble of functions when I decided to make it available to users. 50% of the code was controlling the results tree/treeview. I neatly encapsulated that in an gobject named MedusaTreemvc. After I've created some more widgets, I'll move the MedusaTreemvc to a new components part of the tree. There's more code clean up to be done before I can start expanding the features again. I need to change the search URL format before the year is out so I can start on a new metadata backend in 2004.

Medusa file_type fixed

I found a major gaffe in the file_type clause. The fix was simple (after making glade2 again because xd-unstable put GTK only glade in its place). Searching for music file_type is very fast, and it clearly shows the clumsiness of GNOME's mime-type handling–lots of text files in the results. I added a popup menu to select open file or open parent from the results list. Opening Nautilus views is dodgy on my system, but I let it pass because I see the same problem in other apps.

My last set of changes made the indexer very stable, I don't see any tmp files left next to the db indicating the indexer failed. I'm going to take the time to handle the .progress files when the indexer fails and close that bug. Two other changes I want to make soon are rename the vfs-module and fix the URI format. That will put me in a good position to start replacing Medusa's backend.

Hacking at Medusa nuisances

Some old errors showed on my system as I put Medusa through some duration testing this past week. Those naughty progress files were being left behind when the indexer failed. Cleaning those up automatically will require some subtle changes to the masterDB since C cannot catch an exception, and there is no graceful exit strategy. I'll create a small clean up function I suppose. This DB implementation has reached it limit, time to start working on Storage.

I located and fixed the error in the plain-text indexer that has irked me for more than an year. The fix will prevent Medusa's MasterDB from stepping into the error that left the progress files behind. I really want to toss the indexer–it will never be capable of handling Unicode. I'll do that at the start of next year. The next indexer will make an effort to keep the DB size to much less than the 95 megs I have for my 20 gigs of personal data.

Contemplating simple search that simply works

While looking into some type punning errors with gcc 3.3, I found an opportunity to do a union between content, file name and keyword searching. I can create a pseudo clause that will perform three searches and merge the results. I see that I can do a clumsy weight by moving matching files from all three returns to the top of the list. Instead of having a simple search that just does a 'file name contains' clause, I could use the pseudo clause to return a better set of results.

Even though I could do this, I'm not sure that I should. The query is crude allowing too many false matches, and there isn't really enough information in Medusa at this time to order the results well. This sort of query really requires a modern DB backend, and a rich schema. Still, this idea might do in a pinch, and provide a better set of results that 'file name contains' query.

Fast Medusa, faster. Kill, kill, kill

I found and fixed the bottleneck that caused the search results to take forever to display. I guess the icon creation code is fast enough for the slow find routine used by gnome-search-tool. It is painfully slow, taking 30 seconds to display a 1,000 file match, even though the list took 2 seconds to lookup.

I see Nat listed Medusa among the promising new features for GNOME. Wow. I wish I could work on metadata full time. I don’t own the Medusa project, I’m not even the maintainer. Anyone who would like to contribute is welcome. Nat also mentioned Storage and Dashboard with the hot ideas, and I’m also interested in them. Some collaboration between all projects would really transform GNOME from a smart desktop to outright brilliant.

Medusa HEAD is unstable yet very usable.

I branched the stable medusa-6-0 to do some unstable GUI and indexer development in HEAD. I committed a rudimentary GUI app for file queries. The menus and toolbar are dummies (and the ‘Fewer location options’ is broken again). Many of the results pane functions came from gnome-search-tool to provide some basic file interaction.

It is probably too late to add Medusa 6.x support to Nautilus 2.5, but it may be doable if we reconsider the requirements. The problem is fitting complex search into a toolbar, replacing the entire search toolbar code, and disabling navigation to avoid confusing the user. Updating the search view wont be a difficult task; copy and modify the existing list view or try the new pluggin architecture. Simple search and complex search may be turned into dialogs that create a search URI that open a spatial window. While this plan addresses the toolbar and navigation issues, it will introduce another one. If a save search (folder) is opened from the desktop, there is no way to see or edit the search criteria. The msearch-gui app could be used to edit the criteria of a search folder.

Seeing is believing in Medusa

After three days of mad coding (and a deft liberation of functions from gsearch-tool), I have a working GUI interface for Medusa. It feels good. I have some more callbacks to hookup and a src tree to clean before I commit. I’ll add the desktop search folders and info dialogs latter. Still this much more than the command line msearch has to offer.

The msearch-gui app’s result display is slow. The result set or URIs it returned with 2 seconds for more searched, but the GUI is spending a lot of time looking up the posix file information and formating it. The formating code might be made faster, but since most of it came from gsearch-tool, I doubt I’ll find the bottle neck. The silly thing is, most of the information displayed was known by Medusa, everything but the icon could have been return for display.