GEPS 012: Ecosystem definition

From Gramps
Jump to: navigation, search
Gnome-important.png
'THIS DOCUMENT IS NOT FINISHED ! '

Proposition of definition of the ecosystem around the core GRAMPS system for storing genealogy data. The aim of this GEPS is to come to an official GRAMPS-community endorsed recommendation on how new functionality should be added to GRAMPS.

Motivation

In GRAMPS 3.0.x there are several ways to add functionality to GRAMPS:

  • core changes
  • write an export/import tool
  • write a report (GUI or CLI)
  • write a tool
  • write a quick report (or quick view)
  • write a gramplet

It is unclear for the developers under what form factor a functionality should be added to GRAMPS. Moreover, there are still features people want to add that not fully fit into these categories: certificate manager, map interaction.

Proposed definition

GRAMPS core

The core of GRAMPS is storing genealogy data. The data model belongs to the core, as well as some convenience routines. Also the gui aspect has a core: a fixed set of data entry modules (the editors) allowing edit of everything defined in the data model.

The aim of GRAMPS is to be reliable, and to be able to store as much relevant genealogy information as possible.

GRAMPS Application

The GRAMPS application is the program using the core to store the users family tree. In 3.1.x this consists of a monolithic application. The code should be reorganized into a reusable core, a gui application, and a cli application. We should stay true to the Unix principle: do one thing and do it good. The GRAMPS gui is about storing and analyzing genealogical data. The cli is about accessing this data from the command line. See also external dependencies.

Future: There are questions from time to time for a web interface to the GRAMPS data (GEDCOM does not map to it and GRAMPS does not offer extensions to GEDCOM), and for a maemo/android/iphone/... app to browse the GRAMPS data. The GRAMPS community would be more than happy to collaborate with such project to improve the core. There are no plans to extend the codebase to cover these uses however, so work should start in a different repository. Should developer support exist for such projects within the GRAMPS developers, it might be considered to organize the GRAMPS repository in such a way to accommodate work in a unified repository (keeping the projects itself separate).

GRAMPS Views

Views are general ways to browse/see/present the data stored. Views are the starting place in the GRAMPS gui to interact with and analyze your data. We should work out a procedure on how to make views pluggable, and allow for the creation of different views.

  • The core views are: Person view, family view, event view, place view, source view, repository view, note view
  • Derived views are: Relationship view, Pedigree view
  • Convenience views: Gramplet view, Geo view

Possibilities for the future:

  • Derived views:
    • Person search view: A view that shows a person search box. One types part of the name or other search criteria, hits search and is presented with a treeview of matches. The reason for such a view would be speed on large databases as a full treeview becomes very slow on large databases
    • Timeline view: a view showing all info of a person on a timeline, centering on the events a person was part of
  • Convenience views:
    • Certificates view: a certificate is a specific way of entering data into GRAMPS. One is presented with an entry form reflecting a typical birth/death/marriage/census certificate, and enters the information as seen on the real certificate. The certificate logic stores all according to the correct certificate knowledge in the database


Future: A view is a way to interact with your data embedded in the main GRAMPS application. Some core views must always be present. These can depend on the form factor. The user should be given the power to enable/disable derived and convenience views. There is no need to forbid certain types of views. It should be possible to distribute a view as a plugin, adding functionality to GRAMPS like this, reusing the GRAMPS core

Comments:

  • It would be nice if every view had a default associated report, so that each one could have a print button. The print would respect the filters set, and columns. The list views could do this similar to the Export View as CSV, but most other views have very similar reports already.
  • Currently, you can only have one view of each type. It might be handy, for example, to have two People Views, one set to one filter, and the other set to another filter. Active Person, and change_active could not be global.

Reports

A report is a specific display of information about your data for presentation (be it pdf, odf, html or printpreview).

Reports have an option dialog to define the output settings (at the minimum format and page size)

Pro:

  • Reports are a common way to show to family members the familytree you have created
  • They are essential in how users perceive the quality of GRAMPS

Contra: Running a report means: Report menu --> submenu --> selection --> give data in option dialog --> generate report --> open the report. It is hence something you do to obtain a specific result for further consultation. The user does not want to feel as if he needs to create reports all the time to be able to fully understand what data is stored in his family tree.

Tools

Tools are for:

  • multiple dialog tasks not part of the core
  • maintenance tasks: debug, repair, ...
  • time intensive interactive tasks that otherwise would be gramplets
  • interactive work with groups of objects

Future: TODO

  • Tools aren't sensitive to changes in active person or home person. They could be more useful if you didn't have to close/open to get such a change.

Quick Reports

A way to see a document based report about a specific object. Ties in closely with the simpledocument and simpleaccess classes

Pro: This exists since 3.0.x with the aim of allowing less experienced developers to make their own small reports. It is most convenient that one knows the data is only shown in a widget, and is not for printing (copy/paste is possible on most though).

Contra:

  • The access to quick reports is cumbersome: submenu of context menu.
  • The connection to one active object does not scale.
  • Not meant to scale to more serious reports

Future:

  • simpleaccess can move as a library for new users to write their own plugins. For internal GRAMPS use it should be discouraged.
  • Quick reports should be deprecated, and become: a gramplet if it fits that form factor, a service if it fits that form factor, a real report if it fits that form factor
  • simpledocument can be reused as a writing structure for a service? Perhaps also inside a Gramplet?

Comments:

  • The SimpleTables are very handy, but prevent copy/paste. This could be fixed. I don't think we should let simplicity of the code limit the flexibility of the functionality. --Dsblank 13:43, 3 February 2009 (UTC)
  • I really don't like the idea of a simple interface just for newbies. If it is truly simpler, then it should become part of the API. This could be done by having sensible defaults (both as parameters, and as return values) or other methods. Why would we have an interface that we discourage developers to use? --Dsblank 13:25, 3 February 2009 (UTC)
  • I've noticed that sometimes one wants to create something like a quick report but it isn't tied to a particular entry; it should be available without having to select a particular person/event/etc. --Dsblank 22:18, 29 August 2009 (UTC)

Gramplets

Gramplets are reports shown as a widget, allowing interaction with the GRAMPS database. So they serve a same purpose as a report but with a different aim: help the researcher in his genealogy research during his interaction with GRAMPS.

Gramplets work on all data, all data of an object class, or the active object.


Cons

  • At the moment gramplets can be everything, as all kind of gtk widgets can be used. [Gadgets/Widgets usually can be anything. That is not a "con". Perhaps the con is that currently there isn't enough flexibility in the rest of GRAMPS (unable to create a new view, unable to create these proposed "certificates" data entry methods, etc.) so that things are currently written as gramplets that should be something else. But that is not a con with gramplets.]

Future:

  • Gramplets should not have a print function. Instead they can have a report function, opening a report dialog to create a report with the same information as shown in the gramplet. Core functionality will obviously be reused between the two uses.

Perhaps only Gramplets that have a report associated with it should be allowed.

  • Gramplets should not have data entry. Instead of using the gramplet structure for data entry, certificates should be developed and used. Perhaps a certificate will have the same base class as a Gramplet, but how it works is different, see certificate
  • Gramplets should not overlap with tools. TODO
  • There should be better ways of showing the resource impact of a tool/gramplet/report. In computer science, we use O(1), O(n), O(n log n), O(n ** 2), etc to describe the relationship between items and time to process. Perhaps a simple rating system (from green/fast to red/potentially slow) to show the possible impact.
  • It might be nice to copy text from items to the clipboard.

Comments:

  • This is quite a bit more narrow than I would describe them. I would describe the way any gadget/widget is defined: "a device or control that is very useful for a particular job". Rather than trying to limit what a Gramplet can be, perhaps you can identify those current gramplets that you want to eliminate or move to something else. --Dsblank 13:50, 3 February 2009 (UTC)

Certificates

A way to enter information without following the data model. Instead the entry is based on the form real life certificates have.

See also: GEPS 024: Certificates

TODO Certificates are shown in a view?? and have these characteristics:

  1. they store data in the database on save
  2. they have a meaningful name linking them to a certificate type users can understand

TODO

Services

A way to start convenience functionality from a view/editor, without an options dialog. One click gives you an output result.

  • Example in 3.1.x: map services on the place view: select the thing you want to do, click: browser opens with the place you selected in a map.
  • Possible other uses: the quick reports that cannot be moved to gramplet/real report only, can be run this way. A quick report is then a service on eg the person view. Activating it shows a widget with a text report in a simpledocument class. So the one click paradigm. For official quickreports like this, there must always be a report button opening a report option dialog of the corresponding report that can present the same info in a more durable form.