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. Bye, -Dylan McCall PS: Speaking of abstraction, sorry if my small amount of text formatting comes out weird on your end. On 11/1/07, Luca Ferretti <[EMAIL PROTECTED]> wrote: > > > Il giorno mer, 31/10/2007 alle 12.57 -0400, Matthias Clasen ha scritto: > > On 10/30/07, Luca Ferretti <[EMAIL PROTECTED]> wrote: > > > > > > > Stuffing more and more things into the preferred applications capplet is > really > > not the way forward. I'll end up like gnome-volume-manager if we > > continue this... > > > > Really, we need a single search tool that can talk to various engines. > > Matthias, this is not the issue I was trying to settle. > > Of course the GNOME Desktop needs a new default search tool, that > ideally should talk with the user's preferred engine or the one > available on system (and I hope it will be the best available tool to > search in my data), but I don't think we should lock out any other > alternative. > > What if I like Google Search? It's an available solution for Linux/GNOME > desktops, but I don't think we'll never include it as backend for this > future tool. > What if I will dislike that tool and I'll want to use another? Maybe the > new tool will obsolete all others? > OK, I will always able launch my preferred tool from its menu entry > under Application menu, but I'll not able to quickly hit the "Search" > button on my keyboard or choose Places->Search. It's just like the > gnome-main-menu applet that shows the search entry only if you have > beagle (at least the last time I tried)... > > And about the growing size of Preferred Application capplet, yes, it's > true, but could be physiological if we like to provide a reasonable > degree of choices to users (by now only 6 applications). It's the only > available place to setup default applications that don't open files. > Maybe we should change the UI using a list on the left, as suggested by > HIG if you have a lot of stuff[1], to choose the section (web browser, > email client...). This could allow to merge this capplet with > gnome-volume-manager[2]>, something like > http://www.rubicode.com/Software/RCDefaultApp/ but of course with less > steroids. > > But this could mean that currently the capplet UI is not well scalable, > not that this is a reason to give up an useful (IMHO) feature. > > So, IMHO, "the capplet is a mess" and "we'll have a better tool" (BTW > when?) aren't good reasons to dump this feature. The GNOME Desktop is a > product that distributors, vendors, admins and users should be able to > configure (with a reasonable amount of prefs, of course) and hardcoding > a program (both gnome-panel and gnome-setting-deamon directly launch > gnome-search-tool) isn't a great example for a product adaptable to > customers' requirements ;-) > > > [1] see figure 6-25 at > http://library.gnome.org/devel/hig-book/stable/controls-notebooks.html > > [2] just a note: gnome-volume-manager stores stuff unrelated with > removable stuff. See printers, scanners, and input devices. Really, > what's the reason to run a command when you plug an USB mouse? And, if > any, shouldn't this preference placed in Mouse tool? > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list >
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
