Hi Nils, Welcome back! Nice to see you again. :)
On 11/21/07, Nils Erik Svangård <[EMAIL PROTECTED]> wrote: > * libdashboard - Or as its better known, a C library that generates > valid, parseable clues. This is not only critical since most plugin > authors aren't going to want to spend the time validating that mono > can deserialize all their XML. But because we can generate bindings > for most every other language once we have them in C. I actually think this is the wrong thing to do. This is something we explicitly avoided the first time around with Dashboard, and was a large reason why we were able to instrument as many applications as we did. The problem with creating a library and making people use it is that it introduces a new library dependency. That's extra work for the maintainers of the software, developers, and packagers of the software, and for something as immature and experimental as Dashboard, they simply won't do it. So the way we did it originally was to include a fully self-contained .c file which people would #include into their project, and all the functionality could be included as a simple patch. Ok, that was a long setup, but I think it might even be easier today: with inotify, we don't even really need a programmatic IPC mechanism -- we can just drop XML files into a watched directory and the Dashboard can pick them up automatically. For projects which already use D-Bus, that's a viable alternative as well (but not the sole one -- no adding D-Bus to projects which don't already use it, because, again, added dependencies). > * Real Bug/Performance Testing/Fixing - This is a huge one, Dashboard > is still pre-alpha, and mostly proof of concept. While the code base > could be brought up to production level, it needs tons of cleanup. The amount of Dashboard code there is sufficiently small enough that it can either be used as a starting point, as a good chunk of reference code to look at, or redone completely. I would strongly encourage unit and automated regression tests for this sort of thing; it's something we haven't been particularly good about in Beagle and it has clearly hurt us. > Is there more stuff that have to be done? Well, there isn't a UI for it, so that's a big amount of work. :) It's unclear to me exactly how to present results most usefully to users. The decaying method we had before was a fairly simplistic way of doing it. Some machine learning would probably be pretty useful here. > Is anybody working on dashboard? Sadly, I don't think so. There were some patches sent to the list, and I believe some were committed, but nobody has really taken ownership of the project, which is what it really needs at this point. Joe _______________________________________________ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers