Festive Musings

As family commitments over the festive period meant that I could not do any development work, I had lots of time for musing about future Gramps related work. These ideas are just the ramblings of an overfed mind so please treat them as such. If any of them look interesting then I could add them to the development portal, I’ll see if I get any comments.

I have been thinking about RelLib. It appears to me that a lot of RelLib is boiler plate code (getters, setters, list add/remove/check) that is repeated for each attribute on each class. This has a number of downsides, it means that mistakes can easily be made because of all the repetition, it means that method/attribute naming can sometimes be inconsistent, it makes it time consuming to add/modify the classes and it makes validation/type checking of attributes hard work because of all the replicated code. So I was thinking that a possible alternative would be to use some of Pythons meta-class stuff to simplify the specification of the RelLib classes. This would involve: defining ‘type’ classes for each of the different sorts of attributes (i.e. handles, strings, numbers etc.) these ‘type’ classes would include validators and serialisers for all attributes of the class; defining classes for each of the RelLib ‘Primary’ and ‘Secondary’ classes that listed their attributes in a ‘class attribute’; defining a meta-class that would take the ‘class attribute’ lists and auto generate ‘on the fly’ the settings/getters/list methods/serialisers etc. all with appropriate validation checking/debug logging etc. I think that this would drastically cut the amount of code in the RelLib package and should make it is simpler to ‘see’ what the attributes of the ‘Primary’ and ‘Secondary’ classes are.

Logging/bug reporting/debugging. There is currently little consistency in the way that logging/debug output is handled. There is a mixture of print to stderr and the use of a gtk dialog to report exceptions. I was thinking that a policy for using the Python Logger module would help to make a more consistent approach to logging output. The Python Logger module is very good and can be used in such a way that the end user can redirect logging output in any way they choose with out modifying any of the code. A few thing things would be ‘nice to have’ if the Logger module were to be used: a developers guide to ensure consistent usage (very short); a gtk ‘error report’ wizard that could be triggered if an exception occurred (this would be implemented as a new LogHandler class); an in memory ‘buffer’ type log handler that would always remember the last X log messages; and a GUI to allow the user/developer to control how logging/error handling should happen. This infrastructure should support much better error reporting from users, the ‘wizard’ could gather information about the system (OS, gramps/gtk/gnome versions etc.), about the state of gramps (i.e. the last X log messages etc.), about the exception and about the user (if they want to give it).

Contributed plugins/reports. Some of the discussion recently about dropping unsupported reports and the emergence of the new Calendar Report got me thinking about how to better support contributed plugins/reports without adding them to the code base and then having to remove them later if they are not supported. I think that it should be possible to have an integrated ‘download contributed plugins’ facility. This would work by having contributed plugins on a server somewhere with an appropriate XML index and some infrastructure in gramps to fetch the index and present the user with a list of available plugins. The plugins could state which versions of gramps they are known to run on and it would be up to the plugin authors to keep them up to date. This is kind of like the extensions stuff in Mozilla.

There are other ideas buzzing around my head as well like: a hierarchical object browser that would allow you to view the whole database as a big collapsible tree, with each attribute appearing as a leaf and each Primary/Secondary object as a node; virtual views based upon saved search criteria; enhanced search capabilities that would enable searching for any object in the database etc. but these are not very well thought out at the moment.

And I still want to get the ‘research trip planning’ functionality built from an enhances Source/Repository data model…

Happy New Year to all gramps users and developers.


Responses are currently closed.

Sorry, the comment form is closed at this time.