Re: Reuse new gtkfilechooser Search feature in Nautilus

hi Luca;

On Tue, 2007-05-15 at 17:51 +0200, Luca Ferretti wrote:
> In the last weeks a feature have landed in GTK+ trunk: the availability
> of a "search" section in filechooser. See this[1] and this[2] posts from
> Emanuele Bassi - and of course gtk+ sources :-)
> IMHO Nautilus 2.20 should import the search engine code from gtk: both
> nautilus and gtk support beagle and tracker search engine, but gtk+
> don't depend on them at compile time. Using Emanuele's words: 

the reason why gtk+ has chosen this approach is that gtk+ cannot depend
on libbeagle or libtracker, especially since neither is part of the
platform and also because both depend on d-bus, while gtk+ does not.

so, while it makes perfect sense for gtk+ to go down this road, it makes
less sense for nautilus to do the same - as it already depends on
gnome-vfs which does depend on d-bus.

the code in gtk+ is not really nice, as it dlopen()s the shared
libraries and it's based on the assumption that both libbeagle and
libtracker won't change their symbols any time soon.

as a side note, I'd rather wait and see what kind of API the Xesam
project results into, and then optionally depend on it inside gtk+,
while keeping the dlopen() code as a fallback, until every distro adds
support for Xesam.


what interests me more about the last few changes in the GtkFileChooser
widget, and their reflection into nautilus UI, is adding support for a
'Recently Used' place into nautilus, implemented as a special location
(like the search and trash folders); I'm currently working on a patch, I
think I'll have something working by the end of this week.


Emmanuele Bassi,  E: ebassi gmail com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]