This page collects possibilities for the 3.2 version of GRAMPS
Changes to the way developers handle the workflow. This will be decided by the core developers in the near future.
- Required minimum pylint score? This would require all present code to at least obtain this score?
- svn branches for database changes and main goals? Can everybody with commit rights make a branch or only admins?
- Decision on the definition of the different parts of GRAMPS. What do we allow as plugins, views, gramplets, ... ? How do we offer the user a non-confusing image of what GRAMPS is? This starts in version 3.1 with not distributing some parts of GRAMPS that are present in the subversion repository.
For 3.1 we have: Python 2.5 or greater, PyGTK2 2.10 or greater, Python Glade bindings, librsvg2 (svg icon view), xdg-utils Recommended or optional: GraphViz, gtkspell, ttf-freefont. Documentation is in mediawiki.
Database backend changes
Are there features that require database change? This should happen in the beginning of the development cycle. List your requirements here. Database changes should be started in subversion branches (see commands eg here)
- event subtype: bug tracker:. There is partial support for this in GEDCOM that is not present in Gramps. This addition would mean a rework of the event type system to make it more user friendly to the user, instead of the copy of GEDCOM it is now: selection of most used events, main events with subtypes, addition of iternaries as subtype to use for map display, .... Developers: bmcage - Reviewers: ?
This section lists main goals developers want to achieve with GRAMPS 3.2. Main goals should be started in subversion branches (see commands eg here)
- File Organization (GEPS 008): bug tracker:. Developers: ? - Reviewers: ?
- Import Export Merge (GEPS 009): bug tracker:. Developers: ? - Reviewers: ?
- Beter API documentation: bug tracker:. Developers: ? - Reviewers: ?
- rework PageView classes: bug tracker: TODO. Aim would be to split PageView and classes to it's own subdirectory, allow views to be plugins, have PersonView derive from the same classes as the other views instead of a custom class, have history in all listviews (as it was intended originally, code is half finished now), allow organized views in source/place like in present person view. Developers: bmcage - Reviewers: ?
This section lists minor goals developers want to achieve. Changes to plugins are normally minor goals !! Minor goals can be done by one developers alone.
- Fully functional GeoView: bug tracker: TODO. GeoView has some way to go to be on the level needed to allow inclusion in GRAMPS. Developers: ?
- Remove memory leaks present in glade loading code. bug tracker: