researchbuddy
| resources: | Home Mailing List Installation Source Code Members Bugs Screenshots |
|---|
Installation
XPI INSTALL LINK - click on the link, and install it! To develop, unzip this file and go digging through the source.
package.sh - For developers: script to re-package the xpi after you make changes. Works in linux/mac Research Buddy adds one menu bar in the Tools menu and a menu bar in the menu that appears when you right click. It gets the selected text and sends it to our XUL code.
We use some of the XPCOM components:
nsIFile - to delete, rename and create new files and directories
nsIWebBrowser - to save the current document
nsIDOMDocument - to access the current document
nsIFilePicker - to choose the root directory in the preference
User Manual: link
Communication: We didn't use almost any of the mozdev facilities:
- mailing list: I (Eric) sent one message to the list, but found that I had to manually approve it before it would be sent. Rather than try to figure out how to disable this, we just used a "reply-all" ring to communicate.
- IRC: not used. The lab in Tompkins 211 does not allow IRC traffic out, and since at least one of us was working in there most of the time, we stuck to email and phone calls.
- CVS: our code was very well segmented, so we all developed separately. Combination was done with everyone in the same physical location, so we didn't use cvs until the very end (to post to mozdev - which, incidentally, we couldn't figure out. screw cvs, just download the xpi)
- Bugzilla: project scope was determined too small in scope for use of bugzilla. Since it's at a stable state now, we could probably file future bugs in bugzilla, but during rapid prototyping, all bug discovery was verbally discussed and solved at the time of discovery.
Development started as a mix of C++ component and javascript, but due to many, many problems with C++ code, we converted everything to javascript. Individual developers' code would work fine, but not well upon integration. Since # of developers was small, the complexity of integration should not have taken too long, but it ended up adhering to the rule of "adding more developers makes it go slower". It helped, in the end, to all be working in the same room where we could freely converse and spot bugs in other people's code. The learning curve for XUL-XPCOM is still quite high, and that's why we decided to convert everything to javascript. This has the added bonus of making it easier to compile (you don't have to! hahaha) and easier to run.