* NEWS: Bring up to date.

* TODO: Likewise.


svn: r2051
This commit is contained in:
Alex Roitman 2003-08-27 00:32:13 +00:00
parent fe159d611a
commit ba34fb283d
3 changed files with 18 additions and 20 deletions

View File

@ -1,3 +1,7 @@
2003-08-26 Alex Roitman <shura@alex.neuro.umn.edu>
* NEWS: Bring up to date.
* TODO: Likewise.
2003-08-25 Alex Roitman <shura@alex.neuro.umn.edu> 2003-08-25 Alex Roitman <shura@alex.neuro.umn.edu>
* src/gramps.glade: Minor cleanups for the alternate family view. * src/gramps.glade: Minor cleanups for the alternate family view.
* src/gramps_main.py: Likewise. * src/gramps_main.py: Likewise.

View File

@ -1,6 +1,5 @@
Version 0.9.4 -- the "This used to bug me..." release Version 0.9.4 -- the "This used to bug me..." release
* More compliance with GNOME HIG. * More compliance with GNOME HIG.
* User can choose either the People or Family view as default
* Fixed style problems for book items. * Fixed style problems for book items.
* New Book item: Custom Text. * New Book item: Custom Text.
* New export plugin: Web Family Tree. * New export plugin: Web Family Tree.
@ -10,8 +9,8 @@ Version 0.9.4 -- the "This used to bug me..." release
* Various Merge and Import fixes. * Various Merge and Import fixes.
* More privacy options for GEDCOM export. * More privacy options for GEDCOM export.
* New types of filter rules: * New types of filter rules:
(1) iterating over other filters, (1) Iterating over other filters;
(2) specifying number of generations away for ancestors and descendants. (2) Specifying number of generations away for ancestors and descendants.
* Preliminary support for printing copies of reports. * Preliminary support for printing copies of reports.
* Performance improvements for list views. * Performance improvements for list views.
* Context menus in Family View upon right-click. * Context menus in Family View upon right-click.
@ -19,6 +18,18 @@ Version 0.9.4 -- the "This used to bug me..." release
* Proper saving of standard family relations, event types, and attributes. * Proper saving of standard family relations, event types, and attributes.
* New interface for adding/editing filter rules. * New interface for adding/editing filter rules.
* Configure/build improvements. * Configure/build improvements.
* Removal of intl*.so and switching to Python's gettext.
* Python2.3 compliance.
* User can choose either the People or Family view as default
* New icons for People and Family sidebar buttons.
* History-based browser-style navigation tools:
(1) Back and Forward toolbad buttons;
(2) Go menu with Back, Forward, Home, and History items;
(3) History popups upon right-clicking on Back and Forward buttons;
(4) Context menus in the People, Family, and Pedigree Views.
* User can choose between the usual (left to right) or alternative (top to
bottom) Family View.
* Support for graphics in Book Report.
* Fair share of bug fixes. * Fair share of bug fixes.
Version 0.9.3 Version 0.9.3

View File

@ -1,16 +1,3 @@
* 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 * 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 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 place is a nightmare. All that's needed is keeping track of a single
@ -21,10 +8,6 @@
tab title. I like the latter because it can be uniformly applied to tab title. I like the latter because it can be uniformly applied to
any notes, not only people's. Not so hard to implement. 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, * Allow for multiple notes. A tabbed interface would be really useful,
since there are no titles for notes. Not all objects would necessarily since there are no titles for notes. Not all objects would necessarily
need multiple notes. Determine which ones should and shouldn't. need multiple notes. Determine which ones should and shouldn't.