A couple of applications from your future desktop [LWN.net]

By many (but not all) accounts, the Linux desktop has achieved something close to parity with some of the proprietary alternatives, in terms of both capability and usability. The desktop developers are certainly not ready to declare victory and sit back, however; the pace of development is, if anything, still increasing. As an example of where things are going, we decided to take a quick look at a couple of bleeding-edge applications which have been attracting attention recently.

The first of these is tomboy, a simple desktop note-taking tool. Tomboy implements a set of note cards, each of which contains text and links to other cards. The idea is not particularly new, but the implementation has been thought out well. Some of the best ideas from Wiki-style web sites have been absorbed - typing a WikiWord into a note creates and links to a new note using that word as its title. Links can also be created through a "link" button or by dragging and dropping. A simple search capability can quickly find notes containing a given string.

Nat Friedman was impressed by this application:

Note taking is something I do all the time, and which previously was the realm of "emacs ~/randomname.txt" for me.... We all had our horrible little solutions to this problem, and Tomboy has stepped in to fill the gap in a big way.

I'm not sure it's clear to everyone just how big a space Tomboy has carved out. If Tomboy can own note taking for me, that's one of the main purposes of my computer.

Your editor was, with some effort, able to get tomboy running on a Debian unstable system; this application requires a number of highly-current Mono and GTK libraries. There are some rough edges and missing capabilities, which should come as little surprise for an application this new. Even so, tomboy makes note taking and organization into a quick and easy task; it is good at staying out of the way. If the current trend continues, tomboy should quickly reach a level of functionality and stability that will earn it a place on most distribution disks.

Meanwhile, quite a bit of attention has recently been focused on beagle, which is currently at a lofty 0.0.2 release. Beagle appears to be the GNOME project's answer to Microsoft's search plans and Google's (Windows) offering; it provides a quick way to find things on the desktop. Think of it as a modern version of locate, but with a few enhancements.

One core beagle feature is its collection of "filters," which enable searches of a wide variety of files typically found on a Linux desktop system - and some that aren't. Supported file types include Microsoft Office, OpenOffice.org, PDF, source code in a number of programming languages, and a number of image and audio file formats (only metadata is indexed). Beagle can also search email (mostly limited to evolution users for now), tomboy notes, weblog entries in the "Blam!" format, application launchers, and more.

Underneath it all, beagle uses the (still unmerged) inotify mechanism to learn about changes to the filesystem. New or modified files can be indexed immediately; there should be no need for a massive "thrash the disk" job running in the middle of the night. As an added touch, search results which are currently displayed for the user are updated to reflect the latest filesystem changes.

There is a command-line search tool which may be used to search beagle, but the primary interface to the system is best ("bleeding-edge search tool"). The project has put together a collection of best screenshots which gives a good idea of what beagle can currently do.

While tomboy is primarily the work of one developer (Alex Graveley), beagle is a rather larger affair. The beagle roadmap posted on October 4 shows that quite a few Novell hackers have been set to work on beagle. At the top of their list is basic usability work, things like "Not crashing or failing, most of the time." Among other things, it seems there are memory leak problems in Mono which have to be worked around. Email integration remains on the list ("The primary goal will be Evolution mail integration; patches for other mail clients will, of course, be accepted."). Work continues on the search interface; among other things, search will be integrated into the GNOME file selection dialog.

Longer-term goals include reworking dashboard to sit on top of beagle, adding beagle searches to nautilus, and, somehow, better encapsulating the relationships between desktop objects.

Beagle is very much an early-stage project; it can be difficult to install, and it is not available in packaged form for most distributions. There is also that "not crashing for failing" issue. But it has reached a point where the suicidally early adopters are finding it useful, and progress is happening quickly. Linux, it seems, will not be left behind when it comes to desktop search capabilities.

(Log in to post comments)

Stop the insanity and drop Mono now

Posted Oct 21, 2004 5:13 UTC (Thu) by LinuxLobbyist (guest, #6541) [Link]

Yes, that is what I'm wondering as well.

Let the assimilation begin.

I've read the arguments, and I don't buy them. Miguel and the other Mono proponents are completely ignoring history. If M$ can figure a way to crush FOSS, it will. This just gives them a toehold to do just that.

While M$ might not succeed in crushing FOSS with the Mono toehold, the potential for the need to rewrite large portions of GNOME if Mono takes hold among developers of core GNOME apps could be devastating. Mark my words, it WILL happen.

Stop the insanity and drop Mono now

Posted Oct 21, 2004 8:10 UTC (Thu) by walles (subscriber, #954) [Link]

The CLR (and thus Mono) is designed to be able to run programs compiled from many different languages, C included.

Thus, in the long run there's nothing preventing Gnome from both running inside of Mono and being written in C to a large extent.

See http://www.go-mono.com/languages.html#c for example.

Stop the insanity and drop Mono now

Posted Oct 21, 2004 23:13 UTC (Thu) by massimiliano (subscriber, #3048) [Link]

Miguel and the other Mono proponents are completely ignoring history.

No, we're not.

The only weapon Microsoft could have against Mono is software patents.

If you look carefully, those nice applications do not use "the Microsoft stack" of .NET libraries. They are based on the ECMA standards, and on wrappers on the Posix and Gnome libraries. The ECMA standards do not have patent issues from Microsoft, and the other libraries... well, every Gnome application would be using those libraries anyway! Look into that, Mono provides (and uses) wrappers for GTK, Mozilla, Posix... if there were patent issues, they would not be in the wrappers, but in the libraries themselves, so I state it again, every application using them would be at risk. Using Mono makes no difference.

Add to this Novell's patent policy (which is intended to minimize the risk that somebody actually starts a patent war against open source projects, including Mono)...

So no, the issue is not been overlooked. And chances are that any other technology that does similar things would be covered by the same patents, including Java (seen the Kodak disaster?), and why not, the new perl interpreter, parrot. At the very least the Mono core is covered by the ECMA standard!

Stop the insanity and drop Mono now

Posted Oct 22, 2004 1:43 UTC (Fri) by bronson (subscriber, #4806) [Link]

OK, I'm willing to mark your words. If Microsoft hasn't managed to crush Mono in 5 years, then will you admit you were wrong? And, if they do, I'll admit I was wrong. Personally, I don't think they'll even try; talk about a low percentage effort. Note that quibbling over the .NET emulation libraries is very possible, but that doesn't matter because Gnome software doesn't use them.

Without a time limit, your prediction has about as much meaning as "the end of the world is coming!" i.e., not much.

Stop the insanity and drop Mono now

Posted Oct 22, 2004 4:00 UTC (Fri) by LinuxLobbyist (guest, #6541) [Link]

Five years is reasonable. And, yes, of course I'll admit I'm wrong if it doesn't happen. But with a caveat: only if the policies of the USPTO do not change for the better (i.e.: disallow or severely limit the award of software patents). If the policies change for the better, my assertion becomes moot.

I think many people forget how easy it is for an extremely wealthy company with a near inexhaustible supply of money can game the patent system as well as standards bodies. And it's only getting worse. Witness what happened with the IETF MARID Working Group for but one example. I was (am, actually, but the traffic is near nil, now) subscribed to that list as well as spf-discuss before that and warned of getting too close to Microsoft very early on. And look what happened.

I don't know much about ECMA, but having parts of .NET in the hands of a standards body doesn't give me much comfort, given what I've seen from some standards bodies.

And Microsoft doesn't have to be *right* if they make any kind of claim against Mono in order to hold it in limbo in court for years and drain the financial resources of those who back it and/or distribute it. I personally know people who Microsoft did just that to.

Novell's new patent policy is extremely commendable. It'll likely have an effect against SCO-like (but with patents added) suits of the future. But against the Microsofts of the world, we'll have to see.

Mono

Posted Oct 21, 2004 6:10 UTC (Thu) by ncm (subscriber, #165) [Link]

Maybe Mono is handy for prototyping, but these things should be re-implemented in a real language before trying to deploy them. There's nothing like depending on an unstable, immature execution environment to brand a program as buggy, slow, piggy, etc. (Witness Freenet!) Rewriting in modern C++ on libgnomemm ought to be easy, instructive, and maybe even fun.

Mono

Posted Oct 21, 2004 8:03 UTC (Thu) by walles (subscriber, #954) [Link]

On the other hand, the only way to turn Mono into a stable, mature runtime environment is for people to develop apps on top of it, find problems with it and have them fixed.

Even gcc wasn't very good to begin with.

Mono

Posted Oct 21, 2004 8:21 UTC (Thu) by ca9mbu (guest, #11098) [Link]

> On the other hand, the only way to turn Mono into a stable, mature runtime
> environment is for people to develop apps on top of it, find problems with
> it and have them fixed.

Which is why this quote from the original article:

> Among other things, it seems there are memory leak problems in Mono which
> have to be worked around

strikes me as very odd. Why work around the problem at all? If the guys developing beagle have found a memory leak, why can't they report it and have it fixed upstream so it can be fixed and they don't need to work around it at all?

Mono

Posted Oct 21, 2004 22:51 UTC (Thu) by massimiliano (subscriber, #3048) [Link]

In fact the memory leaks are being fixed...

Mono

Posted Oct 21, 2004 17:16 UTC (Thu) by ncm (subscriber, #165) [Link]

Why bother making the Mono runtime stable and mature at all? Maturity isn't really needed for prototyping, and just interferes with the process of transitioning those prototypes to a real language.

Mono

Posted Oct 22, 2004 7:02 UTC (Fri) by walles (subscriber, #954) [Link]

That's a circular argument.

You're saying that since Mono isn't mature, it isn't good for anything but prototyping. And since it's only good for prototyping, why should it be made mature?

The answer is of course that *if* Mono should become stable and mature it would be good for other things than prototyping. And since it would then be good for other things than prototyping it would need to be stable and mature :-).

As is explained on "http://www.go-mono.com/languages.html", your definition of a "real" language would have to be quite uncommon to be able to find a language that couldn't potentially be run by Mono.

mono is quite mature

Posted Oct 22, 2004 12:02 UTC (Fri) by louie (subscriber, #3285) [Link]

I have my own issues with mono, but if you're criticizing the maturity or stability of mono, you obviously haven't actually used it. I have run tomboy 24x7 for a couple weeks now, and muine 24x7 for several months now, on a music box which is never rebooted and on which muine is never turned off. Neither have had memory or stability problems. There may be plenty of criticisms you can make of mono, but that's just not one of them.