Sinzui

Murray, I think you are partially right about Anjuta promoting Glade code. Without a comprehensive primer about the GNOME development process that provides best practices and a checklist, we will continue to see such mistakes. I lurked on the gnome lists for years, and learned a lot about good and bad practices. When It came time for me to contribute code, I was very frustrated trying to locate good information. In the case of glade, there are dozens of tutorials available, most for Python, and most use glade-generate code. I knew this was wrong, but there is not a good document about what is right. In the case of my recently created msearch-gui, I wanted to reuse code from gnome-search-tool, but I found glade-generated code. I was savvy enough to realize that just because I found glade-generated code in the base GNOME packages, that does not mean I should use it.

There are lots of articles and tutorials about GNOME development, many are wrong, and many are on the developer.gnome.org site. We are reorganizing developer.gnome.org, and we will take the opportunity to remove old documents or label them obsolete. The Web site needs to do a better job at integrating the information into a cohesive set of documents that clearly define how to develop without developers needing to hunt for the answers to their questions.

I would like to create an outline of the GNOME development process, and commit it as a project. It would be good to capture the experience of the seasoned developers, and update project as the development process evolves. Providing a checklist will really help developers avoid making revisions to get their code in shape for a public release. Tools like Anjuta and Scaffold should reinforce the GNOME development process by providing features that reinforce the process, and make it difficult to deviate from the best path.

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.

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.

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.

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.