From: Benny M. <ben...@gm...> - 2010-01-02 13:11:55
|
2010/1/1 Doug Blank <dou...@gm...>: > On Fri, Jan 1, 2010 at 5:07 PM, flix007 <xi...@nu...> wrote: >> >> ez...@ya... schrieb: >> > 25.12.09, 13:57, "Benny Malengier" : >> >> 2009/12/25 flix007 >> >>>> 2009/12/25 flix007 > >> >>>> >> >>>> Hi, >> >>>> >> >>>> for me, showing the descendants of the active person in pedigree >> >>>> view is >> >>>> an important feature. Therefore I added this in gramps some weeks >> >>>> ago. I >> >>>> wanted to finish my canges in the christmas holidays and give it >> >>>> to the >> >>>> gramps developers. >> >>>> >> >>>> However, now there is in trunk a new extended pedigree view, to >> >>>> which >> >>>> you want to switch with the next version of gramps. I don't think >> >>>> my >> >>>> code can be easily ported to this new pedigree view. >> >>>> >> >>>> Therefore my question to the developer of the new view, ezegzda, >> >>>> and all >> >>>> other interested developers: >> >>>> Do you think the new pedigree view can be extended to also show >> >>>> descendants? >> >>>> >> >>>> You can see what I mean in the following feature request: >> >>>> http://www.gramps-project.org/bugs/view.php?id=3474 >> >>>> >> >>>> By the way: >> >>>> I would like to apply for an svn-account, so that I can upload >> >>>> changes >> >>>> to pedigree view. >> >>>> >> >>>> >> >>>> The "new" extended pedigree view is not yet working correctly. >> >>>> Moreover, it has 3 styles, of which only one is the new extended one >> >>>> I >> >>>> think, the other is the same as the old pedigree. >> >>>> I don't like this approach of three styles, ... . >> >>>> >> >>>> Personally I would like to make a timeline pedigree view :-) >> >>>> >> >>>> Anyway, about descendants in the pedigree view. I'm not sure all >> >>>> users >> >>>> of pedigree view would like the fact that some of the simplicity goes >> >>>> away. So, should this be an option? >> >>>> I would like to move to one pedigree view with some options, but I >> >>>> never >> >>>> coded in pedigreeview so have no idea how it can be done. >> >>>> >> >>>> As views are plugins, the best is to develop your version of >> >>>> pedigreeview as a new plugin like I have turned ezegzda's extended >> >>>> view >> >>>> into. Then it is easy to show everybody the difference and choose one >> >>>> as >> >>>> the official one for 3.2 release >> > > lix007, > >> >> I've put my code into a new view. It can be downloaded here >> http://www.gramps-project.org/bugs/view.php?id=3474 >> > > > Great... thanks for the contribution! Look forward to trying it out! > >> >> Thank's to all developers how made adding a view as a plugin so easy! >> This is great! >> >> How can the configuration of the plugin be saved? I want to use the >> config.get function, but it fails when I ask for non-existing values. >> Shouldn't the config.get routine be used like >> config.get('interface.timelinepedview-tree-size', [2, 3]) >> where the second parameter is the default value to be returned when the >> value does not exist in the config-file? > > Your guess of how config.get is a reasonable one in Python, but ours doesn't > work quite like that... at least not yet. > > We haven't figured out what we are going to do with addon persistent values. > If every addon put their stuff in one config file, this would get quite > large, and might take some time to load/save. It is probably a good idea to > keep 3rd-party stuff separate for updating and protection as well. It might > make sense for each plugin to have its own config file. > > I'd be interested in opinions on this. > > In any event, currently, a config value needs to register its name and > default value: > > config.register("section.name", VALUE) > > where VALUE is a default Python type (int, float, string, list, dict, etc). > We use the default value to check the type as well, so config vars have type > checking on subsequent changes. There is a signal system based on the > section.name as well. > > Hope that helps, and thanks again, I use a vefsion of config in my simulation program where I inherit from a base config class (which we could put in gen.utils). The register is in the inheriting class, so one can reuse the config for different parts. I think we should do this too, then a view just has to contain a small class inherting from config with the register code for the plugin, and the filename. The only problem is that I did not figure out how to inherit from a singleton class, so instead the base config is an abstract class, and the singleton code must be repeated in every inheriting class. Anybody know a python way to do that in the abstract api? Benny > > -Doug > > >> >> >>>> >> >>>> Benny >> >>>> >> >>>> >> >>>> >> >>>> Best regards >> >>>> Felix >> >>> I agree with you, having one pedigree-view with several options would >> >>> be >> >>> the best. I will code it as a new plugin. Is there any documentation, >> >>> how such a plugin is written (I guess it needs to be registered to >> >>> gramps, etc.). >> >> This is new for 3.2, so not much documentation. Just look at the >> >> extended pedigree registery: >> >> pedigreeviewext.gpr.py >> >> >> >> So, it's not much work, just a new filename, and then cleaning up code. >> >> Extended pedigree is an improvement (eg the black ribbons for dead people), >> >> it would be nice if you add your things there. If style C bugs cannot be >> >> cleaned out, we would still have style A and B as today with the >> >> improvements. >> > >> > How it will be work? For current person will draw 2 descendants and 2-3 >> > ancestors generations? Or yor can draw uncles/aunts and next their tree >> > (descendants) on one screen? >> > I think, it can be integrate how style D, if Felix not change table's >> > drawing model, because I have not edited old styles, but only added new >> > functions, most of them must work in Felix's style. >> > >> >>> What do you mean by timline pedigree view? Stretching the view >> >>> horizontally and placeing persons by their birth year? >> >>> >> >> See here: http://www.dhaeyer.net/stamboom/family.asp?id=723&p=722 >> >> >> >> So a timeline to the left, and boxes are put with the top equal to the >> >> birth day, if no birth day 25 years before child day. The entire lifespan is >> >> visible via color but I think the execution of that can be done better. >> >> >> >> Benny >> > >> > Nice view, but I think it can't be done in the current plugin. If we >> > could move or resize people boxes, for example, we don't have problem with >> > connection line in my version pedigree view. >> > >> >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |