From: Alan E. <ala...@ph...> - 2012-02-18 09:26:46
|
Hi All I had some free time yesterday to start to get to grips with the Census Gramplet / Geps024. I made pretty good progress in understanding how the gramplet works in 3.3 and doesn't work in 3.4 with the introduction of citations and the demise of the source reference object. I'm starting to come up to speed with Python too! Not a very great speed yet - lol. I understand that all this may not be documented yet, or maybe I just can't find it, but are the rules of inheritance documented anywhere so I can see how the classes all fit together in 3.4? Is there anywhere where I can get the details of all the interfaces exposed by the Citation object other than by digging through the code? Have the naming standards changed, so for example: Self.event.add_source_reference(self.source_ref) is fairly self explanatory, what would be the equivalent for a citation reference? Apologies if these questions seem a bit odd, but I'm jumping around between two versions of the code and learning Python at the same time. I may be getting confused! Alan |
From: jerome <rom...@ya...> - 2012-02-18 14:17:15
|
Hello, While we do not generated new version for API (3.4.x)[1] yet[2], the "simplier" place for looking at available classes is maybe to look at modules into gen/lib! Note, without 'sphynx' for generating a new documentation, you can also run 'pyreverse' from 'pylint' package. $ pyreverse -A -S /home/blabla/trunk/src/gen/lib/*.py -o jpeg //svg file format sounds better under some environment// You can also install sphinx and to generate up-to-date API[3], then to contact the web site administrator for uploading the new API documentation. Note, I guess some modules are missing (related to 'user' class on report and some new features). I will try to update the current documentation references. About Gramplet design, there is a specific page[4], I suppose there is no change since 3.3, only some 'relations/calls' might be differents. Otherwise, the developers portal[5] and related links[6] can be useful when we are starting to look at gramps' code and behavior. [1] http://gramps-project.org/wiki/index.php?title=Using_database_API [2] http://gramps-project.org/wiki/index.php?title=Programming_guidelines#Docstrings [3] http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/docs/README.txt [4] http://gramps-project.org/wiki/index.php?title=Gramplets [5] http://gramps-project.org/wiki/index.php?title=Portal:Developers [6] http://gramps-project.org/wiki/index.php?title=Category:Developers/General I hope this could help. Regards, Jérôme --- En date de : Sam 18.2.12, Alan Eveson <ala...@ph...> a écrit : De: Alan Eveson <ala...@ph...> Objet: Re: [Gramps-devel] Census Gramplet / GEPS 024 À: gra...@li... Date: Samedi 18 février 2012, 10h26 Hi All I had some free time yesterday to start to get to grips with the Census Gramplet / Geps024. I made pretty good progress in understanding how the gramplet works in 3.3 and doesn’t work in 3.4 with the introduction of citations and the demise of the source reference object. I’m starting to come up to speed with Python too! Not a very great speed yet – lol. I understand that all this may not be documented yet, or maybe I just can’t find it, but are the rules of inheritance documented anywhere so I can see how the classes all fit together in 3.4?Is there anywhere where I can get the details of all the interfaces exposed by the Citation object other than by digging through the code? Have the naming standards changed, so for example:Self.event.add_source_reference(self.source_ref) is fairly self explanatory, what would be the equivalent for a citation reference? Apologies if these questions seem a bit odd, but I’m jumping around between two versions of the code and learning Python at the same time. I may be getting confused! Alan -----La pièce jointe associée suit----- ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ -----La pièce jointe associée suit----- _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Jérôme <rom...@ya...> - 2012-02-18 17:20:38
|
> without 'sphynx' for generating a new documentation Sorry, it is 'sphinx' ... I have quickly generated a new pseudo UML representation of gen lib modules for next major release (3.4.x)[1]. And tried to update documentation references for gen.lib[2]. At a glance[3], 'CitationBase' replace 'SourceBase', and 'Citation' replace 'SourceRef'... Tim gave better migration links/samples/revision_numbers on GEPS_023[4]. [1] http://gramps-project.org/wiki/images/2/2e/API.svg [2] http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18922 [3] http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps34/docs/gen/gen_lib.rst?view=patch&r1=18922&r2=18921&pathrev=18922 [4] http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Deferred Welcome! PS: I cannot help more, I am also learning python with Gramps... jerome a écrit : > Hello, > > > While we do not generated new version for API (3.4.x)[1] yet[2], the "simplier" place for looking at available classes is maybe to look at modules into gen/lib! Note, without 'sphynx' for generating a new documentation, you can also run 'pyreverse' from 'pylint' package. > > $ pyreverse -A -S /home/blabla/trunk/src/gen/lib/*.py -o jpeg > > //svg file format sounds better under some environment// > > You can also install sphinx and to generate up-to-date API[3], then to contact the web site administrator for uploading the new API documentation. > > Note, I guess some modules are missing (related to 'user' class on report and some new features). I will try to update the current documentation references. > > > About Gramplet design, there is a specific page[4], I suppose there is no change since 3.3, only some 'relations/calls' might be differents. > > > Otherwise, the developers portal[5] and related links[6] can be useful when we are starting to look at gramps' code and behavior. > > > [1] http://gramps-project.org/wiki/index.php?title=Using_database_API > [2] http://gramps-project.org/wiki/index.php?title=Programming_guidelines#Docstrings > [3] http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/docs/README.txt > [4] http://gramps-project.org/wiki/index.php?title=Gramplets > [5] http://gramps-project.org/wiki/index.php?title=Portal:Developers > [6] http://gramps-project.org/wiki/index.php?title=Category:Developers/General > > > I hope this could help. > > Regards, > Jérôme > > > --- En date de : Sam 18.2.12, Alan Eveson <ala...@ph...> a écrit : > > De: Alan Eveson <ala...@ph...> > Objet: Re: [Gramps-devel] Census Gramplet / GEPS 024 > À: gra...@li... > Date: Samedi 18 février 2012, 10h26 > > Hi All I had some free time yesterday to start to get to grips with the Census Gramplet / Geps024. I made pretty good progress in understanding how the gramplet works in 3.3 and doesn’t work in 3.4 with the introduction of citations and the demise of the source reference object. I’m starting to come up to speed with Python too! Not a very great speed yet – lol. I understand that all this may not be documented yet, or maybe I just can’t find it, but are the rules of inheritance documented anywhere so I can see how the classes all fit together in 3.4?Is there anywhere where I can get the details of all the interfaces exposed by the Citation object other than by digging through the code? Have the naming standards changed, so for example:Self.event.add_source_reference(self.source_ref) is fairly self explanatory, what would be the equivalent for a citation reference? Apologies if these questions seem a bit odd, but I’m jumping around > between two versions of the code and learning Python at the same time. I may be getting confused! Alan > -----La pièce jointe associée suit----- > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > -----La pièce jointe associée suit----- > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: <al...@ev...> - 2012-02-18 18:37:15
|
Hi Jerome Thanks for both of your replies. It's a lot to take on at once! I'm going hrough all the links you sent me and it's all very helpful. A couple there I hadn't found. I think I understand the inheritance now and I'm making progress with getting the Gramplet to work with 3.4 and citations. I'm also pondering how the data should be held. Essentially I'd like the data from the census held in one place as a transcript - separate from the family tree data. Then I want to compare the transcript with the family tree and guide the user through entering all the data into the tree. So, from the census date and the age of the person, I can calculate a birth year which could both be used as an birth event estimate for a new person, and as a check if a date already exits in a birth event. Alan On Sat, 18 Feb 2012 18:20:26 +0100 Jérôme <rom...@ya...> wrote: >> without 'sphynx' for generating a new documentation > > Sorry, it is 'sphinx' ... > > I have quickly generated a new pseudo UML representation of gen lib >modules for next major release (3.4.x)[1]. And tried to update >documentation references for gen.lib[2]. > > At a glance[3], 'CitationBase' replace 'SourceBase', and 'Citation' >replace 'SourceRef'... Tim gave better migration >links/samples/revision_numbers on GEPS_023[4]. > > > > [1] http://gramps-project.org/wiki/images/2/2e/API.svg > [2] >http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18922 > [3] >http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps34/docs/gen/gen_lib.rst?view=patch&r1=18922&r2=18921&pathrev=18922 > [4] >http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Deferred > > > Welcome! > > > PS: I cannot help more, I am also learning python with Gramps... > > > > > jerome a écrit : >> Hello, >> >> >> While we do not generated new version for API (3.4.x)[1] yet[2], the >>"simplier" place for looking at available classes is maybe to look at >>modules into gen/lib! Note, without 'sphynx' for generating a new >>documentation, you can also run 'pyreverse' from 'pylint' package. >> >> $ pyreverse -A -S /home/blabla/trunk/src/gen/lib/*.py -o jpeg >> //svg file format sounds better under some environment// >> >> You can also install sphinx and to generate up-to-date API[3], then >>to contact the web site administrator for uploading the new API >>documentation. >> >> Note, I guess some modules are missing (related to 'user' class on >>report and some new features). I will try to update the current >>documentation references. >> >> >> About Gramplet design, there is a specific page[4], I suppose there >>is no change since 3.3, only some 'relations/calls' might be >>differents. >> >> >> Otherwise, the developers portal[5] and related links[6] can be >>useful when we are starting to look at gramps' code and behavior. >> >> >> [1] >>http://gramps-project.org/wiki/index.php?title=Using_database_API >> [2] >>http://gramps-project.org/wiki/index.php?title=Programming_guidelines#Docstrings >> [3] >>http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/docs/README.txt >> [4] http://gramps-project.org/wiki/index.php?title=Gramplets >> [5] http://gramps-project.org/wiki/index.php?title=Portal:Developers >> [6] >>http://gramps-project.org/wiki/index.php?title=Category:Developers/General >> >> >> I hope this could help. >> >> Regards, >> Jérôme >> >> >> --- En date de : Sam 18.2.12, Alan Eveson >><ala...@ph...> a écrit : >> >> De: Alan Eveson <ala...@ph...> >> Objet: Re: [Gramps-devel] Census Gramplet / GEPS 024 >> À: gra...@li... >> Date: Samedi 18 février 2012, 10h26 >> >> Hi All I had some free time yesterday to start to get to grips >>with the Census Gramplet / Geps024. I made pretty good progress in >>understanding how the gramplet works in 3.3 and doesn’t work in 3.4 >>with the introduction of citations and the demise of the source >>reference object. I’m starting to come up to speed with Python too! >>Not a very great speed yet – lol. I understand that all this may not >>be documented yet, or maybe I just can’t find it, but are the rules >>of inheritance documented anywhere so I can see how the classes all >>fit together in 3.4?Is there anywhere where I can get the details of >>all the interfaces exposed by the Citation object other than by >>digging through the code? Have the naming standards changed, so for >>example:Self.event.add_source_reference(self.source_ref) is fairly >>self explanatory, what would be the equivalent for a citation >>reference? Apologies if these questions seem a bit odd, but I’m >>jumping around >> between two versions of the code and learning Python at the same >>time. I may be getting confused! Alan -----La pièce >>jointe associée suit----- >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >>also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> -----La pièce jointe associée suit----- >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >>also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: jerome <rom...@ya...> - 2012-02-18 19:02:48
|
Alan, > Essentially I'd like the data from the census held in one place as a > transcript - separate from the family tree data. Yes, I like this too. This is also how most transcripts tools are working[1]. For testing, I had moved some simple edition forms into GtkBuilder file format[2] with basic python files. The "pre-alpha" set of tools was using this logic: separation between transcriptions and our genealogical data (both handled into Gramps). But to also commit seizure to DB, if need. It was only "pre/proof" experimentations and not the common Gramps user interface (ManagedWindow, icons[3]), but this was quickly generated with glade. If you have some interface ideas but you are not yet confortable with python and GTK, then glade[4] tool might help us. Later, the generated code could be also rewritten into python (gtk and bindings). > I'm making progress with > getting the Gramplet to work with 3.4 and citations. Great! Note, the DataEntry gramplet was also working with source references. Does someone tested it on 3.4 or trunk? [1] http://gramps-project.org/wiki/index.php?title=Talk:GEPS_024:_Certificates [2] http://www.gramps-project.org/bugs/view.php?id=5552 [3] http://gramps-project.org/wiki/index.php?title=Using_icons#How_to_use_an_Icon_in_GRAMPS [4] http://glade.gnome.org/ Jérôme --- En date de : Sam 18.2.12, al...@ev... <al...@ev...> a écrit : > De: al...@ev... <al...@ev...> > Objet: Re: [Gramps-devel] Census Gramplet / GEPS 024 > À: rom...@ya..., gra...@li... > Date: Samedi 18 février 2012, 18h36 > Hi Jerome > > Thanks for both of your replies. It's a lot to take on at > once! I'm going hrough all the links you sent me and it's > all very helpful. A couple there I hadn't found. I think I > understand the inheritance now and I'm making progress with > getting the Gramplet to work with 3.4 and citations. > > I'm also pondering how the data should be held. Essentially > I'd like the data from the census held in one place as a > transcript - separate from the family tree data. Then I want > to compare the transcript with the family tree and guide the > user through entering all the data into the tree. > > So, from the census date and the age of the person, I can > calculate a birth year which could both be used as an birth > event estimate for a new person, and as a check if a date > already exits in a birth event. > > Alan > > On Sat, 18 Feb 2012 18:20:26 +0100 > Jérôme <rom...@ya...> > wrote: > >> without 'sphynx' for generating a new > documentation > > > > Sorry, it is 'sphinx' ... > > > > I have quickly generated a new pseudo UML > representation of gen lib modules for next major release > (3.4.x)[1]. And tried to update documentation references for > gen.lib[2]. > > > > At a glance[3], 'CitationBase' replace 'SourceBase', > and 'Citation' replace 'SourceRef'... Tim gave better > migration links/samples/revision_numbers on GEPS_023[4]. > > > > > > > > [1] http://gramps-project.org/wiki/images/2/2e/API.svg > > [2] http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18922 > > [3] http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps34/docs/gen/gen_lib.rst?view=patch&r1=18922&r2=18921&pathrev=18922 > > [4] http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Deferred > > > > > > Welcome! > > > > > > PS: I cannot help more, I am also learning python with > Gramps... > > > > > > > > > > jerome a écrit : > >> Hello, > >> > >> > >> While we do not generated new version for API > (3.4.x)[1] yet[2], the "simplier" place for looking at > available classes is maybe to look at modules into gen/lib! > Note, without 'sphynx' for generating a new documentation, > you can also run 'pyreverse' from 'pylint' package. > >> > >> $ pyreverse -A -S > /home/blabla/trunk/src/gen/lib/*.py -o jpeg //svg file > format sounds better under some environment// > >> > >> You can also install sphinx and to generate > up-to-date API[3], then to contact the web site > administrator for uploading the new API documentation. > >> > >> Note, I guess some modules are missing (related to > 'user' class on report and some new features). I will try to > update the current documentation references. > >> > >> > >> About Gramplet design, there is a specific page[4], > I suppose there is no change since 3.3, only some > 'relations/calls' might be differents. > >> > >> > >> Otherwise, the developers portal[5] and related > links[6] can be useful when we are starting to look at > gramps' code and behavior. > >> > >> > >> [1] http://gramps-project.org/wiki/index.php?title=Using_database_API > >> [2] http://gramps-project.org/wiki/index.php?title=Programming_guidelines#Docstrings > >> [3] http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/docs/README.txt > >> [4] http://gramps-project.org/wiki/index.php?title=Gramplets > >> [5] http://gramps-project.org/wiki/index.php?title=Portal:Developers > >> [6] http://gramps-project.org/wiki/index.php?title=Category:Developers/General > >> > >> > >> I hope this could help. > >> > >> Regards, > >> Jérôme > >> > >> > >> --- En date de : Sam 18.2.12, Alan Eveson <ala...@ph...> > a écrit : > >> > >> De: Alan Eveson <ala...@ph...> > >> Objet: Re: [Gramps-devel] Census Gramplet / GEPS > 024 > >> À: gra...@li... > >> Date: Samedi 18 février 2012, 10h26 > >> > >> Hi All I had some free time yesterday > to start to get to grips with the Census Gramplet / > Geps024. I made pretty good progress in understanding > how the gramplet works in 3.3 and doesn’t work in 3.4 with > the introduction of citations and the demise of the source > reference object. I’m starting to come up to speed > with Python too! Not a very great speed yet – lol. I > understand that all this may not be documented yet, or maybe > I just can’t find it, but are the rules of inheritance > documented anywhere so I can see how the classes all fit > together in 3.4?Is there anywhere where I can get the > details of all the interfaces exposed by the Citation object > other than by digging through the code? Have the > naming standards changed, so for > example:Self.event.add_source_reference(self.source_ref) is > fairly self explanatory, what would be the equivalent for a > citation reference? Apologies if these questions seem > a bit odd, but I’m jumping around > >> between two versions of the code and learning > Python at the same time. I may be getting confused! > Alan -----La > pièce jointe associée suit----- > >> > >> > ------------------------------------------------------------------------------ > >> Virtualization & Cloud Management Using > Capacity Planning > >> Cloud computing makes use of virtualization - but > cloud computing also focuses on allowing computing to be > delivered as a service. > >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ > >> -----La pièce jointe associée suit----- > >> > >> _______________________________________________ > >> Gramps-devel mailing list > >> Gra...@li... > >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > >> > >> > ------------------------------------------------------------------------------ > >> Virtualization & Cloud Management Using > Capacity Planning > >> Cloud computing makes use of virtualization - but > cloud computing also focuses on allowing computing to be > delivered as a service. > >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ > >> _______________________________________________ > >> Gramps-devel mailing list > >> Gra...@li... > >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > |
From: Tim L. <guy...@gm...> - 2012-02-18 20:04:05
|
On 18 Feb 2012, at 09:26, gra...@li... wrote: > I had some free time yesterday to start to get to grips with the > Census > Gramplet / Geps024. I made pretty good progress in understanding > how the > gramplet works in 3.3 and doesn't work in 3.4 with the introduction of > citations and the demise of the source reference object. > > I'm starting to come up to speed with Python too! Not a very great > speed yet > - lol. > > I understand that all this may not be documented yet, or maybe I > just can't > find it, but are the rules of inheritance documented anywhere so I > can see > how the classes all fit together in 3.4? > > Is there anywhere where I can get the details of all the interfaces > exposed > by the Citation object other than by digging through the code? > > > > Have the naming standards changed, so for example: > > Self.event.add_source_reference(self.source_ref) is fairly self > explanatory, > what would be the equivalent for a citation reference? I wrote a guide in Dec 2011 to the main changes that are needed in code to take account of GEPS 023 here: http://gramps.1791082.n4.nabble.com/GEPS023-merged-into-trunk-tp4157519p4157519.html (long post - the changes you need to make are in the second half of the post). I have just added this to the wiki here: http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Changes_needed (1) I am absolutely delighted that you are looking at GEPS 024, because I think that improving the user interface for entering data is the next major change that needs to be made to Gramps. (2) While not wanting to discourage you in any way, I wonder whether you could separate the upgrading of the Census gramplet - to do the same thing it did before, but with citations - from anything more major to do with GEPS 024. (3) I make extensive use of the Census gramplet, and part of my motivation for implementing GEPS 023 was so that I could have a single citation of each household in a census, and store the scan of the census page in the citation. (As you will know, the census gramplet uses a single source for the whole of a given census i.e. 1841 UK Census is one source). (4) I am keen to get back to entering my family history into Gramps 3.4, hence keen that at least the existing functionality be available in a similar way to before!! |
From: Alan E. <ala...@ph...> - 2012-02-18 20:42:56
|
Hi Tim (1) I am absolutely delighted that you are looking at GEPS 024, because I think that improving the user interface for entering data is the next major change that needs to be made to Gramps. Yes, I found it a bit of a struggle at first - too good - too many options. I imported my tree from GEDCOM and quickly got lost. Then I started re-entering from Census using the gramplet, and found that much better, but I wanted the same for certificates - then I was pointed to GEPS 024. Bang on target. (2) While not wanting to discourage you in any way, I wonder whether you could separate the upgrading of the Census gramplet - to do the same thing it did before, but with citations - from anything more major to do with GEPS 024. I totally agree. I also want to get everyone else's opinions as to how they "translate" their census/certificates into Gramps records. I'll propose something and we'll chew over it. (3) I make extensive use of the Census gramplet, and part of my motivation for implementing GEPS 023 was so that I could have a single citation of each household in a census, and store the scan of the census page in the citation. (As you will know, the census gramplet uses a single source for the whole of a given census i.e. 1841 UK Census is one source). GEPS 023 makes complete sense to me. (4) I am keen to get back to entering my family history into Gramps 3.4, hence keen that at least the existing functionality be available in a similar way to before!! I hope I'm not treading on toes here. You could probably do it 100 times faster than me, but I really need Gramps to sort my tree out - There's a lot of research and info in there, but if I can just get into a really consistent form I'll discover a lot more. I've already made a couple of discoveries around info I already had, but didn't realise its significance. Just slam the brakes on if you think I'm going the wrong way. My plan is to get every tiny scrap of info out of census & certificates into Gramps in a consistent way and then "play" with it to analyse and try to get some sensible assumptions out that can take my research further. Off to read that post... A -----Original Message----- From: Tim Lyons [mailto:guy...@gm...] Sent: 18 February 2012 20:04 To: gra...@li... Cc: Alan Eveson Subject: Re: [Gramps-devel] Census Gramplet / GEPS 024 On 18 Feb 2012, at 09:26, gra...@li... wrote: > I had some free time yesterday to start to get to grips with the > Census Gramplet / Geps024. I made pretty good progress in > understanding how the gramplet works in 3.3 and doesn't work in 3.4 > with the introduction of citations and the demise of the source > reference object. > > I'm starting to come up to speed with Python too! Not a very great > speed yet > - lol. > > I understand that all this may not be documented yet, or maybe I just > can't find it, but are the rules of inheritance documented anywhere so > I can see how the classes all fit together in 3.4? > > Is there anywhere where I can get the details of all the interfaces > exposed by the Citation object other than by digging through the code? > > > > Have the naming standards changed, so for example: > > Self.event.add_source_reference(self.source_ref) is fairly self > explanatory, what would be the equivalent for a citation reference? I wrote a guide in Dec 2011 to the main changes that are needed in code to take account of GEPS 023 here: http://gramps.1791082.n4.nabble.com/GEPS023-merged-into-trunk-tp4157519p4157 519.html (long post - the changes you need to make are in the second half of the post). I have just added this to the wiki here: http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_fr om_large_sources#Changes_needed (1) I am absolutely delighted that you are looking at GEPS 024, because I think that improving the user interface for entering data is the next major change that needs to be made to Gramps. (2) While not wanting to discourage you in any way, I wonder whether you could separate the upgrading of the Census gramplet - to do the same thing it did before, but with citations - from anything more major to do with GEPS 024. (3) I make extensive use of the Census gramplet, and part of my motivation for implementing GEPS 023 was so that I could have a single citation of each household in a census, and store the scan of the census page in the citation. (As you will know, the census gramplet uses a single source for the whole of a given census i.e. 1841 UK Census is one source). (4) I am keen to get back to entering my family history into Gramps 3.4, hence keen that at least the existing functionality be available in a similar way to before!! |
From: Nick H. <nic...@ho...> - 2012-02-18 23:41:28
|
Alan, Thanks for taking an interest in the Census add-ons. Extra help is always appreciated. I made the GEPS 023 changes because they were quick for me to do. I don't always have time to make enhancements though. There are still many ways we could improve the census gramplet. Feel free to make suggestions or submit patches. Let me know if you have any questions. I am also pleased that you are looking at GEPS 024, and look forward to reading your ideas. Regards, Nick. On 18/02/12 20:42, Alan Eveson wrote: > Hi Tim > > (1) I am absolutely delighted that you are looking at GEPS 024, because I > think that improving the user interface for entering data is the next major > change that needs to be made to Gramps. > > Yes, I found it a bit of a struggle at first - too good - too many options. > I imported my tree from GEDCOM and quickly got lost. Then I started > re-entering from Census using the gramplet, and found that much better, but > I wanted the same for certificates - then I was pointed to GEPS 024. Bang on > target. > > (2) While not wanting to discourage you in any way, I wonder whether you > could separate the upgrading of the Census gramplet - to do the same thing > it did before, but with citations - from anything more major to do with GEPS > 024. > > I totally agree. I also want to get everyone else's opinions as to how they > "translate" their census/certificates into Gramps records. I'll propose > something and we'll chew over it. > > (3) I make extensive use of the Census gramplet, and part of my motivation > for implementing GEPS 023 was so that I could have a single citation of each > household in a census, and store the scan of the census page in the > citation. (As you will know, the census gramplet uses a single source for > the whole of a given census i.e. 1841 UK Census is one source). > > GEPS 023 makes complete sense to me. > > (4) I am keen to get back to entering my family history into Gramps 3.4, > hence keen that at least the existing functionality be available in a > similar way to before!! > > I hope I'm not treading on toes here. You could probably do it 100 times > faster than me, but I really need Gramps to sort my tree out - There's a lot > of research and info in there, but if I can just get into a really > consistent form I'll discover a lot more. I've already made a couple of > discoveries around info I already had, but didn't realise its significance. > Just slam the brakes on if you think I'm going the wrong way. > > My plan is to get every tiny scrap of info out of census& certificates into > Gramps in a consistent way and then "play" with it to analyse and try to get > some sensible assumptions out that can take my research further. > > Off to read that post... > > A > > > > -----Original Message----- > From: Tim Lyons [mailto:guy...@gm...] > Sent: 18 February 2012 20:04 > To: gra...@li... > Cc: Alan Eveson > Subject: Re: [Gramps-devel] Census Gramplet / GEPS 024 > > > On 18 Feb 2012, at 09:26, gra...@li... > wrote: > >> I had some free time yesterday to start to get to grips with the >> Census Gramplet / Geps024. I made pretty good progress in >> understanding how the gramplet works in 3.3 and doesn't work in 3.4 >> with the introduction of citations and the demise of the source >> reference object. >> >> I'm starting to come up to speed with Python too! Not a very great >> speed yet >> - lol. >> >> I understand that all this may not be documented yet, or maybe I just >> can't find it, but are the rules of inheritance documented anywhere so >> I can see how the classes all fit together in 3.4? >> >> Is there anywhere where I can get the details of all the interfaces >> exposed by the Citation object other than by digging through the code? >> >> >> >> Have the naming standards changed, so for example: >> >> Self.event.add_source_reference(self.source_ref) is fairly self >> explanatory, what would be the equivalent for a citation reference? > I wrote a guide in Dec 2011 to the main changes that are needed in code to > take account of GEPS 023 here: > http://gramps.1791082.n4.nabble.com/GEPS023-merged-into-trunk-tp4157519p4157 > 519.html > > (long post - the changes you need to make are in the second half of the > post). > I have just added this to the wiki here: > http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_fr > om_large_sources#Changes_needed > > (1) I am absolutely delighted that you are looking at GEPS 024, because I > think that improving the user interface for entering data is the next major > change that needs to be made to Gramps. > > (2) While not wanting to discourage you in any way, I wonder whether you > could separate the upgrading of the Census gramplet - to do the same thing > it did before, but with citations - from anything more major to do with GEPS > 024. > > (3) I make extensive use of the Census gramplet, and part of my motivation > for implementing GEPS 023 was so that I could have a single citation of each > household in a census, and store the scan of the census page in the > citation. (As you will know, the census gramplet uses a single source for > the whole of a given census i.e. 1841 UK Census is one source). > > (4) I am keen to get back to entering my family history into Gramps 3.4, > hence keen that at least the existing functionality be available in a > similar way to before!! > > > > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Nick H. <nic...@ho...> - 2012-02-18 23:21:36
|
Tim, Thanks for reminding me about this. I have made the GEPS 023 changes for the Census add-ons (r1217). I'll check to see if there are any other outstanding issues before updating the version number. Now we have citation objects there are two enhancements that would be easy to implement: 1. Allow the user to add a census image to the citation object. 2. Generate a transcript from the census data and add it as a note to the citation object. We should be able to do this for the v3.4 release. Nick. On 18/02/12 20:03, Tim Lyons wrote: > On 18 Feb 2012, at 09:26, gra...@li... > wrote: > >> I had some free time yesterday to start to get to grips with the >> Census >> Gramplet / Geps024. I made pretty good progress in understanding >> how the >> gramplet works in 3.3 and doesn't work in 3.4 with the introduction of >> citations and the demise of the source reference object. >> >> I'm starting to come up to speed with Python too! Not a very great >> speed yet >> - lol. >> >> I understand that all this may not be documented yet, or maybe I >> just can't >> find it, but are the rules of inheritance documented anywhere so I >> can see >> how the classes all fit together in 3.4? >> >> Is there anywhere where I can get the details of all the interfaces >> exposed >> by the Citation object other than by digging through the code? >> >> >> >> Have the naming standards changed, so for example: >> >> Self.event.add_source_reference(self.source_ref) is fairly self >> explanatory, >> what would be the equivalent for a citation reference? > I wrote a guide in Dec 2011 to the main changes that are needed in > code to take account of GEPS 023 here: > http://gramps.1791082.n4.nabble.com/GEPS023-merged-into-trunk-tp4157519p4157519.html > > (long post - the changes you need to make are in the second half of > the post). > I have just added this to the wiki here: > http://www.gramps-project.org/wiki/index.php?title=GEPS_023:_Storing_data_from_large_sources#Changes_needed > > (1) I am absolutely delighted that you are looking at GEPS 024, > because I think that improving the user interface for entering data is > the next major change that needs to be made to Gramps. > > (2) While not wanting to discourage you in any way, I wonder whether > you could separate the upgrading of the Census gramplet - to do the > same thing it did before, but with citations - from anything more > major to do with GEPS 024. > > (3) I make extensive use of the Census gramplet, and part of my > motivation for implementing GEPS 023 was so that I could have a single > citation of each household in a census, and store the scan of the > census page in the citation. (As you will know, the census gramplet > uses a single source for the whole of a given census i.e. 1841 UK > Census is one source). > > (4) I am keen to get back to entering my family history into Gramps > 3.4, hence keen that at least the existing functionality be available > in a similar way to before!! > > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Tim L. <guy...@gm...> - 2012-02-19 00:24:32
|
On 18 Feb 2012, at 23:41, gra...@li... wrote: > Looking at the options again, I don't think we need any changes. > There > is already an option to just notify updates only. I have been using > the > defaults, and with an internet connection, I haven't had any > problems at > all. Most of the suggestions are just refinements to something that > works well already. Sorry, but I don't think it does work well enough already. (1) If you don't have an internet connection, apparently start-up hangs to 10 minutes. (I don't know this from personal experience because I do have a connection, so this doesn't bother me). (2) If you don't install a particular add-on the first time Gramps starts and asks you, there is no way to do so later (unless the add-on changes) because 'Check now' only checks for New and/or Updated add- ons. This does affect me, because I didn't chose to install ALL the add-on when I first started, so now there is no way to get at the ones I didn't install. I think this is a real problem, and I would love it to be fixed! The Plugin Manager 'Refresh Addon List' didn't work at all when i was running trunk. Now I am running gramps34 branch, it has started working, but I gather that this looks in a different place from the Preferences 'Check now', so presumably won't give the same add-ons. |
From: Rob H. <rob...@gm...> - 2012-02-19 02:35:10
|
Tim, and Nick: I agree with the both of you on different points that you have made in this email... I do believe that he timeout problem is something that needs to be dealt with right now and backported to Gramps-3.4.x... I also do not install all of the plugins at the first time of installing the software! I would like to have the option of downloading/ installing other add-ons at a later time... Sincerely yours, Rob G. Healey On Sat, Feb 18, 2012 at 4:24 PM, Tim Lyons <guy...@gm...> wrote: > On 18 Feb 2012, at 23:41, gra...@li... > wrote: > > > Looking at the options again, I don't think we need any changes. > > There > > is already an option to just notify updates only. I have been using > > the > > defaults, and with an internet connection, I haven't had any > > problems at > > all. Most of the suggestions are just refinements to something that > > works well already. > > > Sorry, but I don't think it does work well enough already. > > (1) If you don't have an internet connection, apparently start-up > hangs to 10 minutes. (I don't know this from personal experience > because I do have a connection, so this doesn't bother me). > > (2) If you don't install a particular add-on the first time Gramps > starts and asks you, there is no way to do so later (unless the add-on > changes) because 'Check now' only checks for New and/or Updated add- > ons. This does affect me, because I didn't chose to install ALL the > add-on when I first started, so now there is no way to get at the ones > I didn't install. I think this is a real problem, and I would love it > to be fixed! > > The Plugin Manager 'Refresh Addon List' didn't work at all when i was > running trunk. Now I am running gramps34 branch, it has started > working, but I gather that this looks in a different place from the > Preferences 'Check now', so presumably won't give the same add-ons. > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Sincerely yours, Rob G. Healey |
From: Tim L. <guy...@gm...> - 2012-02-19 11:57:14
|
Nick, On 18 Feb 2012, at 23:41, Nick Hall <nic...@ho...> wrote: > Now we have citation objects there are two enhancements that would be > easy to implement: > > 1. Allow the user to add a census image to the citation object. > 2. Generate a transcript from the census data and add it as a note to > the citation object. > > We should be able to do this for the v3.4 release. I think these would be excellent enhancements - GESP 023 is of course so that it is possible to store the census scan in the Citation object. Any chance you would be able to do these two soon? Regards, Tim. |
From: Nick H. <nic...@ho...> - 2012-02-19 14:31:42
|
On 19/02/12 11:57, Tim Lyons wrote: > Nick, > > On 18 Feb 2012, at 23:41, Nick Hall <nic...@ho...> wrote: > >> Now we have citation objects there are two enhancements that would be >> easy to implement: >> >> 1. Allow the user to add a census image to the citation object. >> 2. Generate a transcript from the census data and add it as a note to >> the citation object. >> >> We should be able to do this for the v3.4 release. > > I think these would be excellent enhancements - GESP 023 is of course > so that it is possible to store the census scan in the Citation object. > Yes. I didn't want to add this before we implemented Citation objects. The choice before was to use either the Event object or the Source object - neither of these was a good option and I didn't want to change things in the future. > Any chance you would be able to do these two soon? I should be able to find some time but I haven't thought about the design yet. Have you had any thoughts about the interface? Nick. > > Regards, > Tim. > > |
From: Tim L. <guy...@gm...> - 2012-02-19 15:48:46
|
On 19 Feb 2012, at 14:31, Nick Hall wrote: > On 19/02/12 11:57, Tim Lyons wrote: >> Nick, >> >> On 18 Feb 2012, at 23:41, Nick Hall <nic...@ho...> wrote: >> >>> Now we have citation objects there are two enhancements that would >>> be >>> easy to implement: >>> >>> 1. Allow the user to add a census image to the citation object. >>> 2. Generate a transcript from the census data and add it as a note >>> to >>> the citation object. >>> >>> We should be able to do this for the v3.4 release. >> >> I think these would be excellent enhancements - GESP 023 is of >> course so that it is possible to store the census scan in the >> Citation object. >> > > Yes. I didn't want to add this before we implemented Citation > objects. The choice before was to use either the Event object or > the Source object - neither of these was a good option and I didn't > want to change things in the future. > > >> Any chance you would be able to do these two soon? > > I should be able to find some time but I haven't thought about the > design yet. > > Have you had any thoughts about the interface? I haven't looked at the census gramplet recently, but I assumed just a simple button that would bring up a media object selector (no need to start my scanner for me :-) Adding a note to the Citation for a transcript would just do that. Tim. |
From: Nick H. <nic...@ho...> - 2012-02-19 14:40:08
|
On 19/02/12 00:24, Tim Lyons wrote: > On 18 Feb 2012, at 23:41, gra...@li... > wrote: > >> Looking at the options again, I don't think we need any changes. There >> is already an option to just notify updates only. I have been using the >> defaults, and with an internet connection, I haven't had any problems at >> all. Most of the suggestions are just refinements to something that >> works well already. > > > Sorry, but I don't think it does work well enough already. > > (1) If you don't have an internet connection, apparently start-up > hangs to 10 minutes. (I don't know this from personal experience > because I do have a connection, so this doesn't bother me). > Did you read the first part of my email? Doesn't urllib2 provide a timeout parameter that will fix this bug? For the future, I think that the non-GUI part of the code that checks for new updates should run in a separate thread. > (2) If you don't install a particular add-on the first time Gramps > starts and asks you, there is no way to do so later (unless the add-on > changes) because 'Check now' only checks for New and/or Updated > add-ons. This does affect me, because I didn't chose to install ALL > the add-on when I first started, so now there is no way to get at the > ones I didn't install. I think this is a real problem, and I would > love it to be fixed! > > The Plugin Manager 'Refresh Addon List' didn't work at all when i was > running trunk. Now I am running gramps34 branch, it has started > working, but I gather that this looks in a different place from the > Preferences 'Check now', so presumably won't give the same add-ons. > > My own opinion is to keep the update code separate from the add/remove code. We should remove the ability to add new plugins from the update code. The Plugin Manager should be fixed so that we can add new plugins. In the future, it would be nice to enhance the Plugin Manager. Perhaps we could add pictures and descriptions of the plugins? Nick. |
From: Tim L. <guy...@gm...> - 2012-02-19 15:42:08
|
On 19 Feb 2012, at 14:40, Nick Hall wrote: > On 19/02/12 00:24, Tim Lyons wrote: >> On 18 Feb 2012, at 23:41, gramps-devel- >> re...@li... wrote: >> >>> Looking at the options again, I don't think we need any changes. >>> There >>> is already an option to just notify updates only. I have been >>> using the >>> defaults, and with an internet connection, I haven't had any >>> problems at >>> all. Most of the suggestions are just refinements to something that >>> works well already. >> >> >> Sorry, but I don't think it does work well enough already. >> >> (1) If you don't have an internet connection, apparently start-up >> hangs to 10 minutes. (I don't know this from personal experience >> because I do have a connection, so this doesn't bother me). >> > > Did you read the first part of my email? Doesn't urllib2 provide a > timeout parameter that will fix this bug? I'm not sure that a timeout parameter would make any difference. It seems that it times out after 10 minutes anyway (and if I understand what has been written in the mailing list, this was actually changed from 3 minutes, so could presumably be changed back to a smaller time if wanted). The problem is that it does the check at all even on the first run. > For the future, I think that the non-GUI part of the code that > checks for new updates should run in a separate thread. > > >> (2) If you don't install a particular add-on the first time Gramps >> starts and asks you, there is no way to do so later (unless the add- >> on changes) because 'Check now' only checks for New and/or Updated >> add-ons. This does affect me, because I didn't chose to install ALL >> the add-on when I first started, so now there is no way to get at >> the ones I didn't install. I think this is a real problem, and I >> would love it to be fixed! >> >> The Plugin Manager 'Refresh Addon List' didn't work at all when i >> was running trunk. Now I am running gramps34 branch, it has started >> working, but I gather that this looks in a different place from the >> Preferences 'Check now', so presumably won't give the same add-ons. >> >> > > My own opinion is to keep the update code separate from the add/ > remove code. We should remove the ability to add new plugins from > the update code. Well then even more so should the initial update check on first run be removed. However, from the user point of view, having separate interfaces to add new plugins and update existing ones is very confusing. Suppose he decides to add a new plugin, and does it, but doesn't get told that another existing (perhaps related) plugin is out of date. Or he updates his plugin, but doesn't get told there is a new one that has just been added to the repository. > The Plugin Manager should be fixed so that we can add new plugins. (You can add new plugins from the plugin manager, the only problem is apparently where it goes to look for them). I was hoping that someone who had already looked at the code would fix it, because I have not looked at the code at all, and am just assuming how it works from what has been said in the mailing list and how it doesn't work for me at the moment. > In the future, it would be nice to enhance the Plugin Manager. > Perhaps we could add pictures and descriptions of the plugins? Tim. |
From: Tim L. <guy...@gm...> - 2012-02-21 18:26:37
|
Amazing what you find in the code you didn't know existed! On 19 Feb 2012, at 14:40, Nick Hall wrote: > On 19/02/12 00:24, Tim Lyons wrote: >> On 18 Feb 2012, at 23:41, gramps-devel- >> re...@li... wrote: >> (2) If you don't install a particular add-on the first time Gramps >> starts and asks you, there is no way to do so later (unless the add- >> on changes) because 'Check now' only checks for New and/or Updated >> add-ons. This does affect me, because I didn't chose to install ALL >> the add-on when I first started, so now there is no way to get at >> the ones I didn't install. I think this is a real problem, and I >> would love it to be fixed! OK, so I thought I'd have a look at the code to see what it would take to get it working the way I wanted. And I found 'behavior.do-not-show- previously-seen-updates' which seemed to allow me to get access to addons I had not asked for the first time I started Gramps. I found the setting in gramps.ini, and thought perhaps it was a preset and I needed to change it in gramps.ini. But then I found that configure.py sets up a CheckButton which allows the behaviour to be changed. And lo and behold, there is a check box in the preferences dialogue which allows just what I wanted "Do not ask about previously notified addons". By unsetting this and pressing 'Check now' it gives me a list of all the available addons that I haven't already installed. Moreover, it neatly separates out New addons from Updated addons, (just as I had hoped for in a previous post). >> >> The Plugin Manager 'Refresh Addon List' didn't work at all when i >> was running trunk. Now I am running gramps34 branch, it has started >> working, but I gather that this looks in a different place from the >> Preferences 'Check now', so presumably won't give the same add-ons. >> >> > > My own opinion is to keep the update code separate from the add/ > remove code. We should remove the ability to add new plugins from > the update code. The Plugin Manager should be fixed so that we can > add new plugins. > Now I am really confused. Now that I understand that the Preferences 'Check now' can display both updates and new plugins, why would you want the separate them? What is a new addon today becomes an update to check tomorrow, so it makes sense for them both to be together in one place, and in one piece of code. It also makes sense from the user's point of view to deal with addons in one place. Having both the viewmanager.check_for_updates code and the gui/plug/ _windows.py code is a real mess. One searches the SVN gramps-addons repository, while the other looks in the wiki. Hence they get different addons. There are some that appear in the svn but not in the wiki, and others (I think) that appear in the wiki, but not in the svn. The wiki route does not support updates to the addons, but the svn does. The preferences does not support reloading addons, nor does it provide a permanent display showing the reasons for failure. I'd remove the Install Addons tab from the Plugin Manager. This would retain the Loaded Plugins page to show any errors in Plugin loading, and would also retain the (all important) Reload button at the bottom to reload any plugins that had been (manually) updated. I'd also remove the last (download) column in the wiki, to avoid confusion. > In the future, it would be nice to enhance the Plugin Manager. > Perhaps we could add pictures and descriptions of the plugins? > Yes, that would be nice. In the meantime, retaining the wiki information BUT NOT AS THE DEFINITIVE SOURCE will have to do. >>> Looking at the options again, I don't think we need any changes. >>> There >>> is already an option to just notify updates only. I have been >>> using the >>> defaults, and with an internet connection, I haven't had any >>> problems at >>> all. Most of the suggestions are just refinements to something that >>> works well already. >> >> >> Sorry, but I don't think it does work well enough already. >> >> (1) If you don't have an internet connection, apparently start-up >> hangs to 10 minutes. (I don't know this from personal experience >> because I do have a connection, so this doesn't bother me). >> > > Did you read the first part of my email? Doesn't urllib2 provide a > timeout parameter that will fix this bug? > > For the future, I think that the non-GUI part of the code that > checks for new updates should run in a separate thread. I don't think it matters much, so long as Gramps does not attempt to do the check the first time it starts up. Conclusion: My point (2) is already provided!! (It just needs to be mentioned in the user guide, so that people have a chance to discover it). My point number (1) can be solved by changing the default for register('behavior.check-for-updates', 2) in config.py from 2 to 0. This should mean that on initially starting Gramps, it will not hang waiting for the internet (the original problem that started this thread). Subsequently once the user adds an addon, the user can decide how often he wants to check for updates. Having both the preferences check and the Plugin Manager both present is a real mess. I'd remove the Install Addons tab from the Plugin Manager. I presume this would retain the Loaded Plugins page to show any errors in Plugin loading, and would also retain the (all important) Reload button at the bottom to reload any plugins that had been (manually) updated. I'd also remove the last (download) column in the wiki, to avoid confusion. Tim. |
From: jerome <rom...@ya...> - 2012-02-22 14:29:33
|
Hello Alan, > the introduction of citations and the demise of the source reference > object. I’m starting to come up to speed with Python too! Not a very > great speed yet – lol. I understand that all this may not be documented > yet, or maybe I just can’t find it, but are the rules of inheritance > documented anywhere so I can see how the classes all fit together in 3.4? Note, this is not related to classes but objects self ! I often try/need to generate something like a image for the database design between two major versions... The most accessible entry to the complete data is (for me) the Gramps XML file format[1]. This year, I was wrong about new citation/source relations. Tim has placed the light where I should looked and I guess it is now clearer. :) If this could help someone else or any others projects for a next Gramps XML file format support, I listed something like available (XML) paths into one textual file[2]. I could have forgotten one or two note object references but it is just a simple alternate overview of current interraction between objects via a simple 'path/uri' navigation/breadcrumb. [1] http://gramps-project.org/wiki/index.php?title=XML [2] http://gramps-project.org/wiki/images/5/50/Xpaths.gz regards, Jérôme --- En date de : Sam 18.2.12, Alan Eveson <ala...@ph...> a écrit : De: Alan Eveson <ala...@ph...> Objet: Re: [Gramps-devel] Census Gramplet / GEPS 024 À: gra...@li... Date: Samedi 18 février 2012, 10h26 Hi All I had some free time yesterday to start to get to grips with the Census Gramplet / Geps024. I made pretty good progress in understanding how the gramplet works in 3.3 and doesn’t work in 3.4 with the introduction of citations and the demise of the source reference object. I’m starting to come up to speed with Python too! Not a very great speed yet – lol. I understand that all this may not be documented yet, or maybe I just can’t find it, but are the rules of inheritance documented anywhere so I can see how the classes all fit together in 3.4?Is there anywhere where I can get the details of all the interfaces exposed by the Citation object other than by digging through the code? Have the naming standards changed, so for example:Self.event.add_source_reference(self.source_ref) is fairly self explanatory, what would be the equivalent for a citation reference? Apologies if these questions seem a bit odd, but I’m jumping around between two versions of the code and learning Python at the same time. I may be getting confused! Alan -----La pièce jointe associée suit----- ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ -----La pièce jointe associée suit----- _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Nick H. <nic...@ho...> - 2012-02-23 18:37:40
|
Tim, Please don't interpret my comments as being over-critical. In general, I like the way that the plugin management has been implemented, and I appreciate the work that has been done. This was a great addition to Gramps. I had only a few minor comments: 1. That ideally communications should be handled in a separate thread. But any practical solution is fine by me. 2. That only updates, not new plugins should be checked at startup, before the UI is loaded. This would be consistent with other applications. I note that this is configurable anyway (hence only another minor comment). I don't think that a new user wants to be notified of new plugins before they even see the UI. 3. I can see improvements that could be made to the Plugin Manager. Again though, I don't see that this is important enough for me to devote any time to it. Nick. On 21/02/12 18:26, Tim Lyons wrote: > Amazing what you find in the code you didn't know existed! > > > On 19 Feb 2012, at 14:40, Nick Hall wrote: > >> On 19/02/12 00:24, Tim Lyons wrote: >>> On 18 Feb 2012, at 23:41, gra...@li... >>> wrote: >>> (2) If you don't install a particular add-on the first time Gramps >>> starts and asks you, there is no way to do so later (unless the >>> add-on changes) because 'Check now' only checks for New and/or >>> Updated add-ons. This does affect me, because I didn't chose to >>> install ALL the add-on when I first started, so now there is no way >>> to get at the ones I didn't install. I think this is a real problem, >>> and I would love it to be fixed! > > OK, so I thought I'd have a look at the code to see what it would take > to get it working the way I wanted. And I found > 'behavior.do-not-show-previously-seen-updates' which seemed to allow > me to get access to addons I had not asked for the first time I > started Gramps. I found the setting in gramps.ini, and thought perhaps > it was a preset and I needed to change it in gramps.ini. But then I > found that configure.py sets up a CheckButton which allows the > behaviour to be changed. And lo and behold, there is a check box in > the preferences dialogue which allows just what I wanted "Do not ask > about previously notified addons". By unsetting this and pressing > 'Check now' it gives me a list of all the available addons that I > haven't already installed. Moreover, it neatly separates out New > addons from Updated addons, (just as I had hoped for in a previous post). > > >>> >>> The Plugin Manager 'Refresh Addon List' didn't work at all when i >>> was running trunk. Now I am running gramps34 branch, it has started >>> working, but I gather that this looks in a different place from the >>> Preferences 'Check now', so presumably won't give the same add-ons. >>> >>> >> >> My own opinion is to keep the update code separate from the >> add/remove code. We should remove the ability to add new plugins >> from the update code. The Plugin Manager should be fixed so that we >> can add new plugins. >> > > Now I am really confused. Now that I understand that the Preferences > 'Check now' can display both updates and new plugins, why would you > want the separate them? What is a new addon today becomes an update to > check tomorrow, so it makes sense for them both to be together in one > place, and in one piece of code. It also makes sense from the user's > point of view to deal with addons in one place. > > Having both the viewmanager.check_for_updates code and the > gui/plug/_windows.py code is a real mess. One searches the SVN > gramps-addons repository, while the other looks in the wiki. Hence > they get different addons. There are some that appear in the svn but > not in the wiki, and others (I think) that appear in the wiki, but not > in the svn. The wiki route does not support updates to the addons, but > the svn does. The preferences does not support reloading addons, nor > does it provide a permanent display showing the reasons for failure. > > I'd remove the Install Addons tab from the Plugin Manager. This would > retain the Loaded Plugins page to show any errors in Plugin loading, > and would also retain the (all important) Reload button at the bottom > to reload any plugins that had been (manually) updated. I'd also > remove the last (download) column in the wiki, to avoid confusion. > >> In the future, it would be nice to enhance the Plugin Manager. >> Perhaps we could add pictures and descriptions of the plugins? >> > Yes, that would be nice. In the meantime, retaining the wiki > information BUT NOT AS THE DEFINITIVE SOURCE will have to do. > > >>>> Looking at the options again, I don't think we need any changes. >>>> There >>>> is already an option to just notify updates only. I have been >>>> using the >>>> defaults, and with an internet connection, I haven't had any >>>> problems at >>>> all. Most of the suggestions are just refinements to something that >>>> works well already. >>> >>> >>> Sorry, but I don't think it does work well enough already. >>> >>> (1) If you don't have an internet connection, apparently start-up >>> hangs to 10 minutes. (I don't know this from personal experience >>> because I do have a connection, so this doesn't bother me). >>> >> >> Did you read the first part of my email? Doesn't urllib2 provide a >> timeout parameter that will fix this bug? >> >> For the future, I think that the non-GUI part of the code that checks >> for new updates should run in a separate thread. > > I don't think it matters much, so long as Gramps does not attempt to > do the check the first time it starts up. > > > > Conclusion: > > My point (2) is already provided!! (It just needs to be mentioned in > the user guide, so that people have a chance to discover it). > > My point number (1) can be solved by changing the default for > register('behavior.check-for-updates', 2) in config.py from 2 to 0. > This should mean that on initially starting Gramps, it will not hang > waiting for the internet (the original problem that started this > thread). Subsequently once the user adds an addon, the user can decide > how often he wants to check for updates. > > Having both the preferences check and the Plugin Manager both present > is a real mess. I'd remove the Install Addons tab from the Plugin > Manager. I presume this would retain the Loaded Plugins page to show > any errors in Plugin loading, and would also retain the (all > important) Reload button at the bottom to reload any plugins that had > been (manually) updated. I'd also remove the last (download) column in > the wiki, to avoid confusion. > > Tim. > > |
From: Tim L. <guy...@gm...> - 2012-02-23 19:43:29
|
On 23 Feb 2012, at 18:37, Nick Hall wrote: > Tim, > > Please don't interpret my comments as being over-critical. In > general, I like the way that the plugin management has been > implemented, and I appreciate the work that has been done. This was > a great addition to Gramps. If you mean the facility under Preferences, I very much agree. > I had only a few minor comments: > > 1. That ideally communications should be handled in a separate > thread. But any practical solution is fine by me. > > 2. That only updates, not new plugins should be checked at startup, > before the UI is loaded. This would be consistent with other > applications. I note that this is configurable anyway (hence only > another minor comment). I don't think that a new user wants to be > notified of new plugins before they even see the UI. I agree. There is no point in notifying new users about new plugins before they have even seen the UI. Unfortunately, that is exactly what it does at the moment! The default is to check for new and updated addons once a week, and for new users this means on starting. Just changing it to check for updated addons doesn't work because it reads the addons listing URL before discovering that there are no addons already installed. I would therefore like to change the defaults to 'updated addons only' and [initially] check never. That way, it won't be a problem for new users. When a user adds a plugin, he can decide how often he wants to check for updates, and whether he wants to check for new addons. > > 3. I can see improvements that could be made to the Plugin Manager. > Again though, I don't see that this is important enough for me to > devote any time to it. Depends which plugin manager you mean. At the moment there are two, one in preferences, the other under Help->Plugin Manager. The only change I would like to make is to remove the capability to add new plugins from the Help->Plugin Manager. That would remove all the confusion about two different ways of handling plugins. So, does anyone mind if I make the following changes to gramps34? Regards, Tim. Index: src/gui/plug/_windows.py =================================================================== --- src/gui/plug/_windows.py (revision 18947) +++ src/gui/plug/_windows.py (working copy) @@ -264,8 +264,8 @@ hbutbox.add(self.__refresh_btn) self.__refresh_btn.connect('clicked', self.__refresh_addon_list) install_page.pack_start(hbutbox, expand=False, padding=5) - notebook.append_page(install_page, - tab_label=gtk.Label(_('Install Addons'))) + # notebook.append_page(install_page, + # tab_label=gtk.Label(_('Install Addons'))) #add the notebook to the window self.window.vbox.add(notebook) Index: src/config.py =================================================================== --- src/config.py (revision 18947) +++ src/config.py (working copy) @@ -128,8 +128,8 @@ register('behavior.autoload', False) register('behavior.avg-generation-gap', 20) register('behavior.betawarn', False) -register('behavior.check-for-updates', 2) -register('behavior.check-for-update-types', ["update", "new"]) +register('behavior.check-for-updates', 0) +register('behavior.check-for-update-types', ["new"]) register('behavior.last-check-for-updates', "1970/01/01") register('behavior.previously-seen-updates', []) register('behavior.do-not-show-previously-seen-updates', True) |
From: Doug B. <dou...@gm...> - 2012-02-23 19:55:26
|
On Thu, Feb 23, 2012 at 2:43 PM, Tim Lyons <guy...@gm...> wrote: > > On 23 Feb 2012, at 18:37, Nick Hall wrote: > >> Tim, >> >> Please don't interpret my comments as being over-critical. In general, I >> like the way that the plugin management has been implemented, and I >> appreciate the work that has been done. This was a great addition to >> Gramps. > > > If you mean the facility under Preferences, I very much agree. > > >> I had only a few minor comments: >> >> 1. That ideally communications should be handled in a separate thread. >> But any practical solution is fine by me. >> >> 2. That only updates, not new plugins should be checked at startup, before >> the UI is loaded. This would be consistent with other applications. I note >> that this is configurable anyway (hence only another minor comment). I >> don't think that a new user wants to be notified of new plugins before they >> even see the UI. > > > I agree. There is no point in notifying new users about new plugins before > they have even seen the UI. Unfortunately, that is exactly what it does at > the moment! > > The default is to check for new and updated addons once a week, and for new > users this means on starting. > > Just changing it to check for updated addons doesn't work because it reads > the addons listing URL before discovering that there are no addons already > installed. > > I would therefore like to change the defaults to 'updated addons only' and > [initially] check never. That way, it won't be a problem for new users. When > a user adds a plugin, he can decide how often he wants to check for updates, > and whether he wants to check for new addons. > > >> >> 3. I can see improvements that could be made to the Plugin Manager. Again >> though, I don't see that this is important enough for me to devote any time >> to it. > > > Depends which plugin manager you mean. At the moment there are two, one in > preferences, the other under Help->Plugin Manager. > > The only change I would like to make is to remove the capability to add new > plugins from the Help->Plugin Manager. That would remove all the confusion > about two different ways of handling plugins. > > > So, does anyone mind if I make the following changes to gramps34? I don't mind changing the defaults of when and what to check. (I was the one who set them as is, and I don't feel too strongly about it. I do think that there will be some people that never discover the addons, but we can do other things to try to help on that front.) The other change on Plugin Manager should be oked by others, such as Benny. I think it would be fine, but it will require those that want to manually install a package to literally copy it into the right place. Eventually, we should replicate all of the Plugin Manager/wikipage functionality in the new Preference-based system. It would be great if each addon had a wiki page, thumbnail, and could be hidden/installed/removed from there. Also, the listing on the wiki was a nice feature. I bet we can do that programmatically now, even in different languages. -Doug > Regards, > Tim. > > > Index: src/gui/plug/_windows.py > =================================================================== > --- src/gui/plug/_windows.py (revision 18947) > +++ src/gui/plug/_windows.py (working copy) > @@ -264,8 +264,8 @@ > hbutbox.add(self.__refresh_btn) > self.__refresh_btn.connect('clicked', self.__refresh_addon_list) > install_page.pack_start(hbutbox, expand=False, padding=5) > - notebook.append_page(install_page, > - tab_label=gtk.Label(_('Install Addons'))) > + # notebook.append_page(install_page, > + # tab_label=gtk.Label(_('Install Addons'))) > > #add the notebook to the window > self.window.vbox.add(notebook) > Index: src/config.py > =================================================================== > --- src/config.py (revision 18947) > +++ src/config.py (working copy) > @@ -128,8 +128,8 @@ > register('behavior.autoload', False) > register('behavior.avg-generation-gap', 20) > register('behavior.betawarn', False) > -register('behavior.check-for-updates', 2) > -register('behavior.check-for-update-types', ["update", "new"]) > +register('behavior.check-for-updates', 0) > +register('behavior.check-for-update-types', ["new"]) > register('behavior.last-check-for-updates', "1970/01/01") > register('behavior.previously-seen-updates', []) > register('behavior.do-not-show-previously-seen-updates', True) > > |
From: Tim L. <guy...@gm...> - 2012-02-23 22:33:30
|
Doug, Thanks for your reply. On 23 Feb 2012, at 19:55, Doug Blank wrote: > On Thu, Feb 23, 2012 at 2:43 PM, Tim Lyons <guy...@gm...> > wrote: >> >> On 23 Feb 2012, at 18:37, Nick Hall wrote: >> >> I would therefore like to change the defaults to 'updated addons >> only' and >> [initially] check never. That way, it won't be a problem for new >> users. When >> a user adds a plugin, he can decide how often he wants to check for >> updates, >> and whether he wants to check for new addons. > I don't mind changing the defaults of when and what to check. (I was > the one who set them as is, and I don't feel too strongly about it. I > do think that there will be some people that never discover the > addons, but we can do other things to try to help on that front.) OK, done. > > The other change on Plugin Manager should be oked by others, such as > Benny. Benny, is that OK? > I think it would be fine, but it will require those that want > to manually install a package to literally copy it into the right > place. Sorry, I don't understand. The Help->Plugin Manager is not about manually installing plugins, it is about automatically installing plugins from the wiki page (which I think unnecessarily provides a different view on what addons exist). If you wanted to manually install a plugin, you had to put it manually in the right place, and that doesn't change. > Eventually, we should replicate all of the Plugin > Manager/wikipage functionality in the new Preference-based system. It > would be great if each addon had a wiki page, thumbnail, Yes, I suggest keeping the wiki page as it is for now, just removing the link to the zip file. > and could be > hidden/installed/removed from there. The trouble with using the wiki page for installing addons (I presume you mean using the page as information read by the application, rather than clicking somewhere on the page to have an addon installed) is that there would then be two sources of the truth about which addons existed - never a good idea. I think that separation of installation (via the svn repository) and documentation (via the wiki) is what is needed. After all, that corresponds with the situation for the Gramps application itself. That is why I suggest removing the last column (containing a link to the svn file) from the wiki page. > Also, the listing on the wiki was > a nice feature. I bet we can do that programmatically now, even in > different languages As I say, the documentation on the wiki page should be maintained independently from the code. > -Doug > >> Regards, >> Tim. >> >> >> Index: src/gui/plug/_windows.py >> =================================================================== >> --- src/gui/plug/_windows.py (revision 18947) >> +++ src/gui/plug/_windows.py (working copy) >> @@ -264,8 +264,8 @@ >> hbutbox.add(self.__refresh_btn) >> self.__refresh_btn.connect('clicked', >> self.__refresh_addon_list) >> install_page.pack_start(hbutbox, expand=False, padding=5) >> - notebook.append_page(install_page, >> - tab_label=gtk.Label(_('Install >> Addons'))) >> + # notebook.append_page(install_page, >> + # tab_label=gtk.Label(_('Install >> Addons'))) >> >> #add the notebook to the window >> self.window.vbox.add(notebook) >> Index: src/config.py >> =================================================================== >> --- src/config.py (revision 18947) >> +++ src/config.py (working copy) >> @@ -128,8 +128,8 @@ >> register('behavior.autoload', False) >> register('behavior.avg-generation-gap', 20) >> register('behavior.betawarn', False) >> -register('behavior.check-for-updates', 2) >> -register('behavior.check-for-update-types', ["update", "new"]) >> +register('behavior.check-for-updates', 0) >> +register('behavior.check-for-update-types', ["new"]) >> register('behavior.last-check-for-updates', "1970/01/01") >> register('behavior.previously-seen-updates', []) >> register('behavior.do-not-show-previously-seen-updates', True) >> >> |
From: Doug B. <dou...@gm...> - 2012-02-23 23:11:50
|
>> I think it would be fine, but it will require those that want >> to manually install a package to literally copy it into the right >> place. > > Sorry, I don't understand. > > The Help->Plugin Manager is not about manually installing plugins, it is > about automatically installing plugins from the wiki page (which I think > unnecessarily provides a different view on what addons exist). > > If you wanted to manually install a plugin, you had to put it manually in > the right place, and that doesn't change. I meant that in the Plugin Manager, all you need is a URL to install a plugin. So, anyone could make a zip or tgz, put it on the web, and someone else could install it through the Plugin Manager by entering the URL. Likewise, anyone could add an entry to the wiki page, with that URL, and it could be installed. In the new system, there is a bit of an overhead to getting the addon listed, but that hasn't been too much of a hurdle. >> Eventually, we should replicate all of the Plugin >> Manager/wikipage functionality in the new Preference-based system. It >> would be great if each addon had a wiki page, thumbnail, > > Yes, I suggest keeping the wiki page as it is for now, just removing the > link to the zip file. > Yes, that would be necessary. None of the addons listed there will work with Gramps 3.4 (wrong version) and some of the items listed there are shell scripts and other tools. >> and could be >> hidden/installed/removed from there. > > > The trouble with using the wiki page for installing addons (I presume you > mean using the page as information read by the application, rather than > clicking somewhere on the page to have an addon installed) is that there > would then be two sources of the truth about which addons existed - never a > good idea. Agreed. > I think that separation of installation (via the svn repository) and > documentation (via the wiki) is what is needed. After all, that corresponds > with the situation for the Gramps application itself. Yes, but the addons repository can be used to dynamically provide a list of available addons, rather than having to list it on the wiki. I imagine a page that looks similar to the current wiki page, but generated by a system that reads the addon listing: http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/trunk/listings/ > That is why I suggest removing the last column (containing a link to the svn > file) from the wiki page. Some of those are shell tools, so they need to be listed there (or somewhere), with their urls. >> Also, the listing on the wiki was >> a nice feature. I bet we can do that programmatically now, even in >> different languages > > > As I say, the documentation on the wiki page should be maintained > independently from the code. Yes, but there is a third thing: the listing (see above URL), which has been translated into many languages. The listing is maintained with the code. So, to cut down on confusion, I agree that it would be good to remove the download options from the Plugin Manager (unless Benny et al can think of a reason to keep them) and remove the duplicate entries from the wikipage. On top of that, it would be quite nice to have a server-side script that would read the above listing (or [1]) and generate a page similar to the old wiki page for those that want to browse through the options, with instructions on how to get these through Preferences. -Doug [1] - https://gramps-addons.svn.sourceforge.net/svnroot/gramps-addons/trunk/listings/ > >> -Doug >> >>> Regards, >>> Tim. >>> >>> >>> Index: src/gui/plug/_windows.py >>> =================================================================== >>> --- src/gui/plug/_windows.py (revision 18947) >>> +++ src/gui/plug/_windows.py (working copy) >>> @@ -264,8 +264,8 @@ >>> hbutbox.add(self.__refresh_btn) >>> self.__refresh_btn.connect('clicked', self.__refresh_addon_list) >>> install_page.pack_start(hbutbox, expand=False, padding=5) >>> - notebook.append_page(install_page, >>> - tab_label=gtk.Label(_('Install Addons'))) >>> + # notebook.append_page(install_page, >>> + # tab_label=gtk.Label(_('Install Addons'))) >>> >>> #add the notebook to the window >>> self.window.vbox.add(notebook) >>> Index: src/config.py >>> =================================================================== >>> --- src/config.py (revision 18947) >>> +++ src/config.py (working copy) >>> @@ -128,8 +128,8 @@ >>> register('behavior.autoload', False) >>> register('behavior.avg-generation-gap', 20) >>> register('behavior.betawarn', False) >>> -register('behavior.check-for-updates', 2) >>> -register('behavior.check-for-update-types', ["update", "new"]) >>> +register('behavior.check-for-updates', 0) >>> +register('behavior.check-for-update-types', ["new"]) >>> register('behavior.last-check-for-updates', "1970/01/01") >>> register('behavior.previously-seen-updates', []) >>> register('behavior.do-not-show-previously-seen-updates', True) >>> >>> > |
From: Tim L. <guy...@gm...> - 2012-02-23 23:50:03
|
Doug, Thanks, I now understand. On 23 Feb 2012, at 23:11, Doug Blank wrote: >> That is why I suggest removing the last column (containing a link >> to the svn >> file) from the wiki page. > So, to cut down on confusion, I agree that it would be good to remove > the download options from the Plugin Manager (unless Benny et al can > think of a reason to keep them) and remove the duplicate entries from > the wikipage. >>>> Index: src/gui/plug/_windows.py >>>> =================================================================== >>>> --- src/gui/plug/_windows.py (revision 18947) >>>> +++ src/gui/plug/_windows.py (working copy) >>>> @@ -264,8 +264,8 @@ >>>> hbutbox.add(self.__refresh_btn) >>>> self.__refresh_btn.connect('clicked', >>>> self.__refresh_addon_list) >>>> install_page.pack_start(hbutbox, expand=False, padding=5) >>>> - notebook.append_page(install_page, >>>> - tab_label=gtk.Label(_('Install >>>> Addons'))) >>>> + # notebook.append_page(install_page, >>>> + # tab_label=gtk.Label(_('Install >>>> Addons'))) >>>> >>>> #add the notebook to the window >>>> self.window.vbox.add(notebook) Can I go ahead with this? |
From: Benny M. <ben...@gm...> - 2012-02-24 08:21:36
|
2012/2/24 Tim Lyons <guy...@gm...>: > Doug, > > Thanks, I now understand. > > > > > On 23 Feb 2012, at 23:11, Doug Blank wrote: > >>> That is why I suggest removing the last column (containing a link to the >>> svn >>> file) from the wiki page. > > >> So, to cut down on confusion, I agree that it would be good to remove >> the download options from the Plugin Manager (unless Benny et al can >> think of a reason to keep them) and remove the duplicate entries from >> the wikipage. > > > > > >>>>> Index: src/gui/plug/_windows.py >>>>> =================================================================== >>>>> --- src/gui/plug/_windows.py (revision 18947) >>>>> +++ src/gui/plug/_windows.py (working copy) >>>>> @@ -264,8 +264,8 @@ >>>>> hbutbox.add(self.__refresh_btn) >>>>> self.__refresh_btn.connect('clicked', self.__refresh_addon_list) >>>>> install_page.pack_start(hbutbox, expand=False, padding=5) >>>>> - notebook.append_page(install_page, >>>>> - tab_label=gtk.Label(_('Install Addons'))) >>>>> + # notebook.append_page(install_page, >>>>> + # tab_label=gtk.Label(_('Install >>>>> Addons'))) >>>>> >>>>> #add the notebook to the window >>>>> self.window.vbox.add(notebook) > > > > Can I go ahead with this? My reply would have been that Doug is most current with plugin code, so he should decide. As he already did, go ahead. I only keep my genea data current at no moment, and don't use any 3th party plugins. Do remove all the relevant code, instead of only the append_page part. Also clean up the wiki, so searches on google or our wiki about installing plugins point to the correct place. Benny |