From: Doug B. <dou...@gm...> - 2009-01-30 03:08:14
|
I notice that src/Relationship.py looks like it has support to describe in-laws, but in trunk I see that I am not related to my father-in-law in the status bar, nor in the Relationship Calculator Tool. Is that a bug, or by design? I didn't see in the wiki docs any mention of in-laws, and don't remember if this was mentioned when Benny enhanced the relcalc this past year. -Doug |
From: Brian M. <br...@gr...> - 2009-01-30 04:26:15
|
Doug, > I notice that src/Relationship.py looks like it has support > to describe > in-laws, but in trunk I see that I am not related to my > father-in-law in the > status bar, nor in the Relationship Calculator Tool. Is > that a bug, or by > design? I didn't see in the wiki docs any mention of > in-laws, and don't > remember if this was mentioned when Benny enhanced the > relcalc this past > year. It isn't a bug. Some facilities have been added to begin supporting "in-law" relationships, but nobody has gone so far as to make the relationship calculator support it. There are two reasons for this: 1) Nobody has taken the time to implement it. 2) It is presumed to be processor intensive to calculate marriage relationships between two arbitrary people. Checking all ancestors and descendants is one thing, but if you add in marriage relationships, the number of permutations could grow quickly. I don't know of any research to get tangible numbers on how much processing it actually takes. ~Brian |
From: Benny M. <ben...@gm...> - 2009-01-30 09:31:37
|
2009/1/30 Doug Blank <dou...@gm...> > I notice that src/Relationship.py looks like it has support to describe > in-laws, but in trunk I see that I am not related to my father-in-law in the > status bar, nor in the Relationship Calculator Tool. Is that a bug, or by > design? I didn't see in the wiki docs any mention of in-laws, and don't > remember if this was mentioned when Benny enhanced the relcalc this past > year. Only the quick report shows inlaws i believe, as you wait anyway for this specific person's relation to the home person to come up. Performance reasons are at the basis for not showing it elsewhere. I don't have hard data that it is much less performant, but for inlaw you have at least 4 (can be much more in multiple marriages) possibilities to scan, otherwise only one. Benny > > > -Doug > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Jérôme <rom...@ya...> - 2009-01-30 11:25:52
|
Note, rel_de.py uses a custom code related to inlaw. Should be added on main relationships.py ? if degree == 0 and removed < 0: # for descendants the "in-law" logic is reversed (in_law_a, in_law_b) = (in_law_b, in_law_a) Maybe rel_fr has the same problem with HALF_SIB : need an invert process for displaying correct value ! http://www.gramps-project.org/bugs/view.php?id=2380 Benny Malengier a écrit : > > > 2009/1/30 Doug Blank <dou...@gm... <mailto:dou...@gm...>> > > I notice that src/Relationship.py looks like it has support to > describe in-laws, but in trunk I see that I am not related to my > father-in-law in the status bar, nor in the Relationship Calculator > Tool. Is that a bug, or by design? I didn't see in the wiki docs any > mention of in-laws, and don't remember if this was mentioned when > Benny enhanced the relcalc this past year. > > > Only the quick report shows inlaws i believe, as you wait anyway for > this specific person's relation to the home person to come up. > Performance reasons are at the basis for not showing it elsewhere. I > don't have hard data that it is much less performant, but for inlaw you > have at least 4 (can be much more in multiple marriages) possibilities > to scan, otherwise only one. > > Benny > > > > > -Doug > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Benny M. <ben...@gm...> - 2009-01-30 12:27:47
|
2009/1/30 Jérôme <rom...@ya...> > Note, rel_de.py uses a custom code related to inlaw. > Should be added on main relationships.py ? feel free to do that. You could ask help of the rel_de developer . Benny > > > if degree == 0 and removed < 0: > # for descendants the "in-law" logic is reversed > (in_law_a, in_law_b) = (in_law_b, in_law_a) > > > Maybe rel_fr has the same problem with HALF_SIB : > need an invert process for displaying correct value ! > http://www.gramps-project.org/bugs/view.php?id=2380 > > > > Benny Malengier a écrit : > >> >> >> 2009/1/30 Doug Blank <dou...@gm... <mailto:dou...@gm...>> >> >> >> I notice that src/Relationship.py looks like it has support to >> describe in-laws, but in trunk I see that I am not related to my >> father-in-law in the status bar, nor in the Relationship Calculator >> Tool. Is that a bug, or by design? I didn't see in the wiki docs any >> mention of in-laws, and don't remember if this was mentioned when >> Benny enhanced the relcalc this past year. >> >> >> Only the quick report shows inlaws i believe, as you wait anyway for this >> specific person's relation to the home person to come up. >> Performance reasons are at the basis for not showing it elsewhere. I don't >> have hard data that it is much less performant, but for inlaw you have at >> least 4 (can be much more in multiple marriages) possibilities to scan, >> otherwise only one. >> >> Benny >> >> >> >> -Doug >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> <mailto:Gra...@li...> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > |
From: Doug B. <dou...@gm...> - 2009-01-30 12:36:26
|
On Fri, Jan 30, 2009 at 4:31 AM, Benny Malengier <ben...@gm...>wrote: > > > 2009/1/30 Doug Blank <dou...@gm...> > >> I notice that src/Relationship.py looks like it has support to describe >> in-laws, but in trunk I see that I am not related to my father-in-law in the >> status bar, nor in the Relationship Calculator Tool. Is that a bug, or by >> design? I didn't see in the wiki docs any mention of in-laws, and don't >> remember if this was mentioned when Benny enhanced the relcalc this past >> year. > > > Only the quick report shows inlaws i believe, as you wait anyway for this > specific person's relation to the home person to come up. > Performance reasons are at the basis for not showing it elsewhere. I don't > have hard data that it is much less performant, but for inlaw you have at > least 4 (can be much more in multiple marriages) possibilities to scan, > otherwise only one. > > Benny > > Great, thanks for the pointer. Is that code that could be put in the calculator? I'm looking for a way to make a "deep relationship finder" (find any possible relationship) without having to do it by hand, or copying that code. Or is it necessarily stand-alone? -Doug > > >> >> -Doug >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > |
From: Benny M. <ben...@gm...> - 2009-01-30 13:10:25
|
2009/1/30 Doug Blank <dou...@gm...> > > > On Fri, Jan 30, 2009 at 4:31 AM, Benny Malengier < > ben...@gm...> wrote: > >> >> >> 2009/1/30 Doug Blank <dou...@gm...> >> >>> I notice that src/Relationship.py looks like it has support to describe >>> in-laws, but in trunk I see that I am not related to my father-in-law in the >>> status bar, nor in the Relationship Calculator Tool. Is that a bug, or by >>> design? I didn't see in the wiki docs any mention of in-laws, and don't >>> remember if this was mentioned when Benny enhanced the relcalc this past >>> year. >> >> >> Only the quick report shows inlaws i believe, as you wait anyway for this >> specific person's relation to the home person to come up. >> Performance reasons are at the basis for not showing it elsewhere. I don't >> have hard data that it is much less performant, but for inlaw you have at >> least 4 (can be much more in multiple marriages) possibilities to scan, >> otherwise only one. >> >> Benny >> >> > > Great, thanks for the pointer. Is that code that could be put in the > calculator? I'm looking for a way to make a "deep relationship finder" (find > any possible relationship) without having to do it by hand, or copying that > code. Or is it necessarily stand-alone? > I'm not following. The code is fully reusable with some parameters. Relationship calc, quickreport and status bar all call the same function. Benny > > -Doug > > >> >> >>> >>> -Doug >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by: >>> SourcForge Community >>> SourceForge wants to tell your story. >>> http://p.sf.net/sfu/sf-spreadtheword >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >> > |
From: Doug B. <dou...@gm...> - 2009-01-30 13:49:23
|
On Fri, Jan 30, 2009 at 8:10 AM, Benny Malengier <ben...@gm...>wrote: > > > 2009/1/30 Doug Blank <dou...@gm...> > >> >> >> On Fri, Jan 30, 2009 at 4:31 AM, Benny Malengier < >> ben...@gm...> wrote: >> >>> >>> >>> 2009/1/30 Doug Blank <dou...@gm...> >>> >>>> I notice that src/Relationship.py looks like it has support to describe >>>> in-laws, but in trunk I see that I am not related to my father-in-law in the >>>> status bar, nor in the Relationship Calculator Tool. Is that a bug, or by >>>> design? I didn't see in the wiki docs any mention of in-laws, and don't >>>> remember if this was mentioned when Benny enhanced the relcalc this past >>>> year. >>> >>> >>> Only the quick report shows inlaws i believe, as you wait anyway for >>> this specific person's relation to the home person to come up. >>> Performance reasons are at the basis for not showing it elsewhere. I >>> don't have hard data that it is much less performant, but for inlaw you have >>> at least 4 (can be much more in multiple marriages) possibilities to scan, >>> otherwise only one. >>> >>> Benny >>> >>> >> >> Great, thanks for the pointer. Is that code that could be put in the >> calculator? I'm looking for a way to make a "deep relationship finder" (find >> any possible relationship) without having to do it by hand, or copying that >> code. Or is it necessarily stand-alone? >> > > I'm not following. The code is fully reusable with some parameters. > Relationship calc, quickreport and status bar all call the same function. > What is the easiest way to find an arbitrary relationship between two people? It looks like the code in the all_relations quick view takes some special processing to search the in-laws? I was wondering if that in-law logic could be put in one function? Also, I note that the "Quick View" is more thorough than the "Relationship Calculator" Tool. I would think that the tool would be at least as thorough as the quick view. The tool uses: rel_strings, common_an = self.relationship.get_all_relationships( self.db, self.person, other_person) What would that change to to get the in-laws? One final question: Does the quick view version find all possible connections between two people (up to the max generation limit)? I'm wondering because I ended up with a group of people in my tree that I can't find how they are related to me. I'm wondering if I can find the link (however weak it might be) between any of them and me through the tools already in GRAMPS, or do I need to do a "deep search" to recursively find the connection? -Doug > > Benny > >> >> -Doug >> >> >>> >>> >>>> >>>> -Doug >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by: >>>> SourcForge Community >>>> SourceForge wants to tell your story. >>>> http://p.sf.net/sfu/sf-spreadtheword >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>>> >>> >> > |
From: Peter L. <pet...@te...> - 2009-01-30 14:26:51
|
> On Fri, Jan 30, 2009 at 8:10 AM, Benny Malengier > > <ben...@gm...>wrote: > > 2009/1/30 Doug Blank <dou...@gm...> > > > >> On Fri, Jan 30, 2009 at 4:31 AM, Benny Malengier < > >> > >> ben...@gm...> wrote: > >>> 2009/1/30 Doug Blank <dou...@gm...> > >>> > >>>> I notice that src/Relationship.py looks like it has support to > >>>> describe in-laws, but in trunk I see that I am not related to my > >>>> father-in-law in the status bar, nor in the Relationship Calculator > >>>> Tool. Is that a bug, or by design? I didn't see in the wiki docs any > >>>> mention of in-laws, and don't remember if this was mentioned when > >>>> Benny enhanced the relcalc this past year. > >>> > >>> Only the quick report shows inlaws i believe, as you wait anyway for > >>> this specific person's relation to the home person to come up. > >>> Performance reasons are at the basis for not showing it elsewhere. I > >>> don't have hard data that it is much less performant, but for inlaw you > >>> have at least 4 (can be much more in multiple marriages) possibilities > >>> to scan, otherwise only one. > >>> > >>> Benny > >> > >> Great, thanks for the pointer. Is that code that could be put in the > >> calculator? I'm looking for a way to make a "deep relationship finder" > >> (find any possible relationship) without having to do it by hand, or > >> copying that code. Or is it necessarily stand-alone? > > > > I'm not following. The code is fully reusable with some parameters. > > Relationship calc, quickreport and status bar all call the same function. > > What is the easiest way to find an arbitrary relationship between two > people? It looks like the code in the all_relations quick view takes some > special processing to search the in-laws? I was wondering if that in-law > logic could be put in one function? > > Also, I note that the "Quick View" is more thorough than the "Relationship > Calculator" Tool. I would think that the tool would be at least as thorough > as the quick view. The tool uses: > > rel_strings, common_an = self.relationship.get_all_relationships( > self.db, self.person, > other_person) > > What would that change to to get the in-laws? > > One final question: Does the quick view version find all possible > connections between two people (up to the max generation limit)? I'm > wondering because I ended up with a group of people in my tree that I can't > find how they are related to me. I'm wondering if I can find the link > (however weak it might be) between any of them and me through the tools > already in GRAMPS, or do I need to do a "deep search" to recursively find > the connection? > Doug If use the "FamilyLine Graph", with myself and the other person as the persons of intrest, to show how we are related. /Peter |
From: Stéphane C. <ste...@gm...> - 2009-01-30 17:09:41
|
>> One final question: Does the quick view version find all possible >> connections between two people (up to the max generation limit)? I'm >> wondering because I ended up with a group of people in my tree that I >> can't >> find how they are related to me. I'm wondering if I can find the link >> (however weak it might be) between any of them and me through the tools >> already in GRAMPS, or do I need to do a "deep search" to recursively find >> the connection? >> > [I'd] use the "FamilyLine Graph", with myself and the other person as the > persons of intrest, to show how we are related. Interesting use of FamilyLines. However, as the author of that graph, I can tell you that technique wont really work. Unless you are lucky -- or the two people happen to share the same last name -- you'll end up with two "mini graphs" instead of one big graph. The FamilyLines graph uses people of interest to figure out some of the last names to keep...the "family lines". And to figure out which people can be discarded. If the two people have different last names, you'd need to also know beforehand the "missing links" in the middle, and add some of those as people of interest. Only then will Family Lines come up with a single graph showing how they're all related. Personally, I'd start with the "Not Related" view to see if everyone in the database is somehow linked. It wont tell you how person A is linked to person B, but at least you'll know if anyone in the database is unlinked. Stéphane |
From: Benny M. <ben...@gm...> - 2009-01-30 19:48:13
|
2009/1/30 Doug Blank <dou...@gm...> > On Fri, Jan 30, 2009 at 8:10 AM, Benny Malengier < > ben...@gm...> wrote: > >> >> >> 2009/1/30 Doug Blank <dou...@gm...> >> >>> >>> >>> On Fri, Jan 30, 2009 at 4:31 AM, Benny Malengier < >>> ben...@gm...> wrote: >>> >>>> >>>> >>>> 2009/1/30 Doug Blank <dou...@gm...> >>>> >>>>> I notice that src/Relationship.py looks like it has support to describe >>>>> in-laws, but in trunk I see that I am not related to my father-in-law in the >>>>> status bar, nor in the Relationship Calculator Tool. Is that a bug, or by >>>>> design? I didn't see in the wiki docs any mention of in-laws, and don't >>>>> remember if this was mentioned when Benny enhanced the relcalc this past >>>>> year. >>>> >>>> >>>> Only the quick report shows inlaws i believe, as you wait anyway for >>>> this specific person's relation to the home person to come up. >>>> Performance reasons are at the basis for not showing it elsewhere. I >>>> don't have hard data that it is much less performant, but for inlaw you have >>>> at least 4 (can be much more in multiple marriages) possibilities to scan, >>>> otherwise only one. >>>> >>>> Benny >>>> >>>> >>> >>> Great, thanks for the pointer. Is that code that could be put in the >>> calculator? I'm looking for a way to make a "deep relationship finder" (find >>> any possible relationship) without having to do it by hand, or copying that >>> code. Or is it necessarily stand-alone? >>> >> >> I'm not following. The code is fully reusable with some parameters. >> Relationship calc, quickreport and status bar all call the same function. >> > > What is the easiest way to find an arbitrary relationship between two > people? It looks like the code in the all_relations quick view takes some > special processing to search the in-laws? I was wondering if that in-law > logic could be put in one function? > ok, I understand now. I believe the get_inlaw function could move to utils, it is more usefull than the usage now. If the rest can be one function, probably. As this quick report was the only place I intended using inlaw relationships, it is not like that now. As always with reports, the way you write to the report is often very connected to the way you run over the data. Splitting these two is not always an easy task. If you want to show inlaw relationships somewhere else, then that would be a good way to start splitting the two things that are done so as to reuse the common part > Also, I note that the "Quick View" is more thorough than the "Relationship > Calculator" Tool. I would think that the tool would be at least as thorough > as the quick view. The tool uses: > > rel_strings, common_an = self.relationship.get_all_relationships( > self.db, self.person, > other_person) > Yes, wel, not doing in-law relationships allows you to cache all the data from the person that does not change (the active/home person). Also doing in-laws makes this 1/more difficult, 2/taking up more memory. This can be a real problem on slower computers ! Especially as the home person is normally a person with a large tree. > > What would that change to to get the in-laws? > Take over the logic from the the all relations quick report. But as the relcalc tool must be sufficiently fast, some cache of the active person and it's partners would then be usefull. This now happens with self.storemap in get_relationship_distance_new in Relationship.py It is important for the speed of the relcalc tool (fixed active person), as well as the message in the status bar (fixed home person). > > One final question: Does the quick view version find all possible > connections between two people (up to the max generation limit)? I'm > wondering because I ended up with a group of people in my tree that I can't > find how they are related to me. I'm wondering if I can find the link > (however weak it might be) between any of them and me through the tools > already in GRAMPS, or do I need to do a "deep search" to recursively find > the connection? > So the quick report does not give a relation. The search goes to ancestors looking for common persons. So you must image trees going up in the branches. Hence it helps to start as low as possible in the tree. You can think easily of connections that won't be found: parents of spouses of uncles for example have no relation to you according to the relationship calculators, if you do not start specifically with the spouse. This is obviously correct, as you only have a relationship to these people AFTER the marriage. So you will find the relationship starting from one of their children (barring remarriages, don't remember now how deep stephchildren search goes). Hence a trick is to run a descendant report on the branch you have no connection with, then run the all relationships tool on all descendants in your branch and all descendants in that branch, so that inlaw connections between the lowest roots are found. Benny > > > -Doug > > >> >> Benny >> >>> >>> -Doug >>> >>> >>>> >>>> >>>>> >>>>> -Doug >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> This SF.net email is sponsored by: >>>>> SourcForge Community >>>>> SourceForge wants to tell your story. >>>>> http://p.sf.net/sfu/sf-spreadtheword >>>>> _______________________________________________ >>>>> Gramps-devel mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>> >>>>> >>>> >>> >> > |
From: Brian M. <br...@gr...> - 2009-02-01 04:54:38
|
> ok, I understand now. > I believe the get_inlaw function could move to utils, it is > more usefull > than the usage now. > If the rest can be one function, probably. As this quick > report was the only > place I intended using inlaw relationships, it is not like > that now. I wonder if it would make sense to put it in the relationship module since it deals with calculating relationships. Just thinking out loud. I feel like the "utils" module is turning into a dumping ground for code. But in some situations there is just no better place. ~Brian |
From: Benny M. <ben...@gm...> - 2009-02-01 10:40:41
|
2009/2/1 Brian Matherly <br...@gr...> > > ok, I understand now. > > I believe the get_inlaw function could move to utils, it is > > more usefull > > than the usage now. > > If the rest can be one function, probably. As this quick > > report was the only > > place I intended using inlaw relationships, it is not like > > that now. > > I wonder if it would make sense to put it in the relationship module since > it deals with calculating relationships. Just thinking out loud. I feel like > the "utils" module is turning into a dumping ground for code. But in some > situations there is just no better place. Yes, you are right. It is not because a function is used by other modules it should be part of Utils. This function better moves to Relationship.py as a function. But it does not seem Doug wants to reuse on it at the moment. Benny > > > ~Brian > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2009-02-01 13:30:59
|
On Sun, Feb 1, 2009 at 5:40 AM, Benny Malengier <ben...@gm...>wrote: > > > 2009/2/1 Brian Matherly <br...@gr...> > >> > ok, I understand now. >> > I believe the get_inlaw function could move to utils, it is >> > more usefull >> > than the usage now. >> > If the rest can be one function, probably. As this quick >> > report was the only >> > place I intended using inlaw relationships, it is not like >> > that now. >> >> I wonder if it would make sense to put it in the relationship module since >> it deals with calculating relationships. Just thinking out loud. I feel like >> the "utils" module is turning into a dumping ground for code. But in some >> situations there is just no better place. > > > Yes, you are right. It is not because a function is used by other modules > it should be part of Utils. This function better moves to Relationship.py as > a function. > But it does not seem Doug wants to reuse on it at the moment. > No big hurry. But, if a more comprehensive named-relationship describer function existed, then we could also use it in a new Deep Connections tool. In that way, it would describe the connection, too, and be one step closer of being a replacement for the Relationship Calc tool (if we wished). But, I think that is looking more and more like 3.2... -Doug > > Benny > >> >> >> ~Brian >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Doug B. <dou...@gm...> - 2009-01-31 03:11:00
|
On Fri, Jan 30, 2009 at 2:48 PM, Benny Malengier <ben...@gm...>wrote: > > > 2009/1/30 Doug Blank <dou...@gm...> > >> On Fri, Jan 30, 2009 at 8:10 AM, Benny Malengier < >> ben...@gm...> wrote: >> >>> >>> >>> 2009/1/30 Doug Blank <dou...@gm...> >>> >>>> >>>> >>>> On Fri, Jan 30, 2009 at 4:31 AM, Benny Malengier < >>>> ben...@gm...> wrote: >>>> >>>>> >>>>> >>>>> 2009/1/30 Doug Blank <dou...@gm...> >>>>> >>>>>> I notice that src/Relationship.py looks like it has support to >>>>>> describe in-laws, but in trunk I see that I am not related to my >>>>>> father-in-law in the status bar, nor in the Relationship Calculator Tool. Is >>>>>> that a bug, or by design? I didn't see in the wiki docs any mention of >>>>>> in-laws, and don't remember if this was mentioned when Benny enhanced the >>>>>> relcalc this past year. >>>>> >>>>> >>>>> Only the quick report shows inlaws i believe, as you wait anyway for >>>>> this specific person's relation to the home person to come up. >>>>> Performance reasons are at the basis for not showing it elsewhere. I >>>>> don't have hard data that it is much less performant, but for inlaw you have >>>>> at least 4 (can be much more in multiple marriages) possibilities to scan, >>>>> otherwise only one. >>>>> >>>>> Benny >>>>> >>>>> >>>> >>>> Great, thanks for the pointer. Is that code that could be put in the >>>> calculator? I'm looking for a way to make a "deep relationship finder" (find >>>> any possible relationship) without having to do it by hand, or copying that >>>> code. Or is it necessarily stand-alone? >>>> >>> >>> I'm not following. The code is fully reusable with some parameters. >>> Relationship calc, quickreport and status bar all call the same function. >>> >> >> What is the easiest way to find an arbitrary relationship between two >> people? It looks like the code in the all_relations quick view takes some >> special processing to search the in-laws? I was wondering if that in-law >> logic could be put in one function? >> > > ok, I understand now. > I believe the get_inlaw function could move to utils, it is more usefull > than the usage now. > If the rest can be one function, probably. As this quick report was the > only place I intended using inlaw relationships, it is not like that now. > As always with reports, the way you write to the report is often very > connected to the way you run over the data. Splitting these two is not > always an easy task. If you want to show inlaw relationships somewhere else, > then that would be a good way to start splitting the two things that are > done so as to reuse the common part > > >> Also, I note that the "Quick View" is more thorough than the "Relationship >> Calculator" Tool. I would think that the tool would be at least as thorough >> as the quick view. The tool uses: >> >> rel_strings, common_an = self.relationship.get_all_relationships( >> self.db, self.person, >> other_person) >> > > Yes, wel, not doing in-law relationships allows you to cache all the data > from the person that does not change (the active/home person). Also doing > in-laws makes this 1/more difficult, 2/taking up more memory. This can be a > real problem on slower computers ! Especially as the home person is normally > a person with a large tree. > > >> >> What would that change to to get the in-laws? >> > > Take over the logic from the the all relations quick report. But as the > relcalc tool must be sufficiently fast, some cache of the active person and > it's partners would then be usefull. > This now happens with self.storemap in get_relationship_distance_new in > Relationship.py > It is important for the speed of the relcalc tool (fixed active person), as > well as the message in the status bar (fixed home person). > > >> >> One final question: Does the quick view version find all possible >> connections between two people (up to the max generation limit)? I'm >> wondering because I ended up with a group of people in my tree that I can't >> find how they are related to me. I'm wondering if I can find the link >> (however weak it might be) between any of them and me through the tools >> already in GRAMPS, or do I need to do a "deep search" to recursively find >> the connection? >> > > So the quick report does not give a relation. The search goes to ancestors > looking for common persons. So you must image trees going up in the > branches. Hence it helps to start as low as possible in the tree. > You can think easily of connections that won't be found: parents of spouses > of uncles for example have no relation to you according to the relationship > calculators, if you do not start specifically with the spouse. This is > obviously correct, as you only have a relationship to these people AFTER the > marriage. So you will find the relationship starting from one of their > children (barring remarriages, don't remember now how deep stephchildren > search goes). > Hence a trick is to run a descendant report on the branch you have no > connection with, then run the all relationships tool on all descendants in > your branch and all descendants in that branch, so that inlaw connections > between the lowest roots are found. > Ok, great information in this thread! Thanks all. So, it sounds like we can summarize this as follows: 1) The "Relationship Calculator" Tool gives the same information as the status line. It is quick, and doesn't show in-law relationships. 2) The Quick View "Relation to Home Person" finds the closest common relative between two people, does take into account some in-laws, and is still very quick. 3) The Family Lines show some of these connections, but not all. 4) The Disconnected Person Filter will show you only people that aren't connected to anyone else... it doesn't show people that aren't connected to an arbitrary person So, it turns out that I wasn't really interested in the relationship between two people, I was more interested in how/if they were connected. I also didn't mind if GRAMPS wanted to chug through the data for awhile, as it would save me time from doing it by hand. So, it sounds like a new use. I'm not convinced that we need yet another variation, but I've added an experimental, slow, thorough gramplet called, for the moment, Deep Connections. You can see a picture here: http://gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Gramplets#Deep_Connections_Gramplet Perhaps this should be a 3rd-party plugin? Let me know if you find this useful, and different enough to include in GRAMPS. -Doug > > Benny > >> >> >> -Doug >> >> >>> >>> Benny >>> >>>> >>>> -Doug >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> -Doug >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> This SF.net email is sponsored by: >>>>>> SourcForge Community >>>>>> SourceForge wants to tell your story. >>>>>> http://p.sf.net/sfu/sf-spreadtheword >>>>>> _______________________________________________ >>>>>> Gramps-devel mailing list >>>>>> Gra...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>> >>>>>> >>>>> >>>> >>> >> > |
From: Benny M. <ben...@gm...> - 2009-01-31 08:00:25
|
2009/1/31 Doug Blank <dou...@gm...> > > Ok, great information in this thread! Thanks all. > > So, it sounds like we can summarize this as follows: > > 1) The "Relationship Calculator" Tool gives the same information as the > status line. It is quick, and doesn't show in-law relationships. > > 2) The Quick View "Relation to Home Person" finds the closest common > relative between two people, does take into account some in-laws, and is > still very quick. > > 3) The Family Lines show some of these connections, but not all. > > 4) The Disconnected Person Filter will show you only people that aren't > connected to anyone else... it doesn't show people that aren't connected to > an arbitrary person > > So, it turns out that I wasn't really interested in the relationship > between two people, I was more interested in how/if they were connected. I > also didn't mind if GRAMPS wanted to chug through the data for awhile, as it > would save me time from doing it by hand. So, it sounds like a new use. I'm > not convinced that we need yet another variation, but I've added an > experimental, slow, thorough gramplet called, for the moment, Deep > Connections. You can see a picture here: > > > http://gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Gramplets#Deep_Connections_Gramplet > > Perhaps this should be a 3rd-party plugin? Let me know if you find this > useful, and different enough to include in GRAMPS. > I have two remarks 1/ not everything should be a gramplet now. I guess you did this because of the threading possibilities. This form factor looks more suited to me as a tool with a start, pauze and continue button. 2/this can use up a lot CPU cycles. We must be very carefull that normal users do not think GRAMPS is bad because it is slow/unresponsive, while the reason behind it is that they loaded to many intensive gramplets. As we allow all the gramplets, the user will think it should not matter he puts 15 of them on his 1Ghz laptop. It short, _we_ have to make sure GRAMPS works good also if the user does dumb things. In light of the above I would do the following recommendation: 1/if this is a gramplet, then or a 3th party plugin. That would be a pity though, as many people would benefit from this functionality or an official GRAMPLET that does not respond to user changes but has a start button to start it searching. Then it would be ok in GRAMPS officially, as the user understands why things suddenly slow down. Perhaps it is like that the pause changing in start, as there is no code I can't know. (nomally there is one button, start, after click it becomes pause, after click it becomes continue, on change of active/home person it becomes start again) 2/as a tool, it can go into GRAMPS. A user specifically calls a tool, so he does not mind slower functioning (if he can interrupt) 3/We should define some 'best practices' around the gramplets: * there are too many gramplets, we must help the user find the one he needs. So the add a gramplet should perhaps be subdivided in categories: the most usefull are shown, then at the bottom submenu for the other gramplets: menu for 3th party installed ones (important to get feedback on upgrade of gramps base!!), menu for advanced ones (session, python), ... * should we not limit how many gramplets can be added? * clearly one can now create quickly good looking gramplets with a unified structure to do things we used to do with the tools. It is a pity if this means all is now written as a Gramplet instead of a Tool. Perhaps a general tool can be made that essentially runs a gramplet in it's window (but is called from the tools menu). Is this possible? It would be a new way of writing a tool. Obviously, such a tool should not be available also as a Gramplet. Benny > > -Doug > > >> >> Benny >> >>> >>> >>> -Doug >>> >>> >>>> >>>> Benny >>>> >>>>> >>>>> -Doug >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> -Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> This SF.net email is sponsored by: >>>>>>> SourcForge Community >>>>>>> SourceForge wants to tell your story. >>>>>>> http://p.sf.net/sfu/sf-spreadtheword >>>>>>> _______________________________________________ >>>>>>> Gramps-devel mailing list >>>>>>> Gra...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
From: Doug B. <dou...@gm...> - 2009-01-31 13:27:39
|
On Sat, Jan 31, 2009 at 3:00 AM, Benny Malengier <ben...@gm...>wrote: > > > 2009/1/31 Doug Blank <dou...@gm...> > >> >> Ok, great information in this thread! Thanks all. >> >> So, it sounds like we can summarize this as follows: >> >> 1) The "Relationship Calculator" Tool gives the same information as the >> status line. It is quick, and doesn't show in-law relationships. >> >> 2) The Quick View "Relation to Home Person" finds the closest common >> relative between two people, does take into account some in-laws, and is >> still very quick. >> >> 3) The Family Lines show some of these connections, but not all. >> >> 4) The Disconnected Person Filter will show you only people that aren't >> connected to anyone else... it doesn't show people that aren't connected to >> an arbitrary person >> >> So, it turns out that I wasn't really interested in the relationship >> between two people, I was more interested in how/if they were connected. I >> also didn't mind if GRAMPS wanted to chug through the data for awhile, as it >> would save me time from doing it by hand. So, it sounds like a new use. I'm >> not convinced that we need yet another variation, but I've added an >> experimental, slow, thorough gramplet called, for the moment, Deep >> Connections. You can see a picture here: >> >> >> http://gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Gramplets#Deep_Connections_Gramplet >> >> Perhaps this should be a 3rd-party plugin? Let me know if you find this >> useful, and different enough to include in GRAMPS. >> > > I have two remarks > > 1/ not everything should be a gramplet now. I guess you did this because > of the threading possibilities. This form factor looks more suited to me as > a tool with a start, pauze and continue button. > > 2/this can use up a lot CPU cycles. We must be very carefull that normal > users do not think GRAMPS is bad because it is slow/unresponsive, while the > reason behind it is that they loaded to many intensive gramplets. As we > allow all the gramplets, the user will think it should not matter he puts 15 > of them on his 1Ghz laptop. > It short, _we_ have to make sure GRAMPS works good also if the user does > dumb things. > > In light of the above I would do the following recommendation: > 1/if this is a gramplet, then or a 3th party plugin. That would be a pity > though, as many people would benefit from this functionality or an official > GRAMPLET that does not respond to user changes but has a start button to > start it searching. Then it would be ok in GRAMPS officially, as the user > understands why things suddenly slow down. Perhaps it is like that the pause > changing in start, as there is no code I can't know. (nomally there is one > button, start, after click it becomes pause, after click it becomes > continue, on change of active/home person it becomes start again) > 2/as a tool, it can go into GRAMPS. A user specifically calls a tool, so he > does not mind slower functioning (if he can interrupt) > 3/We should define some 'best practices' around the gramplets: > * there are too many gramplets, we must help the user find the one he > needs. So the add a gramplet should perhaps be subdivided in categories: the > most usefull are shown, then at the bottom submenu for the other gramplets: > menu for 3th party installed ones (important to get feedback on upgrade of > gramps base!!), menu for advanced ones (session, python), ... > * should we not limit how many gramplets can be added? > * clearly one can now create quickly good looking gramplets with a unified > structure to do things we used to do with the tools. It is a pity if this > means all is now written as a Gramplet instead of a Tool. Perhaps a general > tool can be made that essentially runs a gramplet in it's window (but is > called from the tools menu). Is this possible? It would be a new way of > writing a tool. Obviously, such a tool should not be available also as a > Gramplet. > Benny, I agree with everything you say. Here is a short term solution for 3.1: 1) Add a path to a gramplet's name: "Python Gramplet" becomes "System/Python Gramplet" (or something) which gets turned into a series of pulldown menus: System Python Gramplet Data Entry Relationships Misc We can see how a particular set of groupings work and adjust. I prefer functional categories, with alphabetical inside those. 2) Write a tool frame for holding a gramplet. That should be trivial. I agree, it should be a gramplet OR a tool, not both. As to the number of Gramplets, I'm reminded of plugins for projects like Wordpress. There must be hundreds, and even plugins that manage plugins. I agree that the "paradox of choice" can leave users overwhelmed. But I see a vast future of functionality that we are just now beginning to tap... Thanks for the feedback! -Doug > > Benny > > >> >> -Doug >> >> >>> >>> Benny >>> >>>> >>>> >>>> -Doug >>>> >>>> >>>>> >>>>> Benny >>>>> >>>>>> >>>>>> -Doug >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -Doug >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> This SF.net email is sponsored by: >>>>>>>> SourcForge Community >>>>>>>> SourceForge wants to tell your story. >>>>>>>> http://p.sf.net/sfu/sf-spreadtheword >>>>>>>> _______________________________________________ >>>>>>>> Gramps-devel mailing list >>>>>>>> Gra...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
From: Brian M. <br...@gr...> - 2009-01-31 14:44:55
|
Doug, > Benny, > > I agree with everything you say. Here is a short term > solution for 3.1: > > 1) Add a path to a gramplet's name: "Python > Gramplet" becomes "System/Python > Gramplet" (or something) which gets turned into a > series of pulldown menus: Hack alert! Let's build a clear interface with an enumerated list of possible categories that the gramplet author can choose from. The category type should get passed into the register function. > System > Python Gramplet > Data Entry > Relationships > Misc > > We can see how a particular set of groupings work and > adjust. I prefer > functional categories, with alphabetical inside those. > > 2) Write a tool frame for holding a gramplet. That should > be trivial. I > agree, it should be a gramplet OR a tool, not both. Seriously? We can already undock gramplets and have them float around. Why must there be more than one way to do things. If something should be a tool, make it a tool. If something should be a gramplet, make it a gramplet. There are already examples of redundancy. We currently have a "Descendants Browser" tool and a "Descendant" Gramplet which, as far as I can tell, are exactly the same. Between the quick views, gramplets, and tools, I feel like Gramps is starting to look like a hacked together application with no common user paradigm. This is why I would like to see us take some of the quickviews and tools and turn them into Gramplets. > As to the number of Gramplets, I'm reminded of plugins > for projects like > Wordpress. There must be hundreds, and even plugins that > manage plugins. I > agree that the "paradox of choice" can leave > users overwhelmed. But I see a > vast future of functionality that we are just now beginning > to tap... A clever idea here would be allow users to enable and disable plugins from the plugin status window. I can think of about two dozen that I would disable. ~Brian |
From: Doug B. <dou...@gm...> - 2009-01-31 15:16:45
|
On Sat, Jan 31, 2009 at 9:44 AM, Brian Matherly <br...@gr...>wrote: > Doug, > > > Benny, > > > > I agree with everything you say. Here is a short term > > solution for 3.1: > > > > 1) Add a path to a gramplet's name: "Python > > Gramplet" becomes "System/Python > > Gramplet" (or something) which gets turned into a > > series of pulldown menus: > > Hack alert! Let's build a clear interface with an enumerated list of > possible categories that the gramplet author can choose from. The category > type should get passed into the register function. > Just a difference of paths to getting where we want to be. My suggestion is to make it easy to explore these categorizations before we settle on what they should be. It seems to work for filenames and directories... > > > System > > Python Gramplet > > Data Entry > > Relationships > > Misc > > > > We can see how a particular set of groupings work and > > adjust. I prefer > > functional categories, with alphabetical inside those. > > > > 2) Write a tool frame for holding a gramplet. That should > > be trivial. I > > agree, it should be a gramplet OR a tool, not both. > > Seriously? We can already undock gramplets and have them float around. Why > must there be more than one way to do things. > > If something should be a tool, make it a tool. If something should be a > gramplet, make it a gramplet. > > There are already examples of redundancy. We currently have a "Descendants > Browser" tool and a "Descendant" Gramplet which, as far as I can tell, are > exactly the same. > > Between the quick views, gramplets, and tools, I feel like Gramps is > starting to look like a hacked together application with no common user > paradigm. This is why I would like to see us take some of the quickviews and > tools and turn them into Gramplets. > Brian, I think you are reading this the wrong way. What Benny and I are suggesting is to reuse the Gramplet *architecture* for Tools. That's all. Then the things that are best seen as tools can be easily moved there. Once it is a tool, it would look and act like a tool. GRAMPS is changing and evolving, and it has a ways to go to be a perfect UI, but that will always be true. You don't sound very happy about the state of GRAMPS... > > As to the number of Gramplets, I'm reminded of plugins > > for projects like > > Wordpress. There must be hundreds, and even plugins that > > manage plugins. I > > agree that the "paradox of choice" can leave > > users overwhelmed. But I see a > > vast future of functionality that we are just now beginning > > to tap... > > A clever idea here would be allow users to enable and disable plugins from > the plugin status window. I can think of about two dozen that I would > disable. > I suspect that we all have our favorite plugins. I'd be hesitant to hide them too much, as I'm constantly discovering new uses for those that I've seldom used before. I'm constantly surprised at what I find in GRAMPS. -Doug > ~Brian > |
From: Brian M. <br...@gr...> - 2009-01-31 16:32:22
|
> GRAMPS is changing and evolving, and it has a ways to go > to be a perfect UI, but that will always be true. > You don't sound very happy about the state of GRAMPS... I am happy with the state of GRAMPS. I'm also very excited about the speed at which it is changing. We have some key developers who are able to crank out an incredible amount of code in a short amount of time. I wish I were one of them. What concerns me is the direction I see the code going. Function and file sizes are growing at an astounding rate. And it isn't good for the community. We have a responsibility to make sure that the code is readable, scalable and maintainable. We have a responsibility to make sure that files do not get to be 3193 lines long (_ReportUtils.py). We have a responsibility to make sure that functions are not 172 lines long (WebCal.py - calendar_build). We have a responsibility to make sure that functions don't take in 9 parameters (WebCal.py - calendar_common). We have a responsibility to make sure that file, class, function and variable names properly describe the abstractions they are representing. We have a responsibility to make sure that abstractions and interfaces are clearly defined and documented so that when other people have to use them they don't have to reverse engineer our code. We need people who can add features and we need people who can enhance the architecture in order to better support the new features. Right now, it looks to be like the feature people are outpacing the architecture people by about 4 to 1. So, while I am happy with the state of Gramps, I am concerned with where it is going and I feel a responsibility to say something. Not that I would ever attempt to mandate this, but in my mind it would be prudent for us to cease all new feature development for 3.1 and all of us focus on refactoring the code. I think we owe it to the community and to the future developers of Gramps. Somebody please respond. ~Brian |
Re: [Gramps-devel] The state,
speed and direction of Gramps (was Inlaws in relationship
calculator?)
From: Reinhard M. <rei...@by...> - 2009-01-31 22:40:59
|
Am Samstag, den 31.01.2009, 08:32 -0800 schrieb Brian Matherly: > We have a responsibility to make sure that the code is readable, > scalable and maintainable. A quick feedback from somebody who just dived into GRAMPS code recently: I find GRAMPS code very readable. Having said that, I agree with what Brian said :-) Thanks, Reinhard -- Reinhard Müller Tel +43 (5577) 89877-0 BYTEWISE Software GmbH Fax +43 (5577) 89877-66 A-6890 Lustenau, Enga 2 http://www.bytewise.at ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Individuelle Datenbanklösungen für GNU/Linux, Windows und Mac OSX: http://www.bytewise.at/leistungen/gnue-indiv.html |
Re: [Gramps-devel] The state,
speed and direction of Gramps (was Inlaws in relationship
calculator?)
From: Don A. <do...@gr...> - 2009-02-01 00:15:01
|
I know its been over a year since I've been active in the project. I am not a professional software developer, but I have been developing python code for quite a few years, and I continue to develop code at work and on other projects. I wholeheartedly agree with Brian on this issue. Code cleanup is, at this point, more important than features. I have a few suggestions on the code cleanup side. 1. I know that a lot of people have a problem with PEP-8. Get over it. It is the best set of guidelines available for Python programmers, written by the best Python programmers in the world. It provides a nice, consistent set of rules that will make your code readable by other members of the project and other python programmers outside the project. The PythonTidy script will help you with PEP-8 formatting compliance. http://pypi.python.org/pypi/PythonTidy/1.11 2. Use "pylint". This is a nice program for grading your code. It checks for PEP-8 compliance, points out possible mistakes that you could be making, and points out places where you should refactor code. If you use Eclipse as your IDE, pylint can be set up to do dynamic checking of your code as you edit. I set a guideline for my code to require a pylint score of 9.5 or better. 3. Learn to code like a "Pythonista". Python has some significant differences from other languages, and it is too easy to try to code C, C++, or Java in Python. This usually produces far suboptimal code for Python. Here are a few good articles: http://www.python.org/dev/peps/pep-0008/ http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html http://dirtsimple.org/2004/12/python-is-not-java.html Maybe, as I have time, I write a few messages about how to code python in python, instead of C++ or Java in python. Don On Sat, 2009-01-31 at 08:32 -0800, Brian Matherly wrote: > > GRAMPS is changing and evolving, and it has a ways to go > > to be a perfect UI, but that will always be true. > > You don't sound very happy about the state of GRAMPS... > > I am happy with the state of GRAMPS. I'm also very excited about the speed at which it is changing. We have some key developers who are able to crank out an incredible amount of code in a short amount of time. I wish I were one of them. > > What concerns me is the direction I see the code going. Function and file sizes are growing at an astounding rate. And it isn't good for the community. > > We have a responsibility to make sure that the code is readable, scalable and maintainable. > > We have a responsibility to make sure that files do not get to be 3193 lines long (_ReportUtils.py). > > We have a responsibility to make sure that functions are not 172 lines long (WebCal.py - calendar_build). > > We have a responsibility to make sure that functions don't take in 9 parameters (WebCal.py - calendar_common). > > We have a responsibility to make sure that file, class, function and variable names properly describe the abstractions they are representing. > > We have a responsibility to make sure that abstractions and interfaces are clearly defined and documented so that when other people have to use them they don't have to reverse engineer our code. > > We need people who can add features and we need people who can enhance the architecture in order to better support the new features. Right now, it looks to be like the feature people are outpacing the architecture people by about 4 to 1. > > So, while I am happy with the state of Gramps, I am concerned with where it is going and I feel a responsibility to say something. > > Not that I would ever attempt to mandate this, but in my mind it would be prudent for us to cease all new feature development for 3.1 and all of us focus on refactoring the code. I think we owe it to the community and to the future developers of Gramps. > > Somebody please respond. > > ~Brian > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: [Gramps-devel] The state,
speed and direction of Gramps (was Inlaws in relationship
calculator?)
From: Doug B. <dou...@gm...> - 2009-01-31 16:53:08
|
On Sat, Jan 31, 2009 at 11:32 AM, Brian Matherly <br...@gr...>wrote: > > GRAMPS is changing and evolving, and it has a ways to go > > to be a perfect UI, but that will always be true. > > You don't sound very happy about the state of GRAMPS... > > I am happy with the state of GRAMPS. I'm also very excited about the speed > at which it is changing. We have some key developers who are able to crank > out an incredible amount of code in a short amount of time. I wish I were > one of them. > > What concerns me is the direction I see the code going. Function and file > sizes are growing at an astounding rate. And it isn't good for the > community. > > We have a responsibility to make sure that the code is readable, scalable > and maintainable. > > We have a responsibility to make sure that files do not get to be 3193 > lines long (_ReportUtils.py). > > We have a responsibility to make sure that functions are not 172 lines long > (WebCal.py - calendar_build). > > We have a responsibility to make sure that functions don't take in 9 > parameters (WebCal.py - calendar_common). > > We have a responsibility to make sure that file, class, function and > variable names properly describe the abstractions they are representing. > > We have a responsibility to make sure that abstractions and interfaces are > clearly defined and documented so that when other people have to use them > they don't have to reverse engineer our code. > > We need people who can add features and we need people who can enhance the > architecture in order to better support the new features. Right now, it > looks to be like the feature people are outpacing the architecture people by > about 4 to 1. > > So, while I am happy with the state of Gramps, I am concerned with where it > is going and I feel a responsibility to say something. > > Not that I would ever attempt to mandate this, but in my mind it would be > prudent for us to cease all new feature development for 3.1 and all of us > focus on refactoring the code. I think we owe it to the community and to the > future developers of Gramps. > > Somebody please respond. > I'll say it first "I agree with Brian" :) In my experience with open source (and life) there are periods of wild growth and exploration, followed by trimming, and re-organization. I think we are finishing a period of wild growth (3.1). Next we can stand back and see what works, then regroup, cut, rewrite, and prune (3.2). We need both stages to be a healthy, living project. I think it is time for a mandate though: give us a week (or so) to add or remove what we personally have as goals to get into 3.1, then for the rest of Feb, let's all work together to add that spit polish and only debug/fix. Personally, I'm done, but there might be others in the middle of something. I've started my personal priority list on my wiki page: http://www.gramps-project.org/wiki/index.php?title=Category:User Not that I can do all that is on my priority list... but those are the ones I'd like to see done. -Doug > > ~Brian > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Brian M. <br...@gr...> - 2009-02-01 22:39:50
|
> I think it is time for a mandate though: give us a week (or > so) to add or > remove what we personally have as goals to get into 3.1, > then for the rest > of Feb, let's all work together to add that spit polish > and only debug/fix. Ok. Since we should probably firm up our plans for the 3.1 release anyway, here's a suggestion: February 1 - February 7: Add your final feature changes. After February 8, feature changes are highly discouraged. February 8 - February 14: Developers are encouraged to focus on code clean up. Find your favorite files and document them better, make them more PEP8 compliant and break them into smaller files if necessary. This is a good time to rename classes/function/variables that need it. If you can't think of anything to do, grab a random file and work to give it a better pylint score. February 15: Create the 3.1 maintenance branch (gramps31). Any incomplete features will be disabled or commented out in the 31 branch so as not to hold up the release. February 15 - February 28: Bug fix! We will manage the blocking bugs on the Mantis roadmap as usual. Bugs should be fixed in the gramps31 branch and merged into trunk. March 1: Release GRAMPS 3.1.0 - assuming all bugs on the roadmap are fixed. What do you think? Can we do it? |
From: Rob H. <rob...@gm...> - 2009-02-02 06:01:28
|
Greetings Devs: As far as I am concerned: * I will pull alphabet_navigation until 3.2... * will work on calendar_build to break it down some... if anyone else has any problems or ideas on this, please let me know now? Sincerely Yours, Rob On Sun, Feb 1, 2009 at 1:39 PM, Brian Matherly <br...@gr...>wrote: > > I think it is time for a mandate though: give us a week (or > > so) to add or > > remove what we personally have as goals to get into 3.1, > > then for the rest > > of Feb, let's all work together to add that spit polish > > and only debug/fix. > > Ok. Since we should probably firm up our plans for the 3.1 release anyway, > here's a suggestion: > > February 1 - February 7: > Add your final feature changes. After February 8, feature changes are > highly discouraged. > > February 8 - February 14: > Developers are encouraged to focus on code clean up. Find your favorite > files and document them better, make them more PEP8 compliant and break them > into smaller files if necessary. This is a good time to rename > classes/function/variables that need it. If you can't think of anything to > do, grab a random file and work to give it a better pylint score. > > February 15: > Create the 3.1 maintenance branch (gramps31). Any incomplete features will > be disabled or commented out in the 31 branch so as not to hold up the > release. > > February 15 - February 28: > Bug fix! We will manage the blocking bugs on the Mantis roadmap as usual. > Bugs should be fixed in the gramps31 branch and merged into trunk. > > March 1: > Release GRAMPS 3.1.0 - assuming all bugs on the roadmap are fixed. > > What do you think? Can we do it? > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |