From: Martin H. <Mar...@gm...> - 2005-08-02 13:48:08
|
Hi! Looks like we should give the bookmarks in GRAMPS a little work. (Don: I had a little talk to Alex about this.) 1) Bookmark Editor uses old gtk.CList 2) The bookmark does not get removed when a person is deleted (or merged). After this there is a stale menu entry and the bookmark editor is no longer usable: Traceback (most recent call last): File "/home/martin/devel/gramps2_20/src/gramps_main.py", line 1868, in on_edit_bookmarks_activate self.bookmarks.edit() File "/home/martin/devel/gramps2_20/src/Bookmarks.py", line 148, in edit name = NameDisplay.displayer.display(person) File "/home/martin/devel/gramps2_20/src/NameDisplay.py", line 127, in display name = person.get_primary_name() AttributeError: 'NoneType' object has no attribute 'get_primary_name' Where should this be handled? The bookmark could be removed inside the database handler but we do need a callback triggering the rebuild of the bookmark menu. gramps_main could therefore register a handler for the person-delete signal or something like that. 3) The menu entry vor adding a bokmark is visible in every view, but always adds the active person. Not good when in browsing in source view or the others. A Cool hack would be to be able to bookmark the other primary objects too. Cheers, Martin. -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ |
From: Alex R. <sh...@gr...> - 2005-08-03 03:07:20
|
Martin, On 08/02/2005 08:47:56 AM, Martin Hawlisch wrote: >=20 > 1) Bookmark Editor uses old gtk.CList Fixed in gramps20 -- ListModel and TreeView all along. I've also made it more HIG compliant by replacing Cancel/OK buttons with a single Close button -- all changes are immediately saved as they're done by the user. > 2) The bookmark does not get removed when a person is deleted (or merged)= . > After this there is a stale menu entry and the bookmark editor is no long= er > usable: Should be also fixed in gramps20, but please check this out just in case. > Where should this be handled? The bookmark could be removed inside the > database handler but we do need a callback triggering the rebuild of the > bookmark menu. gramps_main could therefore register a handler for the > person-delete signal or something like that. This is what I did, and it works fine for me, both with deletion and merging away. What I did not quite get is the Undo. When I delete a person and then Undo, I expect everything to be just like it was before deletion. However, the bookmark gets removed on deletion, but not restored on Undo. Strangely, Undo after merge magically restores the bookmark. I think for so= me reason the bookmark change gets added to the transaction during merge, but not deletion, at least this is my current theory. If you guys can untangle this it would be great! I'm fried for now :-) > 3) The menu entry vor adding a bokmark is visible in every view, but alwa= ys > adds the active person. Not good when in browsing in source view or the > others. A Cool hack would be to be able to bookmark the other primary > objects too. This will have to wait for some time. Do we want a single list for differen= t obejct types, or do we want separate bookmark lists for people, sources, places, etc.? Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Martin H. <Mar...@gm...> - 2005-08-03 11:35:52
|
Hi! > Von: Alex Roitman <sh...@gr...> > > 2) The bookmark does not get removed when a person is deleted (or > merged). > > After this there is a stale menu entry and the bookmark editor is no > longer > > usable: > > Should be also fixed in gramps20, but please check this out just in case. I have a problem with this. When removing a person that is bookmarked, the TreeView gets corrupted (assertion `VALID_ITER(child, tree_model)' failed) Hmmm wait... this does sometimes happen for people without bookmark too, and happens both, in C and DE locale. Strange. And it looks that the PeopleView has another bug too: I added a person with firstname "zzz", that got correctly sorted in as last element in the lastname group. After editing the firstname to "Bxxx" the position in the group was not changed correctly and the TreeView was corrupt. I can reproduce the not changed ordering, but cannot reporoduce the TreeView corruption. And as we are to changing peoples names... the Bookmarks need to be rebuild on that event too. -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ |
From: Alex R. <sh...@gr...> - 2005-08-03 13:21:23
|
On 08/03/2005 06:35:32 AM, Martin Hawlisch wrote: >=20 > I have a problem with this. > When removing a person that is bookmarked, the TreeView gets corrupted > (assertion `VALID_ITER(child, tree_model)' failed) > Hmmm wait... this does sometimes happen for people without bookmark too, = and > happens both, in C and DE locale. Strange. Which TreeView gets corrupted? Bookmark Editor's or the People View? I really doubt you can corrupt the Bookmark Editor's view, its so simple, with a flat structure. > And it looks that the PeopleView has another bug too: > I added a person with firstname "zzz", that got correctly sorted in as la= st > element in the lastname group. After editing the firstname to "Bxxx" the > position in the group was not changed correctly and the TreeView was > corrupt. I can reproduce the not changed ordering, but cannot reporoduce = the > TreeView corruption. Can't seem to reproduce this. Do I need to run under non-english locale? > And as we are to changing peoples names... the Bookmarks need to be rebui= ld > on that event too. You mean, we need to rebuild the bookmarks menu, right? The Bookmark Editor builds the list on the fly from the handles. I'll look into that. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Martin H. <Mar...@gm...> - 2005-08-03 13:57:38
|
> > When removing a person that is bookmarked, the TreeView gets corrupted > > (assertion `VALID_ITER(child, tree_model)' failed) > > Hmmm wait... this does sometimes happen for people without bookmark > > too, and happens both, in C and DE locale. Strange. > > Which TreeView gets corrupted? Bookmark Editor's or the People View? > I really doubt you can corrupt the Bookmark Editor's view, its so simple, > with a flat structure. This happens to the PeopleView. Another strange thing: I have a test database of 4 people, lastnames are "", "aa", "BB", "xx". Simply keep pressing the "Apply" button for the filter (Entire Database) and I can see that sometimes the sort order for the names changes. One time it is "aa", "", "BB", "xx", the next time it is "BB", "aa", "xx", "". I can reproduce it in C, de_DE and ru_RU locale. others untested. This is possibly causing the the invalid iter bug, because when updating the tree a wrong node is updated for the affected lastname? Cheers, Martin. -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ |
From: Brian M. <pez...@ya...> - 2005-08-03 04:23:47
|
Since I started using Gramps, my database has grown from 0 people to around 2,500. One thing I have noticed is that operations that previously occured instantaneously now take a few seconds. That's reasonably expected with a larger database. What I am wondering is how hard it would be to add a progress indicator to most features if the operations takes more than .5 seconds. One example is the "check and repair database". Selecting that menu entry provides no feedback - just a frozen screen for an unknown period of time. Perhaps a progress bar would help. Another example is when adding parents to a person or spouse in the family view. Upon clicking "OK", the "OK" button depresses and the screen freezes for an unknown period of time. I can move around the "Choose Parents" dialog and 'erase' the family view beneath it. What would it take to get a progress bar here? I really appreciate the "Find duplicate people" feature. That pops up a dialog with a progress bar while it runs. Just some food-for-thought. ~Brian |
From: Alex R. <sh...@gr...> - 2005-08-03 13:11:27
|
Brian, On 08/02/2005 11:23:39 PM, Brian Matherly wrote: > One example is the "check and repair database". Selecting that menu entry > provides no feedback - just a frozen screen for an unknown period of time= . > Perhaps a progress bar would help. >=20 > Another example is when adding parents to a person or spouse in the famil= y > view. Upon clicking "OK", the "OK" button depresses and the screen freeze= s for > an unknown period of time. I can move around the "Choose Parents" dialog = and > 'erase' the family view beneath it. What would it take to get a progress = bar > here?=20 This makes perfect sense. We should add it in the due course. If you could please file a bug report here: http://sourceforge.net/tracker/?group_id=3D25770&atid=3D385137 it would insure that we will not forget this. Thanks, Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Brian M. <pez...@us...> - 2005-08-03 13:18:54
|
Done. Bug # 1251042 ~Brian --- Alex Roitman <sh...@gr...> wrote: > Brian, > > On 08/02/2005 11:23:39 PM, Brian Matherly wrote: > > One example is the "check and repair database". Selecting that menu entry > > provides no feedback - just a frozen screen for an unknown period of time. > > Perhaps a progress bar would help. > > > > Another example is when adding parents to a person or spouse in the family > > view. Upon clicking "OK", the "OK" button depresses and the screen freezes > for > > an unknown period of time. I can move around the "Choose Parents" dialog > and > > 'erase' the family view beneath it. What would it take to get a progress > bar > > here? > > This makes perfect sense. We should add it in the due course. > If you could please file a bug report here: > http://sourceforge.net/tracker/?group_id=25770&atid=385137 > it would insure that we will not forget this. > > Thanks, > Alex > > -- > Alexander Roitman http://www.gramps-project.org > > |
From: Brian M. <pez...@us...> - 2005-08-03 13:14:59
|
Sorry, I posted with the wrong e-mail address. I'm using the RPM from: http://prdownloads.sourceforge.net/gramps/gramps-2.0.5-1mdk.noarch.rpm on Mandriva 2005LE x86_64. It occured to me to wonder if it runs slower on 64 bit architecture than 32, but I just can't think of any reason it would. Another observation is that it seems to slow down over time. By this I mean when I first open Gramps and add people, it feels pretty snappy. But after 10 minutes or so of entering new people, it gets more and more sluggish. After 30 minutes I usually shut down Gramps and restart it because it seems faster on startup. I'm in the process of digitizing my uncle's 20+ years of research. So I spend hours at a time just keying in new names. ~Brian --- Don Allingham <don...@co...> wrote: > Brian, > > Which version of GRAMPS are you using? > > Don > > -- > Don Allingham <don...@co...> > > --- Brian Matherly <pez...@ya...> wrote: > Since I started using Gramps, my database has grown from 0 people to around > 2,500. One thing I have noticed is that operations that previously occured > instantaneously now take a few seconds. That's reasonably expected with a > larger database. What I am wondering is how hard it would be to add a > progress indicator to most features if the operations takes more than .5 > seconds. > > One example is the "check and repair database". Selecting that menu entry > provides no feedback - just a frozen screen for an unknown period of time. > Perhaps a progress bar would help. > > Another example is when adding parents to a person or spouse in the family > view. Upon clicking "OK", the "OK" button depresses and the screen freezes > for an unknown period of time. I can move around the "Choose Parents" dialog > and 'erase' the family view beneath it. What would it take to get a progress > bar here? > > I really appreciate the "Find duplicate people" feature. That pops up a > dialog with a progress bar while it runs. > > Just some food-for-thought. > > ~Brian |
From: Eero T. <eer...@ne...> - 2005-08-07 20:58:26
|
Hi, On Wednesday 03 August 2005 16:11, Alex Roitman wrote: > > One example is the "check and repair database". Selecting that menu > > entry provides no feedback - just a frozen screen for an unknown period > > of time. Perhaps a progress bar would help. > > > > Another example is when adding parents to a person or spouse in the > > family view. Upon clicking "OK", the "OK" button depresses and the > > screen freezes for an unknown period of time. I can move around the > > "Choose Parents" dialog and 'erase' the family view beneath it. What > > would it take to get a progress bar here? > > This makes perfect sense. We should add it in the due course. > If you could please file a bug report here: > http://sourceforge.net/tracker/?group_id=25770&atid=385137 > it would insure that we will not forget this. I've had a suggestion about a progress API for the reports in the Wiki. At least in my statistics chart report that would be pretty useful if all of the charts are generated for a database containing thousands of persons. - Eero |
From: Don A. <don...@co...> - 2005-08-07 21:34:32
|
Eero, We have already implemented this. You can find the ProgressMeter class in the Utils.py file. All tools (but not necessarily reports) have been upgraded to support this in 2.0.6. Don On Mon, 2005-08-08 at 00:14 +0300, Eero Tamminen wrote: > Hi, > > On Wednesday 03 August 2005 16:11, Alex Roitman wrote: > > > One example is the "check and repair database". Selecting that menu > > > entry provides no feedback - just a frozen screen for an unknown period > > > of time. Perhaps a progress bar would help. > > > > > > Another example is when adding parents to a person or spouse in the > > > family view. Upon clicking "OK", the "OK" button depresses and the > > > screen freezes for an unknown period of time. I can move around the > > > "Choose Parents" dialog and 'erase' the family view beneath it. What > > > would it take to get a progress bar here? > > > > This makes perfect sense. We should add it in the due course. > > If you could please file a bug report here: > > http://sourceforge.net/tracker/?group_id=25770&atid=385137 > > it would insure that we will not forget this. > > I've had a suggestion about a progress API for the reports in the Wiki. > At least in my statistics chart report that would be pretty useful if all of > the charts are generated for a database containing thousands of persons. > > > - Eero > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Don Allingham <don...@co...> |