On 02/11/2007, Dylan McCall <[EMAIL PROTECTED]> wrote: > > These search engines all provide similar outputs, do they not? What we > need, then, is a standard system that they can each fill in for via D-Bus, > or by replacing some small GNU-esque applications, with the assumption that > the distro's dependency management can deal with overlapping systems. > Hard-coding anything like this is the wrong way to go, because the solution > ends on whatever it was hard-coded for. You will always bump into a person > like me who hates maintaining code, who refuses to implement a system in his > applications when it arbitrarily runs searches as if by hand. That system > will not be long lasting, and will be continually in flux, so the various > applications integrated in the GNOME desktop just won't want to use it. What > happens then? The same thing that happens with a lot of other systems: > Nothing. No lasting good comes of it, because whatever has been hard-coded > to will grow out of the rigid cage that has been set, and a lot of effort is > wasted. Maybe a few programs will duplicate the code, (the viral GNOME foot > logo spinner comes to mind), but that's not really an attractive thing. > Let's make desktop search worth something! This should be consistently > present as a tool that the user can expect to use, rather than one he is > occasionally given the privilege of encountering. > > If a search engine wants to integrate with GNOME's services, it should > provide particular inputs and outputs. I can't see a selection in Preferred > Applications causing any notable changes in the user interface, so that > shouldn't be too difficult to expect with this solution either. The current > option of choosing search filters could be done such that options for > filters are defined, again in a standard way, by search engines themselves. > Leave the rest to the standard interface, whether the existing systems > follow the rules yet or not. (Those filters would need something to ensure > that applications calling the preferred search engine can safely specify > wanted file types or source folders. Individual applications can get away > much more than GNOME with hard-coded behaviours, such as tag searching if > that is available). > > Need an intermediate solution? Fine, implement search tools for Beagle and > Tracker while we wait for them to create GNOME integration packages. By the > way, this is no more to ask than that they have a GTK-powered front-end. > Don't feel bad about having to lock these to a set output and input; they > can still grow on the inside, and the possibilities unlocked far outweigh > the potential benefits of more fancy search options that only are accessible > from a single place. Besides that, we wouldn't be restricting their growth; > the accepted standards can grow, too. A building usually has a single front > entrance, but that doesn't mean the side doors don't exist for those who > want them. Also, just because we're using the same set of doors doesn't mean > we never see improvements in functionality beyond the standard. One building > may have a shiny metal chute for its front door, so getting in and out is > much quicker than the usual staircase! > > Having a centralized, extensible search engine selection that works is > definitely Very important for GNOME's future, and needs to be done right. > This would offer a huge step forward. I have been chanting a lot today, in > various channels, about how it seems the most intuitive interfaces try hard > to abstract file management. It appears that people like photo management > tools, desktop search and web-based document editors. > Why? Why not just use the local file manager and its nice thumbnails? > I think it is because these tools do not require the constant fussing with > file hierarchies we see with a lot of software. This doesn't happen when > there is a single integrated suite for everything (ie: iLife), but we can't > do that here. The more intuitive behaviour is where the program can deal > with file management, (which always ends up quite a hopeless mess thanks to > how files are displayed in any common file manager), and keep that away from > the user's attention. For example, a centralized backup solution is an > excellent thing for the long term, because it means that applications (which > know their own file management techniques quite well) can help the user with > their backups. Instead of one having to pick through backups to recover his > F-Spot library, he could tell F-Spot to find and restore its own darn files, > and it could seek them out and find them (asking for the user's input along > the way, for example which backup to use) all using a common software > interface it can expect to exist for backups. Many stop there, however, and > leave seeking up to the user if he wants to use another program, because > these things just don't know (or seem to care) that each-other exists unless > it is one of those annoying package conflicts. We need other tools for > programs to inter-operate, like smart drag & drop (dragging an image from > F-Spot to send it as an attachment in Evolution. Smooth!), MIME types as > well as a consistent user interface toolkit. These don't quite cut it, > though, since it still often involves more work than the user feels like > doing. I find that drag and drop and finding files via the file manager work > in different directions, and one always tends to be more suited to a > particular task. File management is a bit jealous of drag and drop, though, > since the latter feels far more clever, and does way more work for the user! > > That is where desktop search comes in. > > With desktop search, done (the way I think is) right, the positives are > two-fold: Desktop search helps people to have data consistently available to > multiple programs under a single interface (without having to hunt for the > files manually), but that power only comes through if it is attached to each > program. Otherwise, as with the current situation, this is still just an > extension of the file manager's functionality. Having it in the file > chooser widget via Search is a great start, but it's still not enough. > (Search folders in the Places list are another good step, as we see in MacOS > out of the box, and in GNOME with a bit of setup). I think the real leap > forward comes when apps can safely use desktop search for everything, from > seeking through their own databases (thus having a single way of doing > search queries across the desktop, instead of each program having its own > little search engine. Wouldn't it be great if Beagle's Boolean searching > happened everywhere, rather than just in Beagle's main front-end? I always > expect that, but I know it isn't happening yet). That coolness could go all > the way back to a photo manager doing something awesome: Quickly locating > new image files larger than 1024x768 pixels, perhaps with digital camera > meta data, and offering to import them. > > That leap is only possible when we have a single desktop search system, > endlessly extensible by interchangeable search engines. We all want it, and > the search engine people would all love having that kind of use available > for their tools. The applications like photo managers, even more so. It may > take a while for everything to be implemented, but I think we are all in the > same boat here. It is in everyone's best interest to standardize this. All > we need now is a standard.
Ok, short answer to long mail - I'm at work so I shouldn't be reading d-d-l :-) XESAM is *exactly* what you talk about. See http://xesam.org. If you are interested I suggest you read the RC1 spec an give your comments on the xdg list at freedesktop.org. I given a small XESAM status report somewhere in this thread. Should be easy to find. Cheers, Mikkel
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
