From: Don A. <don...@co...> - 2004-11-17 03:26:31
|
Alex and I have gone through the outstanding RFEs (Request for Enhancements) for the 1.1.X branch, and we've compiled a list of items that need to be done. If you are looking for an opportunity to contribute, here are a few possibilities. If you are interested in helping with a task, please let us know. Here are a few of the top items. 1) Column control in the Family View child list. Currently the major lists allow you to add, delete, and rearrange columns. The child list does not have this ability now. The child list currently uses the gtk.ListStore, which is fixed in size. GRAMPS has a its own BaseModel class which could provide the desired functionality. 2) Selection of a subsection of a photo. GRAMPS has added a pair of x,y coordinates to a MediaRef object. This will allow the user to select a rectangular region of a shared photo. So if you have a family reunion photo, you can associate it with each person, and select a region for each person, allowing you to point out where Aunt Martha is in the photo. The part we are lacking is the ability to graphically select the subregion. If you want to play with some basic graphics, this might be the task for you. 3) Drag and Drop reordering of spouses/relationships in the Family View. 4) Plugin to remove people that match a filter. 5) Default source. Provide a mechanism to allow the user to easily assign the default source to data. 6) Place merging tool, similar to the "Find Duplicates" tool. 7) Add a "Recent Database" list to prevent the need to search through the filesystem to find recently accessed databases. 8) Import/Export to a CSV (comma separated value) file. 9) Export to a SpreadSheet. Enhance SpreadSheet to support Gnumeric in addition to OpenOffice. 10) Capitalization converter - This could be useful, since a lot of programs force everything to upper case. While straight capitalization would not be good, we could present a list of names and suggested replacements. The user could then override any particular name. 11) Report Enhancements. Tons of requests for this, including the advanced web page generator. Don |
From: Eero T. <oa...@we...> - 2004-11-17 19:34:05
|
Hi, > 8) Import/Export to a CSV (comma separated value) file. This RFE is originally from me, I'll explain it a bit more below. > 9) Export to a SpreadSheet. Enhance SpreadSheet to support Gnumeric > in addition to OpenOffice. All spreadsheets (Excel, OO-calc, Kspread, Gnumeric...) can read and write files in the CSV format. So, unless support for images, formulas or other more advanced spreadsheet features (than just the data in columns) is required, CSV support would probably be enough. Latest Python already supports reading and writing CSV format files: http://www.python.org/doc/2.3.2/lib/module-csv.html I.e. "only" thing to do would be to map the selected data to two-dimensions. It would be great if there would a dialog where one could select what person information to export, and to what person information to map each column in the CSV file import. I think doing this for the information in the "Edit person" dialog "General" tab would be quite enough. People should be able to do quite a bit of spreadsheet analysis & reports even with that data and at least Kspread can be programmed with Python :) (CSV Import would be mostly of use if one uses spreadsheet to quickly type in a list of people or has been previously maintaining people in a one). - Eero |
From: Don A. <don...@co...> - 2004-11-19 00:13:00
|
On Tue, 2004-11-16 at 20:26 -0700, Don Allingham wrote: > 1) Column control in the Family View child list. Currently the major > lists allow you to add, delete, and rearrange columns. The child list > does not have this ability now. The child list currently uses the > gtk.ListStore, which is fixed in size. GRAMPS has a its own > BaseModel class which could provide the desired functionality. I have just checked this into CVS. Don |
From: Don A. <don...@co...> - 2004-11-19 01:17:09
|
On Tue, 2004-11-16 at 20:26 -0700, Don Allingham wrote: > 3) Drag and Drop reordering of spouses/relationships in the Family > View. This has just been checked into CVS. Don |
From: Don A. <don...@co...> - 2004-11-21 00:38:49
|
On Tue, 2004-11-16 at 20:26 -0700, Don Allingham wrote: > 10) Capitalization converter - This could be useful, since a lot > of programs force everything to upper case. While straight > capitalization would not be good, we could present a list of names > and suggested replacements. The user could then override any > particular name. I've just checked in a new Capitalization plugin that tries to determine names that can be converted from all capitals to normal case. If you can, please give this a try and let me know if you have any problems. Don |
From: Julio S. <jul...@gm...> - 2004-11-25 09:46:34
|
On Tue, 16 Nov 2004 20:26:32 -0700, Don Allingham <don...@co...> wrote: > 5) Default source. Provide a mechanism to allow the user to easily > assign the default source to data. Yes, while doing manual input it is useful to have a default automatic source. Also, it would be useful to have this while importing and to set the source from import data, i.e. have all facts without a source coming on a GEDCOM file get a source related with that import. So that if I import and merge data from some researcher, I assign him or her as a source for that information unless a more concrete source is cited. Optionally, adding it even in the presence of other source. Ideally, a source would be proposed on import constructed from information in the source import file. > 6) Place merging tool, similar to the "Find Duplicates" tool. Yes, great. Also, it would be good if there was a method to traverse the database and collapse/merge events that have become now identical after the place merge, i.e. while merging people two events were deemed different because they happened in different places and were thus duplicated. Now that the two places have been declared the same, the event is kept twice and looks silly. Also, source merging is useful. All these problems are common if you merge a lot, as I do, and if you happen to have to correct the spelling of data. On these and thoughts on merging, I will send a message later. > 10) Capitalization converter - This could be useful, since a lot > of programs force everything to upper case. While straight > capitalization would not be good, we could present a list of names > and suggested replacements. The user could then override any > particular name. Very related, I would like to have a surname prefix converter that finds them, either at the end of the given name or at the beginning of the surname and allows moving them to the surname prefix field. It seems like another extension of the nickname finder. > 11) Report Enhancements. Tons of requests for this, including the > advanced web page generator. Currently, uniformity in the handling of additional information, such as notes, sources, etc. is very low. I think they need some refactoring so that reports support a similar set of options when it makes sense. Now that I mentioned refactoring, I think there are a number of date-handling functions that should be extracted and made common, things like estimating dates, comparing dates +/- offsets, etc. Julio |
From: Don A. <don...@co...> - 2004-11-28 05:06:04
|
On Thu, 2004-11-25 at 10:46 +0100, Julio Sanchez wrote: > Very related, I would like to have a surname prefix converter that > finds them, either at the end of the given name or at the beginning of > the surname and allows moving them to the surname prefix field. It > seems like another extension of the nickname finder. > I just checked in an enhancement that allows the plugin to detect titles, nicknames, and common surname prefixes. Don |