Re: State of the Pooch
Hi Joe, Thanks a lot. I am delighted to be awarded the new responsibility. It has been a pleasure to work on beagle this far and I am sure it will be even better in the future. Work continues in trying to make a great 0.3.0 release, and in the meantime we're pushing out 0.2.x maintenance releases. I'd love it if people could be regularly running from SVN trunk so that we can stress test a lot of the features that I'll mention below and get a 0.3.0 release out there that the less adventurous users out there can enjoy. For others, there is no more new feature planned for 0.3.0. Lukas is giving some finishing touches to beagle-search and Nirbheek is working on making the webinterface a bit smoother experience (*). But there is no likelyhood of any changes to the core nor any completely new feature. Sort of like feature freeze but not quite. - dBera (*) e.g. I just came to know that even though my Firefox 1.5 allows me open local links, Firefox 2.0 explicitly deny that. We are thinking of other ways to open local files from the webinterface. -- - Debajyoti Bera @ http://dtecht.blogspot.com beagle / KDE fan Mandriva / Inspiron-1100 user ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
Re: State of the Pooch
On Friday 17 November 2006 17:22, Joe Shaw wrote: When a crash occurs, we should try each of the items in the crashing batch individually to narrow down the exact file that crashes, and then mark it (probably with an xattr) to not try to filter it ever again. I'd propose storing the version of beagle, and only trying again if stored_beagle_version != current_beagle_version. Combining this with a kind of 'blacklist' somewhere, which stores the ids of all files causing the helper to crash, would solve the whole problem transparently for the user. Just check if the beagle version changed and try to re-index the files on the blacklist. Otherwise this would pose the problem: Hey my new beagle is supposed to fix the helper crash I reported, why am I still unable to find the offending file in the index? Regards, Flo -- Florian Hackenberger student @ University of Technology Graz, Austria [EMAIL PROTECTED] www.hackenberger.at ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
Re: State of the Pooch
Hi, A few fill in the blanks from my side: * Generics and .NET 2.0 ... move to generics will also help reduce our memory usage. In The memory reduction and speed improvement are _huge_. I decided to switch CVS to generics a couple of week ago but some runtime crashes during my testing with 1.1.18 stopped me. Unfortunately, 1.2 is not suitable for the extended attribute problem Joe mentioned in an earlier problem. But the switch is happening soon. * Showing status on the state of the index The infrastructure is mostly there. One of the reasons I feel none of the backend authors (ahem) use it because none of the known UIs actually show this information. GUI people please figure out how to inform the user about indexing and index status and the backends will get straightened out. * Handling crashes in the index helper better. This is a killer. Its on my cards once unified index lands. Since there wont be a separate index for each backend, a single bad file could potentially ruin data from other backends. The webbrowser backends e.g. wont be able to recreate the index if purged. They need to be in a separate index. * Removable media Beagle needs to support indexing of data on removable media. There isn't any support for this right now. I don't really have in-depth details about this, but it's on the radar and (sadly) pretty far down on the TODO. I started working on it and its lying 50% completed in my local tree. If anyone is interested, I can transfer the code and/or provide help. * Thunderbird memory usage The Thunderbird backend is a bit of a hog right now. This is: http://bugzilla.gnome.org/show_bug.cgi?id=355549 Kevin has been doing some work on this, but we really need people to take a look at this. I know that this backend has been disabled by default in Fedora Core 6. I suggested some potential improvements to Kevin. The initial improvement is already in CVS. While a streaming Mork parser would be the best way to fix this, I have different plans to tame it. Working on it. * The return of D-Bus Yup. D-Bus would be good. For KDE4 ;-). I think that's it! There is always work to be done in supporting new file formats through filters and data sources through backends, as well as improving our documentation on the Wiki. We've done a great job Joe, Can we put the libbeagle documentation on the wiki ? Like the glib docs. For some reason I cant generate the documentation on my machine and having an updated API documentation on the web will make people interested in using the API. I can do it, but how do I add a bunch of html pages to the wiki as-is ? - dBera -- - Debajyoti Bera @ http://dtecht.blogspot.com beagle / KDE fan Mandriva / Inspiron-1100 user ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
Re: State of the Pooch
On Sun, 2005-05-08 at 16:58 +0100, Daniel Drake wrote: If we move away from GNOME CVS, will we lose out on the translations side? Right now, it looks like random gnome translators are stumbling onto our project and and translating it into all kinds of languages, which I'm very impressed by. Yeah, we probably would. I hadn't thought of that. Other GNOME-related projects like Rhythmbox and AbiWord get translations and they're not developed in GNOME CVS. I'll bring it up on gnome-i18n like Enver suggested. Joe ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
Re: State of the Pooch
Hello, If we move away from GNOME CVS, will we lose out on the translations side? Right now, it looks like random gnome translators are stumbling onto our project and and translating it into all kinds of languages, which I'm very impressed by. An option for translations would be to keep the master po file on the GNOME CVS and have a script that updates it once a week or so. Miguel. ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
