Difference between revisions of "GEPS 012: Ecosystem definition"

From Gramps
Jump to: navigation, search
(Gramplets)
(Quick Reports)
Line 72: Line 72:
 
* 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
 
* 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?
 
* simpledocument can be reused as a writing structure for a service? Perhaps also inside a Gramplet?
 +
 +
[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? --[[User:Dsblank|Dsblank]] 13:25, 3 February 2009 (UTC)]
  
 
=== Gramplets ===
 
=== Gramplets ===

Revision as of 13:25, 3 February 2009

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 a fixed set of data entry modules (the editors). The aim is to be reliable, and to be able to store as much relevant genealogy information as possible.

GRAMPS Views

Views are general ways to browse/see/present the data stored. Different devices might call for different types of views. We should work out a procedure on how to make views plugable, 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, hits search and is presented with a treeview of matches. The reason of such a view would be speed on large databases
  • 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
  • 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.

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. Should it be possible to distribute a view as a plugin?

Reports

A report is a specific display of information about your data for presentation on paper (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

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?

[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)]

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.

Certificates

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

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.