I'll help write them if you want.
Brave man, consider yourself volunteered :-)
* Hierarchical tags... i.e. tags organized by trees.
If you can figure out a way to do it without complicating the UI. I
would impose the condition that the existing UI shouldn't become any
more complicated, and people who don't want trees of tags shouldn't be
exposed to any fallout.
* Paste BibTeX in the document properties dialog
Would be useful for the "add a pdf with some bibtex" use case. However,
why put it in the dialog rather than having a "Paste into" operation in
the main window?
* BibTeX fields that change based on the type in the document
properties dialog
http://en.wikipedia.org/wiki/Bibtex seems to have a pretty good list of
what is required and what is optional for each type.
This will require a considerable bit of careful restructuring behind the
scenes. Although such restructuring is fine by me, please bear in mind
that Referencer is not intended to be a bibtex-specific tool.
Constraints on which fields are valid for which document types may vary
between bibliography formats. As such, all this stuff needs to be
designed such that information about which fields are visible with which
document types is dynamic, and takes into consideration future export
targets such as MS Word bibliography files and OpenOffice.
Disclaimer: the bibdata stuff was written waaay before referencer was
ever going to be publically available! As such it's "nobody's ever
going to look at this" code.
Also, the document properties dialog needs to stay neat. The fields
should always be presented in a reliable order, and things that only
need half-width fields (such as year, issue # etc) should be presented
as such. I would like to avoid a list of fields so long it's scrollable
as far as humanly possible, possibly maintaining some fields as visible
by default, and others in a "More Fields" expander which may be valid
for a document type but are not so frequently used.
* On the document right-click menu, in addition to the 'Open...'
option, an 'Open With...' option.
My own use case for this is that I occasionally want to open a pdf with
acroread instead of evince -- what's yours?
* Per document notes... i.e. a mechanism for associating notes with a
particular item.
Perhaps a simple way to do this would be to leverage existing notetaking
apps (Zim, Tomboy, gnotes). Looking at Zim in particular it takes a
parameter that is the notes page. With an additional string stored in
BibData, a user specified notes app (probably set in preferences) and a
menu entry, an execle() could spawn the notes app with the associated
string as the parameter.
Some kind of layer that would allow referencer to interact with various
note-taking frameworks would be desirable, although support for a single
program would be acceptable as a prototype.
At this point we start to enter somewhat murky territory where what we
really want is a plugin system. A relatively big job.
* Related to the per document notes above... have a mechanism for
opening an associated xournal file.
I've been using xournal to annotate PDFs, and referencer doesn't have
any problem importing them. But, it would be nice if the xournal file
were associated with the actual paper.
I guess really what you're suggesting here is being able to associate
more than one file to a reference. Seems pretty viable, through a
concept of "Attachments" or so.
If you're serious about getting your hands dirty with this, feel free to
get me off-list on IRC (#referencer on freenode.net) or google talk
(username jcspray) to discuss code details, including telling me I'm
wrong about how things should be done ;-)
Although I wouldn't encourage using it as a wishlist in general, if
you're thinking about implementing something you might want to write up
a quick spec as a "Blueprint" on launchpad:
https://blueprints.launchpad.net/referencer/
John