Revision as of 12:39, 18 July 2013

My GRAMPS-related scratchpad

merge familylines and relgraph good stuff into a common report
auto-translation of names, places, etc. - for reports and exports
reports & export should have more in common -- in filtering/selecting source set and output data
- new action - filter, expose for cli?
- see also bug #1600 and Filtered_Reports
what is the best practice for collaboration with other active researchers? Is there a tutorial? Should gramps collab with multisync @sf? or some DVCS? Obvious use cases:

two (or more) people using GRAMPS. Each wants to be the master of his own DB and vet anything incoming.
make life easy for people taking periodic exports from gramps

(This is a known hot issue, see How_you_can_help#Web_2.0)
- can we send out only the stuff that changed? (yet another multisync sub-problem)

we need a feature usage stats tracker, there's lots of obscure features that probably aren't used much, but contribute to overall complexity. E.g., should we cut some of the report backends?

Cairo Tutorial for Python Programmers, by Michael Urman
python-cairo v3 docs
pygtk docs slightly outdated wrt the trunk env, e.g., pango.Layout.set_text() doesn't list the mandatatory second argument for string length on my system... python help(pango.Layout.set_text) is the final authority!..

@@ Line 10: / Line 10: @@
 # two (or more) people using GRAMPS. Each wants to be the master of his own DB and vet anything incoming.
 # make life easy for people taking periodic exports from gramps
+* (This is a known hot issue, see [[How_you_can_help#Web_2.0]])
+** can we send out only the stuff that changed? (yet another multisync sub-problem)
-This is a known hot issue, see [[How_you_can_help#Web_2.0]]
+* we need a feature usage stats tracker, there's lots of obscure features that probably aren't used much, but contribute to overall complexity. E.g., should we cut some of the report backends?
-- can we send out only the stuff that changed? (yet another multisync sub-problem)
 =Dev bookmarks=