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....
 |