Re: User's preferred search tool

[Denis Washington <dwashington gmx net>]

Why not use the xesam spec? We could just have one generic GNOME search
tool that sends xesam queries and presents the search results,
regardless of which search engine gave them us. This would require a
xesam interface for basic file search, but that shouldn't be much of a
problem.

Cheers,
Denis 

On Thu, 2007-11-01 at 20:29 -0700, Dylan McCall 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. 
> 
> 
> 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 <elle uca libero it> wrote:
>         
>         Il giorno mer, 31/10/2007 alle 12.57 -0400, Matthias Clasen ha
>         scritto:
>         > On 10/30/07, Luca Ferretti <elle uca libero it> 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