2003-08-12 05:16:09 +05:30
|
|
|
* History of navigation and the Back button. The RFE 747529, see
|
|
|
|
|
http://sourceforge.net/tracker/index.php?func=detail&aid=747529&group_id=25770&atid=385140
|
|
|
|
|
asks for the Back button in the Family View, but it'd be more consistent
|
|
|
|
|
to enable it in all navigatable views (People, Pedigree, and Family).
|
|
|
|
|
We'd have to keep track of the active persons and enable Back-Forward buttons,
|
|
|
|
|
maybe even a history popup with the list of those people. Very similar to
|
|
|
|
|
browsers and, therefore, very useful and familiar to users. We already have
|
|
|
|
|
bookmarks and home button.
|
|
|
|
|
|
|
|
|
|
As for the interface, we can have "Go" menu with Back, Forward, and
|
|
|
|
|
Home. Back and Forward can have down-arrow popups. Plus, all the views
|
|
|
|
|
can have Back and Forward in the context menus.
|
|
|
|
|
|
|
|
|
|
* Remember where the images are added from (RFE 748974). This is actually
|
|
|
|
|
very useful when you add 50 new images -- navigating 50 times to the same
|
|
|
|
|
place is a nightmare. All that's needed is keeping track of a single
|
|
|
|
|
last selected directory and then point gtk.FileSellector there.
|
|
|
|
|
|
|
|
|
|
* Presense of Notes for a person/event/whatever_else. RFE 747527 suggested
|
|
|
|
|
either a column in the People View or something like boldfaces "Notes"
|
|
|
|
|
tab title. I like the latter because it can be uniformly applied to
|
|
|
|
|
any notes, not only people's. Not so hard to implement.
|
|
|
|
|
|
|
|
|
|
* Following the only child in a family view (RFE 750987). If there's a single
|
|
|
|
|
kid, an arrow should clearly follow this child, even if (s)he's not selected.
|
|
|
|
|
This is a minor thing and also should not be too hard.
|
|
|
|
|
|
2002-10-20 19:55:16 +05:30
|
|
|
* Allow for multiple notes. A tabbed interface would be really useful,
|
|
|
|
|
since there are no titles for notes. Not all objects would necessarily
|
|
|
|
|
need multiple notes. Determine which ones should and shouldn't.
|
|
|
|
|
* Speed up the reading of the database. The python XML routines are not
|
|
|
|
|
as fast as I would like, and it can take a minute or so to read a
|
|
|
|
|
large database. This is way too slow.
|
|
|
|
|
* Finish the generic load of revision control interfaces to allow a
|
|
|
|
|
revision control plugin system. Most of the work is already done.
|
|
|
|
|
* Disable the save buttons if gramps database is marked read-only. Disable
|
|
|
|
|
the adding of media objects as well, since this will cause gramps to
|
|
|
|
|
try to create a thumbnail in a readonly database.
|
|
|
|
|
* Startup tips.
|
|
|
|
|
* And a whole lot more....
|
