Hi,
On Fri, Feb 22, 2008 at 10:19 AM, Mark Fink [EMAIL PROTECTED] wrote:
Why do you insist on belittling me? I'm doing more to protect your
software freedoms than anyone else here who are all speaking about how
MONO is fine. NO IT'S NOT!!
Where did you get your law degree? How much
Hi,
On Jan 18, 2008 3:49 AM, Olav Vitters [EMAIL PROTECTED] wrote:
Currently project information is spread thoughout various systems. The
maintainers are available in MAINTAINERS files, developers in AUTHORS,
the description is possibly in either Bugzilla or some README file,
etc. I'd like to
Hi,
On 11/2/07, Denis Washington [EMAIL PROTECTED] wrote:
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
Hi,
A lot of people at GUADEC seemed to be using opt for their
presentations. It's built on top of clutter, but it seems to be a toy
app.
I couldn't find a home page for it, but the code is here:
http://svn.o-hand.com/view/clutter/trunk/toys/opt/
It might be a useful starting point if you
Hi,
On 10/31/07, jamie [EMAIL PROTECTED] wrote:
On Wed, 2007-10-31 at 17:27 +, Emmanuele Bassi wrote:
who knows how's xesam these days? is it still written in python? do
search engines implement the xesam query spec?
I think beagle has preliminary support for it but not sure how much
Hi,
On 7/24/07, Bastien Nocera [EMAIL PROTECTED] wrote:
On Mon, 2007-07-23 at 15:10 -0400, Havoc Pennington wrote:
- sync of browser state (history, bookmarks, cookies, passwords),
like Google Browser Sync but open source and integrated with
everything else (e.g. no need to log
Hi,
On 8/4/07, Jan de Groot [EMAIL PROTECTED] wrote:
yelp-search-parser.c: In function 'check_lang':
yelp-search-parser.c:401: error: 'langs' undeclared (first use in this
function)
yelp-search-parser.c:401: error: (Each undeclared identifier is reported
only once
yelp-search-parser.c:401:
Hi,
On 8/2/07, Jan de Groot [EMAIL PROTECTED] wrote:
- beagle search in yelp no longer builds as of 2.19.1
What is the build failure? What version of Beagle are you building against?
Thanks,
Joe
___
desktop-devel-list mailing list
Hi,
On 7/25/07, Owen Taylor [EMAIL PROTECTED] wrote:
That just doesn't make a lot of sense to me. What the Empathy block
here is doing here is merging together data from various sources; not
just e-d-s, but also Telepathy, Pidgin, or whatever. I see the
online-desktop-server as another of
Hi,
On 5/17/07, Piotr Gaczkowski [EMAIL PROTECTED] wrote:
KDE with Mandriva is working on adaptation of semantic technologies[1]
on desktop. Are there any similar efforts going on in the GNOME world?
Projects like Beagle and Tracker are at the fringes of this, by
indexing and making searchable
Hi,
On Tue, 2007-02-06 at 08:29 -0500, JP Rosevear wrote:
On Tue, 2007-02-06 at 10:14 +, jamie wrote:
On Mon, 2007-02-05 at 21:19 -0600, Federico Mena Quintero wrote:
El mar, 06-02-2007 a las 12:52 +1100, Russell Shaw escribió:
Now that we have hundreds of .desktop files, it is not a
Hi,
On Tue, 2007-02-06 at 16:30 +, jamie wrote:
The only way to do wildcards with a hashtable is a full table scan - if
you have a million unique words/keys in the hashtable then you have to
glob each one to determine if the word matches the wildcard.
The above is ridiculously slow
Hi,
Bastien Nocera wrote:
On Tue, 2007-01-23 at 17:43 -0600, Hans Petter Jansson wrote:
This has bitten Beagle's metadata extraction a *lot* - and it's not just
100% CPU bugs, it's also bugs that'll eat up all your memory, for
instance.
Beagle's metadata extraction is in-process, the
Hi,
Jamie McCracken wrote:
point 2 is scheduled at nice +19 (same with Ionice +7) so it only uses
more cpu if its idle.
That's not quite how the nice level works, at least in Linux. Higher
nice values get a shorter timeslice, so they merely have less time to
get their work in before other
Hi,
On Fri, 2007-01-12 at 12:04 +, Gustavo J. A. M. Carneiro wrote:
2. it requires _a lot_ of CPU power.
Basically point 2 is a killer. No one is going to want to run this
except in servers. Keeping the CPU busy almost 100% of the time is not
nice: consumes more power, gets my
Hi,
On Mon, 2007-01-08 at 20:47 +0100, Steve Frécinaux wrote:
Jamie McCracken wrote:
in any event tracker can be configured to not index at all or only index
metadata and/or contents. It can also be used a stand alone metadata DB
so I think tracker should be flexible enough for most
Hi,
On Wed, 2007-01-10 at 16:26 +, Jamie McCracken wrote:
Joe Shaw wrote:
[snipped my concerns about Tracker]
all these also apply to EDS too yet no one complains?
Some of them apply. EDS isn't a general data store; it has APIs and
backends that are very specific to the types of data
Hi,
On Wed, 2007-01-10 at 18:22 +, Jamie McCracken wrote:
Tagging in fspot does not use leaftag afaik.
It doesn't, no. F-Spot predates Leaftag by several years.
Their metadata system appears to be based around something
called semweb.
SemWeb is an RDF library. Tags are stored
Hi,
On Tue, 2006-12-12 at 12:57 -0500, Jon Nettleton wrote:
On Tue, 2006-12-12 at 17:33 +, Thomas Wood wrote:
I do think using a shell window is easier than a menu, especially when
it has search and filter features. It is also likely to be more familiar
to users coming from other
Hi,
On Thu, 2006-10-26 at 08:42 +0100, Ross Burton wrote:
Instead of whatever database you are currently using to store metadata,
use a triplestore. You are half-way there with the current (pseudocode)
Subject.AddProperty(dc.title, sometitle).
These are currently stored as separate fields in
Hi,
On Tue, 2006-10-24 at 00:09 +0100, Alan Horkan wrote:
What are the chances of a version of Beagle ever using the C Lucene
backend, which as Jos has mentioned is currently faster?
Lucene performance across the board is pretty great. I'm not sure that
switching to the C version would buy us
Hi Ross,
On Wed, 2006-10-25 at 13:49 +0100, Ross Burton wrote:
I do wonder why nobody has taken a fast database-backed RDF triple store
(from librdf), put a sparql-based frontend on it for queries (again from
librdf) and used re-used a lot of code from both Beagle and Tracker for
harvesting
Hi,
Jamie McCracken wrote:
I know that Thunderbird and firefox are moving to sqlite for storage but
Im not sure in thunderbird's case whether emails will be stored in
sqlite or just the config/mork stuff.
Emails themselves are stored in mbox format. The summary format is Mork
(and sqlite
Hi,
Jeff Waugh wrote:
We have a pretty clear email from Joe about that, and what he needs to do to
rectify the situation.
Good news on this front: with the help of some Mono developers here at
the Mono Summit, we've been able to reduce Beagle startup memory usage
by a third, we've
content and metadata.) This will
be a problem when searching emails, for instance, because people
will type Joe Shaw eggplant and expect it to match from the
author field and the body of the message.
* The graphical search tool is a C application that has been
Hi,
On Thu, 2006-10-19 at 13:19 +0100, Jamie McCracken wrote:
I cant comment too much on Beagle cause the last version I tried almost
a year ago was unusable on my 256mb machine.
+ whole load of stuff that tracker can do that beagle cant (while it
remains a dedicated indexer that is)
I
searching emails, for instance, because people
will type Joe Shaw eggplant and expect it to match from the
author field and the body of the message.
of course you can - have you tried it?
Ok, I apologize then. I have not tried writing to the APIs, I got the
opposite impression
Hi,
On Thu, 2006-10-19 at 23:31 +0100, Don Scorgie wrote:
(Not getting into the *cough* discussion *cough*, just wanted to add 1
comment)
:)
On Thu, 2006-10-19 at 18:11 -0400, Joe Shaw wrote:
(As an aside, I thought there was consensus that all new modules had to
be fully documented
Hi,
Jamie McCracken wrote:
Joe Shaw wrote:
What I meant is that Tracker has to read and process all that
information. One thing I've learned from Beagle is that there is a lot
of broken data out there, or that our code to process that data was
broken. (This has particularly been a problem
Hey,
We had a hackfest at the GNOME Summit in Boston this past weekend.
Here's a quick rundown of the things people decided to work on:
* Me - Working on updating the indexer to better handle support
of user-provided metadata. Originally my plan was to store
metadata in
Hi,
Étienne Bersac wrote:
I submit a request for a SVN Repo and a gnome.org account few weeks ago.
Still nothing about both. I would like to avoid using CVS for a
migration in some weeks later ... (and because i'm fed up with CVS)
But, of course, using Gnome hosting is something i'll be
Hi,
On Thu, 2006-09-07 at 12:59 -0400, Hubert Figuiere wrote:
There have been a large pimping of project Topaz, and I strongly believe that
this is the kind of goal that would need a longer development cycle for a big
leap forward towards world domination.
The counterargument here is always
Hi Vincent,
Vincent Untz wrote:
The API in the bindings suite covers the platform API. This has to be
clear to ISD/ISV and we don't want to compromise this message. Please
don't consider Gtk# only, but the platform (with the bindings) as a
whole.
It's not about additional guarantees. It
Hi,
Matthias Clasen wrote:
On 7/22/06, Joe Shaw [EMAIL PROTECTED] wrote:
If Mike were starting from scratch here, this would be great. But there
are already users of these bindings and breaking them up would
effectively break ABI for existing users. Gtk# already has its own
stability
Hi,
On Fri, 2006-07-14 at 16:09 +0100, Alvaro Lopez Ortega wrote:
What I meant is that if you launch a KDE desktop, it'll use a single
framework and execution environment. Even if they have binding, all
the main desktop application have been written using a single
development
Hi,
On Fri, 2006-07-14 at 09:10 +0100, Jamie McCracken wrote:
I don't use Beagle, and in fact I hope the alternate Tracker project
will solve this problem.
It already does - tracker uses a tiny 3-6 MB RAM and provides
considerably faster indexing and search retrieval of results. I
Hi,
On Thu, 2006-07-13 at 22:16 -0400, Ben Maurer wrote:
On Fri, 14 Jul 2006, [ISO-8859-1] Steve Frcinaux wrote:
Not really. In fact, blessing an app in the desktop has the immediate
consequency that other apps can depend on it in a non-conditional way.
For instance, a few distros already
Hi,
On Thu, 2006-07-13 at 10:28 +0100, Alvaro Lopez Ortega wrote:
It is a very different situation. While the power manager support
provides new functionality, GTK# would only provide duplicate
functionality for another development framework that overlaps with
GNOME.
Perhaps I am
Hi,
On Sun, 2006-06-25 at 13:17 +0100, Glenn J. Mason wrote:
Yeah, what happened to Dashboard? The last update on the weblog is
the end of 2003. I love the idea of persistent real time information
display, like Beagle search but fed a stream of cluepackets.
I actually just gave a talk
Hi,
On Thu, 2006-04-20 at 22:43 +0100, Jamie McCracken wrote:
well there's a huge problem with that - the memory usage of beagle would
mean only high end machines would be able to run it. Tracker gives us a
better alternative IMHO for integrated search as it rocks for *everyone*
and not
Hi,
On Fri, 2006-04-21 at 09:21 +0200, Luca Ferretti wrote:
Oh, it's a freedesktop project.
This isn't a dig on tracker, but I don't really agree with the
implication of this statement. Putting something up on freedesktop.org
doesn't automatically bless it in some utopian cross desktop way.
Hi,
On Mon, 2006-04-10 at 14:31 +0100, Iain * wrote:
You missed my second point. If the icon is the application, then we
should provide an easy way for the application to use an applet
instead of the notification area.
Except they want it so that they work in KDE as well. That was the
Hi,
On Wed, 2006-02-08 at 12:09 -0500, Rodney Dawes wrote:
It's not an extension to the panel menu code. It's not even a patch.
It's a completely separate applet. This is in fact, in no way different
than a theme engine in terms of integrating it upstream, into a larger
conglomerate package.
Hi,
Straying from the topic a little bit...
On Sat, 2005-10-29 at 14:19 +0200, Raphael Slinckx wrote:
It's also worth mentionning that in theory, deskbar could work with
beagle only, but in practice, beagle isn't installed by default
everywhere, beagle is not production ready, and filtering
Hi,
I am going to steer this thread in my own direction. :)
On Tue, 2005-08-09 at 01:53 -0700, Jeff Waugh wrote:
Maybe a View Audio Files or View Video Files option in the right click
context menu?
Default context menu item == Play (or whatever action makes sense), with
the Open item
Hi,
On Thu, 2005-06-16 at 20:09 +0200, Piotr Gaczkowski wrote:
Recently I came into the Topaz roadmap and a kind of presentation at
SourceForge. One of features that interests me is this tagging Beagle
stuff.
It reminds me of the Semantic Web vision and it's derivative Semantic
46 matches
Mail list logo
