From: Nick H. <nic...@ho...> - 2010-02-14 16:08:44
|
Hi, I am intending to to some work on the extended pedigree view. I would like to get it to a stage where we can seriously consider it for inclusion in the 3.2 release. There are two main tasks that need to be done: 1. Fix the bug with the connecting lines. 2. Move the configuration in the popups into the new configuration menu. I will also try to tidy up the code so that it is easier to understand. If anyone else was planning to work on this, or has any comments, then let me know. Regards, Nick. |
From: Nick H. <nic...@ho...> - 2010-03-02 11:29:57
|
Benny, I did get a chance to look at the extended pedigree view. My first objective was to fix the bug with the connecting lines in type C. This is also a bug with type A, but it not so noticeable due to the limit of 5 levels of hierarchy. The solution was to create a class for the connecting line that was aware of the child and both parent boxes. This worked for type C and I was going to use it for type A as well. It also removed some code from the main loop making it easier to understand. In doing this I started to tidy up the code. There are places where code is duplicated and there is also some redundant code. I would also like to change the way the direction change works. At the moment it only works for type C. I can't see why it shouldn't just involve a simple transformation of the standard orientation layout co-ordinates. We should be able to change the direction of all the layout types. I have also written a dynamic position calculation for type A. This was only a small tweak from the type C calculation. This will allow us to view more levels in type A as well as type C. Do we really need both types in this case? I'll do some more work on it today. I suggest that we don't include it in this release, but include it as a plug-in. What do you think? Regards, Nick. |
From: Benny M. <ben...@gm...> - 2010-03-02 11:45:17
|
2010/3/2 Nick Hall <nic...@ho...>: > Benny, > > I did get a chance to look at the extended pedigree view. > > My first objective was to fix the bug with the connecting lines in type > C. This is also a bug with type A, but it not so noticeable due to the > limit of 5 levels of hierarchy. The solution was to create a class for > the connecting line that was aware of the child and both parent boxes. > This worked for type C and I was going to use it for type A as well. It > also removed some code from the main loop making it easier to understand. > > In doing this I started to tidy up the code. There are places where > code is duplicated and there is also some redundant code. > > I would also like to change the way the direction change works. At the > moment it only works for type C. I can't see why it shouldn't just > involve a simple transformation of the standard orientation layout > co-ordinates. We should be able to change the direction of all the > layout types. > > I have also written a dynamic position calculation for type A. This was > only a small tweak from the type C calculation. This will allow us to > view more levels in type A as well as type C. Do we really need both > types in this case? > > I'll do some more work on it today. > > I suggest that we don't include it in this release, but include it as a > plug-in. > > What do you think? I think we need a pedigreeview in gramps, and that it would be better to remove the old one for better newer code that is supported. If we leave the old pedigreeview in Gramps, it will probably be with us into 2011. It looks like you however have a lot of changes, so if you think the code will not be stable, then to move forward, we should remove pedigreeviewext from gramps, and move the new code for now to the addons. We have to avoid however to have too many things in gramps-addons that will be integrated in trunk also. The chance is big the developer needs to support to much different versions. So, choose one of the following: 1/New Pedigreeviewext is in good shape: rename it as Pedigreeview, so remove old and replace by new one, update Makefile/POTFILES, merge with trunk 2/New Pedigreeviewext is still unstable: remove it from branch32, update Makefile/POTFILES, in trunk however, do as 1/ above, so let's not carry around the old one in what will become version 3.3 much later on. If you think you can support it, also add it to gramps-addons for 3.2. Personally, I would not bother about that. Not every new feature must be present in gramps-addons and the old pedigreeview is not in itself 'broken'. Benny > Regards, > > > Nick. > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: flix007 <xi...@nu...> - 2010-03-02 18:05:59
|
Benny Malengier schrieb: > 2010/3/2 Nick Hall <nic...@ho...>: >> Benny, >> >> I did get a chance to look at the extended pedigree view. >> >> My first objective was to fix the bug with the connecting lines in type >> C. This is also a bug with type A, but it not so noticeable due to the >> limit of 5 levels of hierarchy. The solution was to create a class for >> the connecting line that was aware of the child and both parent boxes. >> This worked for type C and I was going to use it for type A as well. It >> also removed some code from the main loop making it easier to understand. >> >> In doing this I started to tidy up the code. There are places where >> code is duplicated and there is also some redundant code. >> >> I would also like to change the way the direction change works. At the >> moment it only works for type C. I can't see why it shouldn't just >> involve a simple transformation of the standard orientation layout >> co-ordinates. We should be able to change the direction of all the >> layout types. >> >> I have also written a dynamic position calculation for type A. This was >> only a small tweak from the type C calculation. This will allow us to >> view more levels in type A as well as type C. Do we really need both >> types in this case? >> >> I'll do some more work on it today. >> >> I suggest that we don't include it in this release, but include it as a >> plug-in. >> >> What do you think? > > I think we need a pedigreeview in gramps, and that it would be better > to remove the old one for better newer code that is supported. > If we leave the old pedigreeview in Gramps, it will probably be with > us into 2011. > > It looks like you however have a lot of changes, so if you think the > code will not be stable, then to move forward, we should remove > pedigreeviewext from gramps, and move the new code for now to the > addons. > We have to avoid however to have too many things in gramps-addons that > will be integrated in trunk also. The chance is big the developer > needs to support to much different versions. > > So, choose one of the following: > > 1/New Pedigreeviewext is in good shape: rename it as Pedigreeview, so > remove old and replace by new one, update Makefile/POTFILES, merge > with trunk > > 2/New Pedigreeviewext is still unstable: remove it from branch32, > update Makefile/POTFILES, in trunk however, do as 1/ above, so let's > not carry around the old one in what will become version 3.3 much > later on. If you think you can support it, also add it to > gramps-addons for 3.2. Personally, I would not bother about that. Not > every new feature must be present in gramps-addons and the old > pedigreeview is not in itself 'broken'. > > Benny > >> Regards, >> >> >> Nick. >> Nick, as you are working on the extended pedigree view: Some weeks ago I added the timeline pedigree view to gramps-addons. Personally I would like it to be merged to the other pedigree views, because it also shares a lot of code with them. I will be able to work on it again during the easter break. I would just like to know if that has any influence on your work with the pedigree view? Felix |
From: Nick H. <nic...@ho...> - 2010-03-02 18:29:58
|
Felix, My original idea was to get the extended pedigree view to a state where it could be used in the 3.2 release. This is looking less likely now. I haven't looked at the code for the timeline pedigree view, because I didn't want to get distracted. What code does it share? I am guessing that it re-uses the tree walking, the box widgets and popup menu code. It would be good if we could share code. Maybe we could have a base pedigree class which other views could inherit from. The pedigree view positions widgets in a table. The positions are either calculated or looked up. I am tidying up this part of the code at the moment. Regards, Nick. Felix Heß wrote: > Benny Malengier schrieb: >> 2010/3/2 Nick Hall <nic...@ho...>: >>> Benny, >>> >>> I did get a chance to look at the extended pedigree view. >>> >>> My first objective was to fix the bug with the connecting lines in type >>> C. This is also a bug with type A, but it not so noticeable due to the >>> limit of 5 levels of hierarchy. The solution was to create a class for >>> the connecting line that was aware of the child and both parent boxes. >>> This worked for type C and I was going to use it for type A as >>> well. It >>> also removed some code from the main loop making it easier to >>> understand. >>> >>> In doing this I started to tidy up the code. There are places where >>> code is duplicated and there is also some redundant code. >>> >>> I would also like to change the way the direction change works. At the >>> moment it only works for type C. I can't see why it shouldn't just >>> involve a simple transformation of the standard orientation layout >>> co-ordinates. We should be able to change the direction of all the >>> layout types. >>> >>> I have also written a dynamic position calculation for type A. This >>> was >>> only a small tweak from the type C calculation. This will allow us to >>> view more levels in type A as well as type C. Do we really need both >>> types in this case? >>> >>> I'll do some more work on it today. >>> >>> I suggest that we don't include it in this release, but include it as a >>> plug-in. >>> >>> What do you think? >> >> I think we need a pedigreeview in gramps, and that it would be better >> to remove the old one for better newer code that is supported. >> If we leave the old pedigreeview in Gramps, it will probably be with >> us into 2011. >> >> It looks like you however have a lot of changes, so if you think the >> code will not be stable, then to move forward, we should remove >> pedigreeviewext from gramps, and move the new code for now to the >> addons. >> We have to avoid however to have too many things in gramps-addons that >> will be integrated in trunk also. The chance is big the developer >> needs to support to much different versions. >> >> So, choose one of the following: >> >> 1/New Pedigreeviewext is in good shape: rename it as Pedigreeview, so >> remove old and replace by new one, update Makefile/POTFILES, merge >> with trunk >> >> 2/New Pedigreeviewext is still unstable: remove it from branch32, >> update Makefile/POTFILES, in trunk however, do as 1/ above, so let's >> not carry around the old one in what will become version 3.3 much >> later on. If you think you can support it, also add it to >> gramps-addons for 3.2. Personally, I would not bother about that. Not >> every new feature must be present in gramps-addons and the old >> pedigreeview is not in itself 'broken'. >> >> Benny >> >>> Regards, >>> >>> >>> Nick. >>> > > Nick, > > as you are working on the extended pedigree view: > Some weeks ago I added the timeline pedigree view to gramps-addons. > Personally I would like it to be merged to the other pedigree views, > because it also shares a lot of code with them. I will be able to work > on it again during the easter break. > I would just like to know if that has any influence on your work with > the pedigree view? > > Felix > > |
From: jerome <rom...@ya...> - 2010-03-02 19:14:32
|
Not certain you are talking from the same view/code ! Alternate extended PedigreeView (ezegzda) : http://www.gramps-project.org/bugs/view.php?id=2846 Aternated extended PedigreeView (flix007) : http://www.gramps-project.org/bugs/view.php?id=3474 --- En date de : Mar 2.3.10, Nick Hall <nic...@ho...> a écrit : > De: Nick Hall <nic...@ho...> > Objet: Re: [Gramps-devel] Extended pedigree view > À: "Felix Heß" <fel...@gm...> > Cc: "Gramps developers" <gra...@li...> > Date: Mardi 2 mars 2010, 19h13 > Felix, > > My original idea was to get the extended pedigree view to a > state where > it could be used in the 3.2 release. This is looking > less likely now. > > I haven't looked at the code for the timeline pedigree > view, because I > didn't want to get distracted. What code does it > share? I am guessing > that it re-uses the tree walking, the box widgets and popup > menu code. > > It would be good if we could share code. Maybe we > could have a base > pedigree class which other views could inherit from. > > The pedigree view positions widgets in a table. The > positions are > either calculated or looked up. I am tidying up this > part of the code > at the moment. > > Regards, > > Nick. > > > Felix Heß wrote: > > Benny Malengier schrieb: > >> 2010/3/2 Nick Hall <nic...@ho...>: > >>> Benny, > >>> > >>> I did get a chance to look at the extended > pedigree view. > >>> > >>> My first objective was to fix the bug with the > connecting lines in type > >>> C. This is also a bug with type A, but > it not so noticeable due to the > >>> limit of 5 levels of hierarchy. The > solution was to create a class for > >>> the connecting line that was aware of the > child and both parent boxes. > >>> This worked for type C and I was going to use > it for type A as > >>> well. It > >>> also removed some code from the main loop > making it easier to > >>> understand. > >>> > >>> In doing this I started to tidy up the > code. There are places where > >>> code is duplicated and there is also some > redundant code. > >>> > >>> I would also like to change the way the > direction change works. At the > >>> moment it only works for type C. I can't > see why it shouldn't just > >>> involve a simple transformation of the > standard orientation layout > >>> co-ordinates. We should be able to > change the direction of all the > >>> layout types. > >>> > >>> I have also written a dynamic position > calculation for type A. This > >>> was > >>> only a small tweak from the type C > calculation. This will allow us to > >>> view more levels in type A as well as type > C. Do we really need both > >>> types in this case? > >>> > >>> I'll do some more work on it today. > >>> > >>> I suggest that we don't include it in this > release, but include it as a > >>> plug-in. > >>> > >>> What do you think? > >> > >> I think we need a pedigreeview in gramps, and that > it would be better > >> to remove the old one for better newer code that > is supported. > >> If we leave the old pedigreeview in Gramps, it > will probably be with > >> us into 2011. > >> > >> It looks like you however have a lot of changes, > so if you think the > >> code will not be stable, then to move forward, we > should remove > >> pedigreeviewext from gramps, and move the new code > for now to the > >> addons. > >> We have to avoid however to have too many things > in gramps-addons that > >> will be integrated in trunk also. The chance is > big the developer > >> needs to support to much different versions. > >> > >> So, choose one of the following: > >> > >> 1/New Pedigreeviewext is in good shape: rename it > as Pedigreeview, so > >> remove old and replace by new one, update > Makefile/POTFILES, merge > >> with trunk > >> > >> 2/New Pedigreeviewext is still unstable: remove it > from branch32, > >> update Makefile/POTFILES, in trunk however, do as > 1/ above, so let's > >> not carry around the old one in what will become > version 3.3 much > >> later on. If you think you can support it, also > add it to > >> gramps-addons for 3.2. Personally, I would not > bother about that. Not > >> every new feature must be present in gramps-addons > and the old > >> pedigreeview is not in itself 'broken'. > >> > >> Benny > >> > >>> Regards, > >>> > >>> > >>> Nick. > >>> > > > > Nick, > > > > as you are working on the extended pedigree view: > > Some weeks ago I added the timeline pedigree view to > gramps-addons. > > Personally I would like it to be merged to the other > pedigree views, > > because it also shares a lot of code with them. I will > be able to work > > on it again during the easter break. > > I would just like to know if that has any influence on > your work with > > the pedigree view? > > > > Felix > > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, > find bugs > proactively, and fine-tune applications for parallel > performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <nic...@ho...> - 2010-03-02 19:27:41
|
We could be talking about different views. I am working on - Alternate extended PedigreeView (ezegzda) I haven't looked at - Aternated extended PedigreeView (flix007) There seem to be two versions in this second feature request: Pedigree View with descendants Timeline Pedigree View Both of them seem interesting. I haven't looked at the code for either of these. Can we share code? Nick. jerome wrote: > Not certain you are talking from the same view/code ! > > Alternate extended PedigreeView (ezegzda) : > http://www.gramps-project.org/bugs/view.php?id=2846 > > Aternated extended PedigreeView (flix007) : > http://www.gramps-project.org/bugs/view.php?id=3474 > > > > --- En date de : Mar 2.3.10, Nick Hall <nic...@ho...> a écrit : > > >> De: Nick Hall <nic...@ho...> >> Objet: Re: [Gramps-devel] Extended pedigree view >> À: "Felix Heß" <fel...@gm...> >> Cc: "Gramps developers" <gra...@li...> >> Date: Mardi 2 mars 2010, 19h13 >> Felix, >> >> My original idea was to get the extended pedigree view to a >> state where >> it could be used in the 3.2 release. This is looking >> less likely now. >> >> I haven't looked at the code for the timeline pedigree >> view, because I >> didn't want to get distracted. What code does it >> share? I am guessing >> that it re-uses the tree walking, the box widgets and popup >> menu code. >> >> It would be good if we could share code. Maybe we >> could have a base >> pedigree class which other views could inherit from. >> >> The pedigree view positions widgets in a table. The >> positions are >> either calculated or looked up. I am tidying up this >> part of the code >> at the moment. >> >> Regards, >> >> Nick. >> >> >> Felix Heß wrote: >> >>> Benny Malengier schrieb: >>> >>>> 2010/3/2 Nick Hall <nic...@ho...>: >>>> >>>>> Benny, >>>>> >>>>> I did get a chance to look at the extended >>>>> >> pedigree view. >> >>>>> My first objective was to fix the bug with the >>>>> >> connecting lines in type >> >>>>> C. This is also a bug with type A, but >>>>> >> it not so noticeable due to the >> >>>>> limit of 5 levels of hierarchy. The >>>>> >> solution was to create a class for >> >>>>> the connecting line that was aware of the >>>>> >> child and both parent boxes. >> >>>>> This worked for type C and I was going to use >>>>> >> it for type A as >> >>>>> well. It >>>>> also removed some code from the main loop >>>>> >> making it easier to >> >>>>> understand. >>>>> >>>>> In doing this I started to tidy up the >>>>> >> code. There are places where >> >>>>> code is duplicated and there is also some >>>>> >> redundant code. >> >>>>> I would also like to change the way the >>>>> >> direction change works. At the >> >>>>> moment it only works for type C. I can't >>>>> >> see why it shouldn't just >> >>>>> involve a simple transformation of the >>>>> >> standard orientation layout >> >>>>> co-ordinates. We should be able to >>>>> >> change the direction of all the >> >>>>> layout types. >>>>> >>>>> I have also written a dynamic position >>>>> >> calculation for type A. This >> >>>>> was >>>>> only a small tweak from the type C >>>>> >> calculation. This will allow us to >> >>>>> view more levels in type A as well as type >>>>> >> C. Do we really need both >> >>>>> types in this case? >>>>> >>>>> I'll do some more work on it today. >>>>> >>>>> I suggest that we don't include it in this >>>>> >> release, but include it as a >> >>>>> plug-in. >>>>> >>>>> What do you think? >>>>> >>>> I think we need a pedigreeview in gramps, and that >>>> >> it would be better >> >>>> to remove the old one for better newer code that >>>> >> is supported. >> >>>> If we leave the old pedigreeview in Gramps, it >>>> >> will probably be with >> >>>> us into 2011. >>>> >>>> It looks like you however have a lot of changes, >>>> >> so if you think the >> >>>> code will not be stable, then to move forward, we >>>> >> should remove >> >>>> pedigreeviewext from gramps, and move the new code >>>> >> for now to the >> >>>> addons. >>>> We have to avoid however to have too many things >>>> >> in gramps-addons that >> >>>> will be integrated in trunk also. The chance is >>>> >> big the developer >> >>>> needs to support to much different versions. >>>> >>>> So, choose one of the following: >>>> >>>> 1/New Pedigreeviewext is in good shape: rename it >>>> >> as Pedigreeview, so >> >>>> remove old and replace by new one, update >>>> >> Makefile/POTFILES, merge >> >>>> with trunk >>>> >>>> 2/New Pedigreeviewext is still unstable: remove it >>>> >> from branch32, >> >>>> update Makefile/POTFILES, in trunk however, do as >>>> >> 1/ above, so let's >> >>>> not carry around the old one in what will become >>>> >> version 3.3 much >> >>>> later on. If you think you can support it, also >>>> >> add it to >> >>>> gramps-addons for 3.2. Personally, I would not >>>> >> bother about that. Not >> >>>> every new feature must be present in gramps-addons >>>> >> and the old >> >>>> pedigreeview is not in itself 'broken'. >>>> >>>> Benny >>>> >>>> >>>>> Regards, >>>>> >>>>> >>>>> Nick. >>>>> >>>>> >>> Nick, >>> >>> as you are working on the extended pedigree view: >>> Some weeks ago I added the timeline pedigree view to >>> >> gramps-addons. >> >>> Personally I would like it to be merged to the other >>> >> pedigree views, >> >>> because it also shares a lot of code with them. I will >>> >> be able to work >> >>> on it again during the easter break. >>> I would just like to know if that has any influence on >>> >> your work with >> >>> the pedigree view? >>> >>> Felix >>> >>> >>> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, >> find bugs >> proactively, and fine-tune applications for parallel >> performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > > > > > > |
From: Benny M. <ben...@gm...> - 2010-03-02 20:27:54
|
2010/3/2 Nick Hall <nic...@ho...>: > We could be talking about different views. > > I am working on - Alternate extended PedigreeView (ezegzda) > > I haven't looked at - Aternated extended PedigreeView (flix007) > > There seem to be two versions in this second feature request: > > Pedigree View with descendants > Timeline Pedigree View > > Both of them seem interesting. I haven't looked at the code for either > of these. Can we share code? A better approach is to put code in the Gramps codebase, then merge in patches from Felix, and refractoring pieces so as to share code. Cooperating without meeting face to face is difficult. As Nick has commit rights, his code is the by default the base code. We often are confronted with entire changed files on the bug tracker, which is very difficult for developers. There is a reason contribution happens via patches in the OSS world, preferably atomic: one patch per feature/change. Benny > > Nick. > > jerome wrote: >> Not certain you are talking from the same view/code ! >> >> Alternate extended PedigreeView (ezegzda) : >> http://www.gramps-project.org/bugs/view.php?id=2846 >> >> Aternated extended PedigreeView (flix007) : >> http://www.gramps-project.org/bugs/view.php?id=3474 >> >> >> >> --- En date de : Mar 2.3.10, Nick Hall <nic...@ho...> a écrit : >> >> >>> De: Nick Hall <nic...@ho...> >>> Objet: Re: [Gramps-devel] Extended pedigree view >>> À: "Felix Heß" <fel...@gm...> >>> Cc: "Gramps developers" <gra...@li...> >>> Date: Mardi 2 mars 2010, 19h13 >>> Felix, >>> >>> My original idea was to get the extended pedigree view to a >>> state where >>> it could be used in the 3.2 release. This is looking >>> less likely now. >>> >>> I haven't looked at the code for the timeline pedigree >>> view, because I >>> didn't want to get distracted. What code does it >>> share? I am guessing >>> that it re-uses the tree walking, the box widgets and popup >>> menu code. >>> >>> It would be good if we could share code. Maybe we >>> could have a base >>> pedigree class which other views could inherit from. >>> >>> The pedigree view positions widgets in a table. The >>> positions are >>> either calculated or looked up. I am tidying up this >>> part of the code >>> at the moment. >>> >>> Regards, >>> >>> Nick. >>> >>> >>> Felix Heß wrote: >>> >>>> Benny Malengier schrieb: >>>> >>>>> 2010/3/2 Nick Hall <nic...@ho...>: >>>>> >>>>>> Benny, >>>>>> >>>>>> I did get a chance to look at the extended >>>>>> >>> pedigree view. >>> >>>>>> My first objective was to fix the bug with the >>>>>> >>> connecting lines in type >>> >>>>>> C. This is also a bug with type A, but >>>>>> >>> it not so noticeable due to the >>> >>>>>> limit of 5 levels of hierarchy. The >>>>>> >>> solution was to create a class for >>> >>>>>> the connecting line that was aware of the >>>>>> >>> child and both parent boxes. >>> >>>>>> This worked for type C and I was going to use >>>>>> >>> it for type A as >>> >>>>>> well. It >>>>>> also removed some code from the main loop >>>>>> >>> making it easier to >>> >>>>>> understand. >>>>>> >>>>>> In doing this I started to tidy up the >>>>>> >>> code. There are places where >>> >>>>>> code is duplicated and there is also some >>>>>> >>> redundant code. >>> >>>>>> I would also like to change the way the >>>>>> >>> direction change works. At the >>> >>>>>> moment it only works for type C. I can't >>>>>> >>> see why it shouldn't just >>> >>>>>> involve a simple transformation of the >>>>>> >>> standard orientation layout >>> >>>>>> co-ordinates. We should be able to >>>>>> >>> change the direction of all the >>> >>>>>> layout types. >>>>>> >>>>>> I have also written a dynamic position >>>>>> >>> calculation for type A. This >>> >>>>>> was >>>>>> only a small tweak from the type C >>>>>> >>> calculation. This will allow us to >>> >>>>>> view more levels in type A as well as type >>>>>> >>> C. Do we really need both >>> >>>>>> types in this case? >>>>>> >>>>>> I'll do some more work on it today. >>>>>> >>>>>> I suggest that we don't include it in this >>>>>> >>> release, but include it as a >>> >>>>>> plug-in. >>>>>> >>>>>> What do you think? >>>>>> >>>>> I think we need a pedigreeview in gramps, and that >>>>> >>> it would be better >>> >>>>> to remove the old one for better newer code that >>>>> >>> is supported. >>> >>>>> If we leave the old pedigreeview in Gramps, it >>>>> >>> will probably be with >>> >>>>> us into 2011. >>>>> >>>>> It looks like you however have a lot of changes, >>>>> >>> so if you think the >>> >>>>> code will not be stable, then to move forward, we >>>>> >>> should remove >>> >>>>> pedigreeviewext from gramps, and move the new code >>>>> >>> for now to the >>> >>>>> addons. >>>>> We have to avoid however to have too many things >>>>> >>> in gramps-addons that >>> >>>>> will be integrated in trunk also. The chance is >>>>> >>> big the developer >>> >>>>> needs to support to much different versions. >>>>> >>>>> So, choose one of the following: >>>>> >>>>> 1/New Pedigreeviewext is in good shape: rename it >>>>> >>> as Pedigreeview, so >>> >>>>> remove old and replace by new one, update >>>>> >>> Makefile/POTFILES, merge >>> >>>>> with trunk >>>>> >>>>> 2/New Pedigreeviewext is still unstable: remove it >>>>> >>> from branch32, >>> >>>>> update Makefile/POTFILES, in trunk however, do as >>>>> >>> 1/ above, so let's >>> >>>>> not carry around the old one in what will become >>>>> >>> version 3.3 much >>> >>>>> later on. If you think you can support it, also >>>>> >>> add it to >>> >>>>> gramps-addons for 3.2. Personally, I would not >>>>> >>> bother about that. Not >>> >>>>> every new feature must be present in gramps-addons >>>>> >>> and the old >>> >>>>> pedigreeview is not in itself 'broken'. >>>>> >>>>> Benny >>>>> >>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> Nick. >>>>>> >>>>>> >>>> Nick, >>>> >>>> as you are working on the extended pedigree view: >>>> Some weeks ago I added the timeline pedigree view to >>>> >>> gramps-addons. >>> >>>> Personally I would like it to be merged to the other >>>> >>> pedigree views, >>> >>>> because it also shares a lot of code with them. I will >>>> >>> be able to work >>> >>>> on it again during the easter break. >>>> I would just like to know if that has any influence on >>>> >>> your work with >>> >>>> the pedigree view? >>>> >>>> Felix >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, >>> find bugs >>> proactively, and fine-tune applications for parallel >>> performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >> >> >> >> >> >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: flix007 <xi...@nu...> - 2010-03-02 21:07:16
|
Nick, both Pedigree View with descendants and timeline Pedigree View were written by me. I started with the name Extended Pedigree View until I noticed there was another Extended Pedigree View (at that time ony in the bug tracker). At that point I changed its name to Pedigree View with descendants. It is also based on the table-layout (like all of the pedigree views in current trunk). Then I stopped working on that and focused on "Timeline Pedigree View". It does not use a table for the layout to be more flexible. The Timeline Pedigree View is now also in gramps-addons. Actually one could create all the layouts of the "Extended Pedigree View" in trunk (i.e. style A, B, C) with the Layout-mechanism the "Timeline Pedigree View" uses. However it adds the possibility to - show descendants - show a timeline with lifespans of all persons In principle they share some code (personboxes, menu callbacks, etc). However it has evolved to far for just creating a patch. So now we are in the difficult situation that Benny has mentioned. Felix Benny Malengier schrieb: > 2010/3/2 Nick Hall <nic...@ho...>: >> We could be talking about different views. >> >> I am working on - Alternate extended PedigreeView (ezegzda) >> >> I haven't looked at - Aternated extended PedigreeView (flix007) >> >> There seem to be two versions in this second feature request: >> >> Pedigree View with descendants >> Timeline Pedigree View >> >> Both of them seem interesting. I haven't looked at the code for either >> of these. Can we share code? > > A better approach is to put code in the Gramps codebase, then merge in > patches from Felix, and refractoring pieces so as to share code. > Cooperating without meeting face to face is difficult. As Nick has > commit rights, his code is the by default the base code. > > We often are confronted with entire changed files on the bug tracker, > which is very difficult for developers. There is a reason contribution > happens via patches in the OSS world, preferably atomic: one patch per > feature/change. > > Benny > >> Nick. >> >> jerome wrote: >>> Not certain you are talking from the same view/code ! >>> >>> Alternate extended PedigreeView (ezegzda) : >>> http://www.gramps-project.org/bugs/view.php?id=2846 >>> >>> Aternated extended PedigreeView (flix007) : >>> http://www.gramps-project.org/bugs/view.php?id=3474 >>> >>> >>> >>> --- En date de : Mar 2.3.10, Nick Hall <nic...@ho...> a écrit : >>> >>> >>>> De: Nick Hall <nic...@ho...> >>>> Objet: Re: [Gramps-devel] Extended pedigree view >>>> À: "Felix Heß" <fel...@gm...> >>>> Cc: "Gramps developers" <gra...@li...> >>>> Date: Mardi 2 mars 2010, 19h13 >>>> Felix, >>>> >>>> My original idea was to get the extended pedigree view to a >>>> state where >>>> it could be used in the 3.2 release. This is looking >>>> less likely now. >>>> >>>> I haven't looked at the code for the timeline pedigree >>>> view, because I >>>> didn't want to get distracted. What code does it >>>> share? I am guessing >>>> that it re-uses the tree walking, the box widgets and popup >>>> menu code. >>>> >>>> It would be good if we could share code. Maybe we >>>> could have a base >>>> pedigree class which other views could inherit from. >>>> >>>> The pedigree view positions widgets in a table. The >>>> positions are >>>> either calculated or looked up. I am tidying up this >>>> part of the code >>>> at the moment. >>>> >>>> Regards, >>>> >>>> Nick. >>>> >>>> >>>> Felix Heß wrote: >>>> >>>>> Benny Malengier schrieb: >>>>> >>>>>> 2010/3/2 Nick Hall <nic...@ho...>: >>>>>> >>>>>>> Benny, >>>>>>> >>>>>>> I did get a chance to look at the extended >>>>>>> >>>> pedigree view. >>>> >>>>>>> My first objective was to fix the bug with the >>>>>>> >>>> connecting lines in type >>>> >>>>>>> C. This is also a bug with type A, but >>>>>>> >>>> it not so noticeable due to the >>>> >>>>>>> limit of 5 levels of hierarchy. The >>>>>>> >>>> solution was to create a class for >>>> >>>>>>> the connecting line that was aware of the >>>>>>> >>>> child and both parent boxes. >>>> >>>>>>> This worked for type C and I was going to use >>>>>>> >>>> it for type A as >>>> >>>>>>> well. It >>>>>>> also removed some code from the main loop >>>>>>> >>>> making it easier to >>>> >>>>>>> understand. >>>>>>> >>>>>>> In doing this I started to tidy up the >>>>>>> >>>> code. There are places where >>>> >>>>>>> code is duplicated and there is also some >>>>>>> >>>> redundant code. >>>> >>>>>>> I would also like to change the way the >>>>>>> >>>> direction change works. At the >>>> >>>>>>> moment it only works for type C. I can't >>>>>>> >>>> see why it shouldn't just >>>> >>>>>>> involve a simple transformation of the >>>>>>> >>>> standard orientation layout >>>> >>>>>>> co-ordinates. We should be able to >>>>>>> >>>> change the direction of all the >>>> >>>>>>> layout types. >>>>>>> >>>>>>> I have also written a dynamic position >>>>>>> >>>> calculation for type A. This >>>> >>>>>>> was >>>>>>> only a small tweak from the type C >>>>>>> >>>> calculation. This will allow us to >>>> >>>>>>> view more levels in type A as well as type >>>>>>> >>>> C. Do we really need both >>>> >>>>>>> types in this case? >>>>>>> >>>>>>> I'll do some more work on it today. >>>>>>> >>>>>>> I suggest that we don't include it in this >>>>>>> >>>> release, but include it as a >>>> >>>>>>> plug-in. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>> I think we need a pedigreeview in gramps, and that >>>>>> >>>> it would be better >>>> >>>>>> to remove the old one for better newer code that >>>>>> >>>> is supported. >>>> >>>>>> If we leave the old pedigreeview in Gramps, it >>>>>> >>>> will probably be with >>>> >>>>>> us into 2011. >>>>>> >>>>>> It looks like you however have a lot of changes, >>>>>> >>>> so if you think the >>>> >>>>>> code will not be stable, then to move forward, we >>>>>> >>>> should remove >>>> >>>>>> pedigreeviewext from gramps, and move the new code >>>>>> >>>> for now to the >>>> >>>>>> addons. >>>>>> We have to avoid however to have too many things >>>>>> >>>> in gramps-addons that >>>> >>>>>> will be integrated in trunk also. The chance is >>>>>> >>>> big the developer >>>> >>>>>> needs to support to much different versions. >>>>>> >>>>>> So, choose one of the following: >>>>>> >>>>>> 1/New Pedigreeviewext is in good shape: rename it >>>>>> >>>> as Pedigreeview, so >>>> >>>>>> remove old and replace by new one, update >>>>>> >>>> Makefile/POTFILES, merge >>>> >>>>>> with trunk >>>>>> >>>>>> 2/New Pedigreeviewext is still unstable: remove it >>>>>> >>>> from branch32, >>>> >>>>>> update Makefile/POTFILES, in trunk however, do as >>>>>> >>>> 1/ above, so let's >>>> >>>>>> not carry around the old one in what will become >>>>>> >>>> version 3.3 much >>>> >>>>>> later on. If you think you can support it, also >>>>>> >>>> add it to >>>> >>>>>> gramps-addons for 3.2. Personally, I would not >>>>>> >>>> bother about that. Not >>>> >>>>>> every new feature must be present in gramps-addons >>>>>> >>>> and the old >>>> >>>>>> pedigreeview is not in itself 'broken'. >>>>>> >>>>>> Benny >>>>>> >>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Nick. >>>>>>> >>>>>>> >>>>> Nick, >>>>> >>>>> as you are working on the extended pedigree view: >>>>> Some weeks ago I added the timeline pedigree view to >>>>> >>>> gramps-addons. >>>> >>>>> Personally I would like it to be merged to the other >>>>> >>>> pedigree views, >>>> >>>>> because it also shares a lot of code with them. I will >>>>> >>>> be able to work >>>> >>>>> on it again during the easter break. >>>>> I would just like to know if that has any influence on >>>>> >>>> your work with >>>> >>>>> the pedigree view? >>>>> >>>>> Felix >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, >>>> find bugs >>>> proactively, and fine-tune applications for parallel >>>> performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>>> >>> >>> >>> >>> >>> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > |
From: <ez...@ya...> - 2010-03-04 21:11:49
|
Thank you for fix bug with connecting lines. Good work. I look at your code. And think to start work on drawing more complex trees, as in commercial products. Maybe now it will be successful, but a year ago I had a lot of problems. -- Zegzhda Yevgeny 02.03.10, 11:29, "Nick Hall" <nic...@ho...>: > Benny, > > I did get a chance to look at the extended pedigree view. > > My first objective was to fix the bug with the connecting lines in type > C. This is also a bug with type A, but it not so noticeable due to the > limit of 5 levels of hierarchy. The solution was to create a class for > the connecting line that was aware of the child and both parent boxes. > This worked for type C and I was going to use it for type A as well. It > also removed some code from the main loop making it easier to understand. > > In doing this I started to tidy up the code. There are places where > code is duplicated and there is also some redundant code. > > I would also like to change the way the direction change works. At the > moment it only works for type C. I can't see why it shouldn't just > involve a simple transformation of the standard orientation layout > co-ordinates. We should be able to change the direction of all the > layout types. > > I have also written a dynamic position calculation for type A. This was > only a small tweak from the type C calculation. This will allow us to > view more levels in type A as well as type C. Do we really need both > types in this case? > > I'll do some more work on it today. > > I suggest that we don't include it in this release, but include it as a > plug-in. > > What do you think? > > Regards, > > > Nick. |
From: Benny M. <ben...@gm...> - 2010-02-14 16:25:10
|
2010/2/14 Nick Hall <nic...@ho...>: > Hi, > > I am intending to to some work on the extended pedigree view. I would > like to get it to a stage where we can seriously consider it for > inclusion in the 3.2 release. > > There are two main tasks that need to be done: > > 1. Fix the bug with the connecting lines. > 2. Move the configuration in the popups into the new configuration menu. > > I will also try to tidy up the code so that it is easier to understand. > > If anyone else was planning to work on this, or has any comments, then > let me know. I was going to find an hour today, but I'll hold my guns :-D I was planning the following myself: 1/ do a diff between old pedigree and new, and see if for style A and B, all stuff that old can do is in new. 2/ for style C, place it behind a debug flag, so it is not present in release 3/ remove the old pedigree from svn 4/ if time, move stuff that is now behind the context menu (changing style, ... ) to the configure dialog 5/ if the bugs in style C are easy, try to fix them (but I do 2 because I don't think I'd have the time). So, if I understand, you will try to tackle point 5. Consider doing 1. and 3. first, so we have one view less to worry about. When you then finish, do 2 if you cannot fix the errors with style C. When finished, let met know, and I see if I have time left for 4 (I wouldn't mind you doing that too :-) ) Benny |
From: Benny M. <ben...@gm...> - 2010-02-14 20:34:32
|
I just had another bug here: A person with no connections. I added a picture to it. In console I see: /home/benny/gramps/trunk/src/plugins/view/pedigreeviewext.py:1248: GtkWarning: gtk_table_attach: assertion `left_attach < right_attach' failed 0, 0, 0, 0) /home/benny/gramps/trunk/src/plugins/view/pedigreeviewext.py:1271: GtkWarning: gtk_table_attach: assertion `left_attach < right_attach' failed 0, 0, 0, 0) Benny 2010/2/14 Nick Hall <nic...@ho...>: > Hi, > > I am intending to to some work on the extended pedigree view. I would > like to get it to a stage where we can seriously consider it for > inclusion in the 3.2 release. > > There are two main tasks that need to be done: > > 1. Fix the bug with the connecting lines. > 2. Move the configuration in the popups into the new configuration menu. > > I will also try to tidy up the code so that it is easier to understand. > > If anyone else was planning to work on this, or has any comments, then > let me know. > > Regards, > > > Nick. > > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |