41 lines
		
	
	
		
			2.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			41 lines
		
	
	
		
			2.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
* 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.
 | 
						|
 | 
						|
* 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....
 |