From: Duncan L. <dun...@gm...> - 2009-09-10 20:03:35
|
I've continued to think about the problem of places which we always have. I have a place called: Innerleithen, Scottish Boarders, United Kingdom I have a street in this town called Miller Street If I already have Innerleithen, why can't I make it a parent of Miller Street? Using this system each place can be a series of parent-child relationships. When viewing a place it could be presented something like below. Two fields where we can add, remove, create new, and share existing places, but directly edit them, they are seperate place objects. Between them is a node for the place we're doing now. The street --------------------------------------------------------------------------------------- | Sub-node(s): [add] [new] | This node: [ Miller Street ] Street [ \/ ] | Super-node(s): Innerleithen, Scottish Boarders, United Kingdom --------------------------------------------------------------------------------------- The town --------------------------------------------------------------------------------------- | Sub-node(s): [ > ] Miller Street (1 of 1) [add] [new] | This node: [ Innerleithen ] | Super-node(s): Scottish Boarders, United Kingdom -------------------------------------------------------------------------------------- Of course a county (or country etc) can have many sub places, so they could live in a clickable alphabetical flip-down list. -------------------------------------------------------------------------------------- | Sub-node(s): [ > ] Innerleithen (1 of 3) [add] [ new] | This node: [ Scottish Boarders ] | Super-node(s): United Kingdom -------------------------------------------------------------------------------------- The county folded out -------------------------------------------------------------------------------------- | Sub-node(s): [ \/ ] [ + ] [ - ] Innerleithen [add] [new] | [ + ] [ - ] Peebles | [ + ] [ - ] Traquir | This node: [ Scottish Boarders ] | Super-node(s): United Kingdom -------------------------------------------------------------------------------------- These diagrams have left out details of the interface which we already have and wouldneed to keep. Is this something that makes sense to anyone? It's hierarchical without having a pre-determined hierarchy. As our own lists of places grow so does the usefulness of this system, in my opinion. Let me know what you think so I can explain it more and we can keep working on this problem. Duncan |
From: Frederico M. <fs...@gm...> - 2009-09-10 21:33:01
|
Hi, 2009/9/10 Duncan Lithgow <dun...@gm...>: > I've continued to think about the problem of places which we always have. > > I have a place called: Innerleithen, Scottish Boarders, United Kingdom > I have a street in this town called Miller Street > > If I already have Innerleithen, why can't I make it a parent of Miller Street? Yes, this is something that I've seen "bite" most people, using any software. Should they add the Church, or the Church parish? They generally do the latter since otherwise it would mean the multiplication of places and would make it very hard to easily see events by location, etc. > Using this system each place can be a series of parent-child > relationships. When viewing a place it could be presented something > like below. Two fields where we can add, remove, create new, and share > existing places, but directly edit them, they are seperate place > objects. Between them is a node for the place we're doing now. > [... neat ASCII diagrams removed...] > Is this something that makes sense to anyone? It's hierarchical > without having a pre-determined hierarchy. As our own lists of places > grow so does the usefulness of this system, in my opinion. Let me know > what you think so I can explain it more and we can keep working on > this problem. I like it a lot. How would this play with the existing fields (State, Parish, City, etc)? Regards, Frederico |
From: Nick H. <nic...@ho...> - 2009-09-10 22:15:24
|
This is a good idea. Comments in-line: Frederico Muñoz wrote: > Hi, > > 2009/9/10 Duncan Lithgow <dun...@gm...>: > >> I've continued to think about the problem of places which we always have. >> >> I have a place called: Innerleithen, Scottish Boarders, United Kingdom >> I have a street in this town called Miller Street >> >> If I already have Innerleithen, why can't I make it a parent of Miller Street? >> > > Yes, this is something that I've seen "bite" most people, using any > software. Should they add the Church, or the Church parish? They > generally do the latter since otherwise it would mean the > multiplication of places and would make it very hard to easily see > events by location, etc. > > I have recorded quite a few events with street and/or church information. In the pedigree view I only really need to see town and above in the hierarchy. I was thinking of creating a feature request for this. >> Using this system each place can be a series of parent-child >> relationships. When viewing a place it could be presented something >> like below. Two fields where we can add, remove, create new, and share >> existing places, but directly edit them, they are seperate place >> objects. Between them is a node for the place we're doing now. >> >> Would this be a fixed number of levels? There is an existing hierarchy of street, city, county, state, country but the links are not defined. Would these levels be renamed or user-defined? Most of my addresses are in the UK so I don't use the "state" field - would this be just a level 2 field and I could use it for county? > [... neat ASCII diagrams removed...] > > >> Is this something that makes sense to anyone? It's hierarchical >> without having a pre-determined hierarchy. As our own lists of places >> grow so does the usefulness of this system, in my opinion. Let me know >> what you think so I can explain it more and we can keep working on >> this problem. >> > > Are you suggesting that we could add a new place by editing another? > I like it a lot. How would this play with the existing fields (State, > Parish, City, etc)? > > The existing fields can be useful from the Places view with filters. For example, it is easy to find all the places in a given city by filtering on the city field. > Regards, > > Frederico > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > |
From: Frederico M. <fs...@gm...> - 2009-09-10 22:23:47
|
Hi, 2009/9/10 Nick Hall <nic...@ho...>: (...) > Would this be a fixed number of levels? There is an existing hierarchy of > street, city, county, state, country but the links are not defined. Would > these levels be renamed or user-defined? Most of my addresses are in the UK > so I don't use the "state" field - would this be just a level 2 field and I > could use it for county? (...) > The existing fields can be useful from the Places view with filters. For > example, it is easy to find all the places in a given city by filtering on > the city field. I mentioned the existing fields since they are, I think, needed for GEDCOM. They would have to have some sort of relation with the levels we are talking about (at least that's what comes to mind). I was also implying exactly what you've said, the existing structure doesn't really work well for almost any non-USA country, I use "State" to mean something very different. Regards, Frederico |
From: Nick H. <nic...@ho...> - 2009-09-10 23:23:49
|
I just had a quick look at this. There is already a GEP: http://www.gramps-project.org/wiki/index.php?title=GEPS_006:_Better_Place_handling This refers to a GEDCOM 5.5EL which doesn't seem to be used yet. If I export my database I get 3 fields: PLAC A comma separated list which comes from my Place Name. ADDR This comes from the Street field. CITY This comes from the City field. There is nothing for county or country (I don't know about state). LocationBase which is a base class for Location and Address contains: street city county state country postal phone The first 5 of these fields are hierarchical. I like Duncan's idea of trying to utilise this relationship in an interface. I would also like the place name to be populated automatically from these 5 fields separated by commas. Nick. Frederico Muñoz wrote: > Hi, > > > 2009/9/10 Nick Hall <nic...@ho...>: > (...) > >> Would this be a fixed number of levels? There is an existing hierarchy of >> street, city, county, state, country but the links are not defined. Would >> these levels be renamed or user-defined? Most of my addresses are in the UK >> so I don't use the "state" field - would this be just a level 2 field and I >> could use it for county? >> > > (...) > > >> The existing fields can be useful from the Places view with filters. For >> example, it is easy to find all the places in a given city by filtering on >> the city field. >> > > I mentioned the existing fields since they are, I think, needed for > GEDCOM. They would have to have some sort of relation with the levels > we are talking about (at least that's what comes to mind). I was also > implying exactly what you've said, the existing structure doesn't > really work well for almost any non-USA country, I use "State" to mean > something very different. > > Regards, > > Frederico > > > |
From: Gerald B. <ger...@gm...> - 2009-09-11 00:38:17
|
While we're at it, let's try to align places and addresses. They share most (but not all) fields and have similar (though not identical) purposes. e.g. - Place splits city, county; Address puts them on one line - Place has lat/long. Address does not - Address label "State/Province" == Place label "State" (should be same label) - Address has a date; Place (understandably) does not I think that there would be a benefit in making these two similar and even...maybe...using one template for both purposes. While we're at it, why not make them more locale-specific? Maybe change State to Shire if we're locale=en_UK e.g. Maybe allow easy customization or even reconfigure dynamically based on the country? What about linking to a country's address lookup (like canadapost.ca for me)? Too way out there? Just some brainstorming ideas. Looking for more input. On Thu, Sep 10, 2009 at 7:23 PM, Nick Hall <nic...@ho...> wrote: > I just had a quick look at this. There is already a GEP: > > http://www.gramps-project.org/wiki/index.php?title=GEPS_006:_Better_Place_handling > > This refers to a GEDCOM 5.5EL which doesn't seem to be used yet. > > If I export my database I get 3 fields: > > PLAC A comma separated list which comes from my Place Name. > ADDR This comes from the Street field. > CITY This comes from the City field. > > There is nothing for county or country (I don't know about state). > > LocationBase which is a base class for Location and Address contains: > > street > city > county > state > country > postal > phone > > The first 5 of these fields are hierarchical. I like Duncan's idea of > trying to utilise this relationship in an interface. > > I would also like the place name to be populated automatically from > these 5 fields separated by commas. > > Nick. > > > Frederico Muñoz wrote: >> Hi, >> >> >> 2009/9/10 Nick Hall <nic...@ho...>: >> (...) >> >>> Would this be a fixed number of levels? There is an existing hierarchy of >>> street, city, county, state, country but the links are not defined. Would >>> these levels be renamed or user-defined? Most of my addresses are in the UK >>> so I don't use the "state" field - would this be just a level 2 field and I >>> could use it for county? >>> >> >> (...) >> >> >>> The existing fields can be useful from the Places view with filters. For >>> example, it is easy to find all the places in a given city by filtering on >>> the city field. >>> >> >> I mentioned the existing fields since they are, I think, needed for >> GEDCOM. They would have to have some sort of relation with the levels >> we are talking about (at least that's what comes to mind). I was also >> implying exactly what you've said, the existing structure doesn't >> really work well for almost any non-USA country, I use "State" to mean >> something very different. >> >> Regards, >> >> Frederico >> >> >> > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Gerald Britton |
From: Rob H. <rob...@gm...> - 2009-09-11 00:50:05
|
Greetings: I believe that it would be great to have the multi tiered places as was talked about last year and this year also. I know that Benny was talking about it too... I think having it be dynamic based on your locale would be awesome, but what if I live in the US, and I am trying to add a EUROPEAN address??? I think it would incredible to do what Ancestry.com already does! You pick a country from a drop-down, then state/shire/province drop-down based on country. Then state from a drop-down. Then a City as a text field... Just my two cents on the matter.... Sincerely, Rob On Thu, Sep 10, 2009 at 5:16 PM, Gerald Britton <ger...@gm...>wrote: > While we're at it, let's try to align places and addresses. They > share most (but not all) fields and have similar (though not > identical) purposes. > > e.g. - Place splits city, county; Address puts them on one line > - Place has lat/long. Address does not > - Address label "State/Province" == Place label "State" (should > be same label) > - Address has a date; Place (understandably) does not > > I think that there would be a benefit in making these two similar and > even...maybe...using one template for both purposes. While we're at > it, why not make them more locale-specific? Maybe change State to > Shire if we're locale=en_UK e.g. Maybe allow easy customization or > even reconfigure dynamically based on the country? What about linking > to a country's address lookup (like canadapost.ca for me)? Too way > out there? > > Just some brainstorming ideas. Looking for more input. > > On Thu, Sep 10, 2009 at 7:23 PM, Nick Hall <nic...@ho...> wrote: > > I just had a quick look at this. There is already a GEP: > > > > > http://www.gramps-project.org/wiki/index.php?title=GEPS_006:_Better_Place_handling > > > > This refers to a GEDCOM 5.5EL which doesn't seem to be used yet. > > > > If I export my database I get 3 fields: > > > > PLAC A comma separated list which comes from my Place Name. > > ADDR This comes from the Street field. > > CITY This comes from the City field. > > > > There is nothing for county or country (I don't know about state). > > > > LocationBase which is a base class for Location and Address contains: > > > > street > > city > > county > > state > > country > > postal > > phone > > > > The first 5 of these fields are hierarchical. I like Duncan's idea of > > trying to utilise this relationship in an interface. > > > > I would also like the place name to be populated automatically from > > these 5 fields separated by commas. > > > > Nick. > > > > > > Frederico Muñoz wrote: > >> Hi, > >> > >> > >> 2009/9/10 Nick Hall <nic...@ho...>: > >> (...) > >> > >>> Would this be a fixed number of levels? There is an existing hierarchy > of > >>> street, city, county, state, country but the links are not defined. > Would > >>> these levels be renamed or user-defined? Most of my addresses are in > the UK > >>> so I don't use the "state" field - would this be just a level 2 field > and I > >>> could use it for county? > >>> > >> > >> (...) > >> > >> > >>> The existing fields can be useful from the Places view with filters. > For > >>> example, it is easy to find all the places in a given city by filtering > on > >>> the city field. > >>> > >> > >> I mentioned the existing fields since they are, I think, needed for > >> GEDCOM. They would have to have some sort of relation with the levels > >> we are talking about (at least that's what comes to mind). I was also > >> implying exactly what you've said, the existing structure doesn't > >> really work well for almost any non-USA country, I use "State" to mean > >> something very different. > >> > >> Regards, > >> > >> Frederico > >> > >> > >> > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > > trial. Simplify your report design, integration and deployment - and > focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > > -- > Gerald Britton > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2009-09-11 07:22:13
|
All this discussion is nice, but as indicated, it has been discussed many, many times before. I have a clear idea from the past what has to happen to make place more workable while not turning GRAMPS into a place management software instead of a genealogy software. I want to be firm on this, changing place handling can only be added to GRAMPS if some old,and in need of maintenance code, is rewritten first. It is unacceptable that features are always added on top of the existing infrastructure, without redoing stuff from time to time. So if anybody is serious of changing the place infrastructure, the first thing that must happen is: help with the rewrite of PageView.py and the models for the listviews. PersonView should inherit from the same classes as the other listviews, all views must be navigationviews (backward/forward). I started by rewriting the listview model in /gui/views/models, same must happen for a treeview model. As a bonus making sure views can be pluggable would be nice (you could then experiment with different place views). Once this is in place, without changing the database structure, one can already show places in a treeview just as persons is done, which would make the navigation of places already much more easy and would allow some other things in software only (drop down of already used countries, ...). Sorry to say things a bit sharply, but I really feel in this one that some of the interface fundamentals must be cleaned up before adding things like a new place structure on top of it. Anyway, the design of another place structure would take a lot of work. I really don't care much in this case for the 'trust me, I'll start coding and you'll see when it is finished that it is good' approach. I don't mind loosing some control, but things must be done logically correct so that maintenance is clear. Benny |
From: Duncan L. <dun...@gm...> - 2009-09-11 09:36:26
|
My thoughts on this... Benny is of course correct in saying that the integrity and cleanliness of the codebase is of utmost importance. But as far as I know no-one has offered to make any changes yet, I think each time we've discussed it we've had slightly different views of how to solve this. As for Aunt Martha and migration issues... all of this is just hot air for now, so migration is a discussion for later once a solution is settled on and some devs step forward to carry this project. I personally don't see Aunt Martha having trouble with this, terminology is a tricky point here though, we can't use the concept of parents and children. That's why I stuck with 'Part of...' Localisation... I think it would be a bad idea to try and localise on the user. My locale is Denmark, but almost none of my research is here. But a pair of dropdown lists could be good. One for a locations locale which activates the other which has a set of palce types based on a set of locales. I also think that all the geonames and internal place lists etc. is a burdensome task. I would make all of that part of a web-lookup plugin which compares the places I have to web based lists of high quality. Anyway. I'm going to stop on this issue as there is clearly not traction for it at the moment. Duncan |
From: Jérôme <rom...@ya...> - 2009-09-11 12:40:36
Attachments:
drag%26drop.png
|
Just a question, does someone know how to drag&drop a place on Event Editor ? I suppose there is a wording/typo issue but maybe there is a way for using drag&drop action on Event Editor ! http://www.gramps-project.org/bugs/view.php?id=3149 Best Regards, Jérôme Duncan Lithgow a écrit : > My thoughts on this... > > Benny is of course correct in saying that the integrity and > cleanliness of the codebase is of utmost importance. But as far as I > know no-one has offered to make any changes yet, I think each time > we've discussed it we've had slightly different views of how to solve > this. > > As for Aunt Martha and migration issues... all of this is just hot air > for now, so migration is a discussion for later once a solution is > settled on and some devs step forward to carry this project. I > personally don't see Aunt Martha having trouble with this, terminology > is a tricky point here though, we can't use the concept of parents and > children. That's why I stuck with 'Part of...' > > Localisation... > I think it would be a bad idea to try and localise on the user. My > locale is Denmark, but almost none of my research is here. But a pair > of dropdown lists could be good. One for a locations locale which > activates the other which has a set of palce types based on a set of > locales. > > I also think that all the geonames and internal place lists etc. is a > burdensome task. I would make all of that part of a web-lookup plugin > which compares the places I have to web based lists of high quality. > > Anyway. I'm going to stop on this issue as there is clearly not > traction for it at the moment. > > Duncan > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <nic...@ho...> - 2009-09-11 13:04:51
|
You can drag&drop a place from the clipboard onto the Event Editor. A black box will appear around the field when it is OK to drop. Nick. Jérôme wrote: > Just a question, does someone know how to drag&drop a place on Event > Editor ? > > I suppose there is a wording/typo issue but maybe there is a way for > using drag&drop action on Event Editor ! > > http://www.gramps-project.org/bugs/view.php?id=3149 > > > Best Regards, > Jérôme > > Duncan Lithgow a écrit : >> My thoughts on this... >> >> Benny is of course correct in saying that the integrity and >> cleanliness of the codebase is of utmost importance. But as far as I >> know no-one has offered to make any changes yet, I think each time >> we've discussed it we've had slightly different views of how to solve >> this. >> >> As for Aunt Martha and migration issues... all of this is just hot air >> for now, so migration is a discussion for later once a solution is >> settled on and some devs step forward to carry this project. I >> personally don't see Aunt Martha having trouble with this, terminology >> is a tricky point here though, we can't use the concept of parents and >> children. That's why I stuck with 'Part of...' >> >> Localisation... >> I think it would be a bad idea to try and localise on the user. My >> locale is Denmark, but almost none of my research is here. But a pair >> of dropdown lists could be good. One for a locations locale which >> activates the other which has a set of palce types based on a set of >> locales. >> >> I also think that all the geonames and internal place lists etc. is a >> burdensome task. I would make all of that part of a web-lookup plugin >> which compares the places I have to web based lists of high quality. >> >> Anyway. I'm going to stop on this issue as there is clearly not >> traction for it at the moment. >> >> Duncan >> >> ------------------------------------------------------------------------------ >> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment >> - and focus on what you do best, core application coding. Discover >> what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jérôme <rom...@ya...> - 2009-09-11 13:23:22
|
ooooh that's it ... drag&drop from Place View or with clipboard. I tried to drag from external source or from "select place" dialog ! I never used this feature on Event Editor (and I use Gramps since many years ...) :-[ Thanks ! I will close my bug report. Jérôme Nick Hall a écrit : > You can drag&drop a place from the clipboard onto the Event Editor. A > black box will appear around the field when it is OK to drop. > > Nick. > > Jérôme wrote: >> Just a question, does someone know how to drag&drop a place on Event >> Editor ? >> >> I suppose there is a wording/typo issue but maybe there is a way for >> using drag&drop action on Event Editor ! >> >> http://www.gramps-project.org/bugs/view.php?id=3149 >> >> >> Best Regards, >> Jérôme >> >> Duncan Lithgow a écrit : >>> My thoughts on this... >>> >>> Benny is of course correct in saying that the integrity and >>> cleanliness of the codebase is of utmost importance. But as far as I >>> know no-one has offered to make any changes yet, I think each time >>> we've discussed it we've had slightly different views of how to solve >>> this. >>> >>> As for Aunt Martha and migration issues... all of this is just hot air >>> for now, so migration is a discussion for later once a solution is >>> settled on and some devs step forward to carry this project. I >>> personally don't see Aunt Martha having trouble with this, terminology >>> is a tricky point here though, we can't use the concept of parents and >>> children. That's why I stuck with 'Part of...' >>> >>> Localisation... >>> I think it would be a bad idea to try and localise on the user. My >>> locale is Denmark, but almost none of my research is here. But a pair >>> of dropdown lists could be good. One for a locations locale which >>> activates the other which has a set of palce types based on a set of >>> locales. >>> >>> I also think that all the geonames and internal place lists etc. is a >>> burdensome task. I would make all of that part of a web-lookup plugin >>> which compares the places I have to web based lists of high quality. >>> >>> Anyway. I'm going to stop on this issue as there is clearly not >>> traction for it at the moment. >>> >>> Duncan >>> >>> ------------------------------------------------------------------------------ >>> >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day trial. Simplify your report design, integration and deployment >>> - and focus on what you do best, core application coding. Discover >>> what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment >> - and focus on what you do best, core application coding. Discover >> what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > |
From: Doug B. <dou...@gm...> - 2009-09-11 10:41:18
|
On Fri, Sep 11, 2009 at 3:21 AM, Benny Malengier <ben...@gm...>wrote: > All this discussion is nice, but as indicated, it has been discussed > many, many times before. > I have a clear idea from the past what has to happen to make place > more workable while not turning GRAMPS into a place management > software instead of a genealogy software. > > I want to be firm on this, changing place handling can only be added > to GRAMPS if some old,and in need of maintenance code, is rewritten > first. It is unacceptable that features are always added on top of the > existing infrastructure, without redoing stuff from time to time. > > So if anybody is serious of changing the place infrastructure, the > first thing that must happen is: help with the rewrite of PageView.py > and the models for the listviews. PersonView should inherit from the > same classes as the other listviews, all views must be navigationviews > (backward/forward). > I started by rewriting the listview model in /gui/views/models, same > must happen for a treeview model. As a bonus making sure views can be > pluggable would be nice (you could then experiment with different > place views). > > Once this is in place, without changing the database structure, one > can already show places in a treeview just as persons is done, which > would make the navigation of places already much more easy and would > allow some other things in software only (drop down of already used > countries, ...). > > Sorry to say things a bit sharply, but I really feel in this one that > some of the interface fundamentals must be cleaned up before adding > things like a new place structure on top of it. > Anyway, the design of another place structure would take a lot of > work. I really don't care much in this case for the 'trust me, I'll > start coding and you'll see when it is finished that it is good' > approach. I don't mind loosing some control, but things must be done > logically correct so that maintenance is clear. > > Benny > > I just wanted to add that I have been using the Place Completion Tool recently, and I really think that this functionality should optionally be part of Gramps. That is, I believe that places and locations won't be of much good until we can attach long/lats to them, and it would be great to have that as part of the data entry process. If you didn't have all of the geo info installed, Gramps could work as-is. But if one installed some/all of the geo databases, you could pick places from lists if you wanted, as Rob was wishing for. This would require real databases for the geo data with indexes, and being able to store these hierarchical place selections. I've seen some exciting news in the last few days regarding geo data and open source, so I think that this functionality (and the GeoView itself) will only be more relevant and useful as time goes on. -Doug |
From: Jérôme <rom...@ya...> - 2009-09-11 08:55:39
|
Hello, I have a place database for France (more than 38 000 entries ...) I know that Gramps uses Place Title (like other programs), other fields on place editor will be only used by Gramps (internal) !!! http://www.gramps-project.org/wiki/images/8/8b/Edit-plc.png For example, export place with coordinates, location item additional name, data will be written into an ADDR markup, child of PLAC ... There is not a lot of genealogical programs who support this. I suppose a place database for Gramps just needs "title and coordinates". For restructuring places informations, users could use "Place completion" tool : http://www.gramps-project.org/wiki/index.php?title=Place_completion_tool --------------------------------------------------------- As a translator I had to make compromises ... http://fr.geneawiki.com/index.php/Informatique_-_saisie_des_lieux * "ZIP/postal" code translates as "place code" (BE-CA-FR) http://www.gramps-project.org/bugs/view.php?id=3113 * "county" translates as "comté/département" (BE-CA-FR) * "province" translates as "province/région" (BE-CA-FR) see also : http://www.gramps-project.org/bugs/view.php?id=3164 --------------------------------------------------------- For setting Address into Place, I use description field on Event ! http://www.gramps-project.org/wiki/index.php?title=Residence_and_census I had used subdivision on Place before, but we could get multiple entries on the same city. :( Also, address fields is the 'end of line', this cannot be related to other primary objects (only on person and ignores family, does every person lives alone ?). Without mention to the change of name and address of structure over time, phone number !!! It is not easy to manage Addresses for genealogical searchs, sounds like a PIM ... http://en.wikipedia.org/wiki/Personal_information_management I have written a plugin for listing address locations on my database, has generated a file, then I clean-up my database and moved all references to one data scheme : event + description who works with places and person & family. http://www.gramps-project.org/wiki/index.php?title=LocationsReport --------------------------------------------------------- Finally, I want to share something typical "opensource ressources and spirit" ... Here a project using OpenStreetMap data for generating a city map ! http://www.maposmatic.org/ http://www.fsf.org/licensing/licenses/agpl-3.0.html How this works ? * PostgreSQL server with PostGIS * OpenStreetMap data for France * http://www.mapnik.org/ for map rendering * OCitySMap (python script working with mapnik and cairo) * Django web service Geoview + web app/services ??? --------------------------------------------------------- Maybe address part on place could be useful if we have old maps (timeline addresses). Currently, if I really need to add a street and cannot add it on event, I use "Alternate Locations" item on Place Editor ... Jérôme Rob Healey a écrit : > Greetings: > > I believe that it would be great to have the multi tiered places as was > talked about last year and this year also. I know that Benny was > talking about it too... > > I think having it be dynamic based on your locale would be awesome, but > what if I live in the US, and I am trying to add a EUROPEAN address??? > > I think it would incredible to do what Ancestry.com already does! > > You pick a country from a drop-down, then state/shire/province drop-down > based on country. Then state from a drop-down. Then a City as a text > field... > > Just my two cents on the matter.... > > Sincerely, > Rob > > > On Thu, Sep 10, 2009 at 5:16 PM, Gerald Britton > <ger...@gm... <mailto:ger...@gm...>> wrote: > > While we're at it, let's try to align places and addresses. They > share most (but not all) fields and have similar (though not > identical) purposes. > > e.g. - Place splits city, county; Address puts them on one line > - Place has lat/long. Address does not > - Address label "State/Province" == Place label "State" (should > be same label) > - Address has a date; Place (understandably) does not > > I think that there would be a benefit in making these two similar and > even...maybe...using one template for both purposes. While we're at > it, why not make them more locale-specific? Maybe change State to > Shire if we're locale=en_UK e.g. Maybe allow easy customization or > even reconfigure dynamically based on the country? What about linking > to a country's address lookup (like canadapost.ca > <http://canadapost.ca> for me)? Too way > out there? > > Just some brainstorming ideas. Looking for more input. > > On Thu, Sep 10, 2009 at 7:23 PM, Nick Hall <nic...@ho... > <mailto:nic...@ho...>> wrote: > > I just had a quick look at this. There is already a GEP: > > > > > http://www.gramps-project.org/wiki/index.php?title=GEPS_006:_Better_Place_handling > > > > This refers to a GEDCOM 5.5EL which doesn't seem to be used yet. > > > > If I export my database I get 3 fields: > > > > PLAC A comma separated list which comes from my Place Name. > > ADDR This comes from the Street field. > > CITY This comes from the City field. > > > > There is nothing for county or country (I don't know about state). > > > > LocationBase which is a base class for Location and Address contains: > > > > street > > city > > county > > state > > country > > postal > > phone > > > > The first 5 of these fields are hierarchical. I like Duncan's > idea of > > trying to utilise this relationship in an interface. > > > > I would also like the place name to be populated automatically from > > these 5 fields separated by commas. > > > > Nick. > > > > > > Frederico Muñoz wrote: > >> Hi, > >> > >> > >> 2009/9/10 Nick Hall <nic...@ho... > <mailto:nic...@ho...>>: > >> (...) > >> > >>> Would this be a fixed number of levels? There is an existing > hierarchy of > >>> street, city, county, state, country but the links are not > defined. Would > >>> these levels be renamed or user-defined? Most of my addresses > are in the UK > >>> so I don't use the "state" field - would this be just a level 2 > field and I > >>> could use it for county? > >>> > >> > >> (...) > >> > >> > >>> The existing fields can be useful from the Places view with > filters. For > >>> example, it is easy to find all the places in a given city by > filtering on > >>> the city field. > >>> > >> > >> I mentioned the existing fields since they are, I think, needed for > >> GEDCOM. They would have to have some sort of relation with the > levels > >> we are talking about (at least that's what comes to mind). I was > also > >> implying exactly what you've said, the existing structure doesn't > >> really work well for almost any non-USA country, I use "State" > to mean > >> something very different. > >> > >> Regards, > >> > >> Frederico > >> > >> > >> > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > > trial. Simplify your report design, integration and deployment - > and focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > <mailto:Gra...@li...> > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > > -- > Gerald Britton > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Rob H. <rob...@gm...> - 2009-09-11 00:46:59
|
Dear Duncan: With this updated place information, will Gramps modify the existing places already listed, or do we need to modify the existing to the new format??? Sincerely yours, Rob G. Healey On Thu, Sep 10, 2009 at 4:23 PM, Nick Hall <nic...@ho...> wrote: > I just had a quick look at this. There is already a GEP: > > > http://www.gramps-project.org/wiki/index.php?title=GEPS_006:_Better_Place_handling > > This refers to a GEDCOM 5.5EL which doesn't seem to be used yet. > > If I export my database I get 3 fields: > > PLAC A comma separated list which comes from my Place Name. > ADDR This comes from the Street field. > CITY This comes from the City field. > > There is nothing for county or country (I don't know about state). > > LocationBase which is a base class for Location and Address contains: > > street > city > county > state > country > postal > phone > > The first 5 of these fields are hierarchical. I like Duncan's idea of > trying to utilise this relationship in an interface. > > I would also like the place name to be populated automatically from > these 5 fields separated by commas. > > Nick. > > > Frederico Muñoz wrote: > > Hi, > > > > > > 2009/9/10 Nick Hall <nic...@ho...>: > > (...) > > > >> Would this be a fixed number of levels? There is an existing hierarchy > of > >> street, city, county, state, country but the links are not defined. > Would > >> these levels be renamed or user-defined? Most of my addresses are in > the UK > >> so I don't use the "state" field - would this be just a level 2 field > and I > >> could use it for county? > >> > > > > (...) > > > > > >> The existing fields can be useful from the Places view with filters. > For > >> example, it is easy to find all the places in a given city by filtering > on > >> the city field. > >> > > > > I mentioned the existing fields since they are, I think, needed for > > GEDCOM. They would have to have some sort of relation with the levels > > we are talking about (at least that's what comes to mind). I was also > > implying exactly what you've said, the existing structure doesn't > > really work well for almost any non-USA country, I use "State" to mean > > something very different. > > > > Regards, > > > > Frederico > > > > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <nic...@ho...> - 2009-09-16 21:28:33
|
Benny, I'd like to help with the re-write and then perhaps test a new place view. So far I have split out the code for PeopleModel so that it inherits from a new TreeBaseModel. I have also enhanced the node map so that it supports more than two levels of hierarchy. I have looked at PageView but haven't made any changes yet. I created a PersonView which inherits from ListView - it displays the tree and the search/filter works but nothing else. What is the best way for me to contribute this to the project? Regards, Nick. Benny Malengier wrote: > All this discussion is nice, but as indicated, it has been discussed > many, many times before. > I have a clear idea from the past what has to happen to make place > more workable while not turning GRAMPS into a place management > software instead of a genealogy software. > > I want to be firm on this, changing place handling can only be added > to GRAMPS if some old,and in need of maintenance code, is rewritten > first. It is unacceptable that features are always added on top of the > existing infrastructure, without redoing stuff from time to time. > > So if anybody is serious of changing the place infrastructure, the > first thing that must happen is: help with the rewrite of PageView.py > and the models for the listviews. PersonView should inherit from the > same classes as the other listviews, all views must be navigationviews > (backward/forward). > I started by rewriting the listview model in /gui/views/models, same > must happen for a treeview model. As a bonus making sure views can be > pluggable would be nice (you could then experiment with different > place views). > > Once this is in place, without changing the database structure, one > can already show places in a treeview just as persons is done, which > would make the navigation of places already much more easy and would > allow some other things in software only (drop down of already used > countries, ...). > > Sorry to say things a bit sharply, but I really feel in this one that > some of the interface fundamentals must be cleaned up before adding > things like a new place structure on top of it. > Anyway, the design of another place structure would take a lot of > work. I really don't care much in this case for the 'trust me, I'll > start coding and you'll see when it is finished that it is good' > approach. I don't mind loosing some control, but things must be done > logically correct so that maintenance is clear. > > Benny > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > |
From: Benny M. <ben...@gm...> - 2009-09-16 23:06:55
|
2009/9/16 Nick Hall <nic...@ho...>: > Benny, > > I'd like to help with the re-write and then perhaps test a new place view. > > So far I have split out the code for PeopleModel so that it inherits from a > new TreeBaseModel. I have also enhanced the node map so that it supports > more than two levels of hierarchy. Great to hear this. Unfortunately, I leave for conference friday and have very little time now. The best way forward is that: 1. I review your code. Send it my way or add it to a bug list 2. Depending on my judgement, I give you svn access and check your code post change instead of pre change 3. I let you know how I think PageView should be split up. The idea is to have a series of objects that slowly adds functionality, with real views inheriting from the base view that they need. So all listviews should be bookmarkviews and navigation views. Something like Pedigreeview would not be a listview, but still a bookmarkview or navigationview, something like the GrampletView would inherit from the base class as it does not need navigation or bookmark. All should move to src/gui/views 4. I think treeview should extend listview, and then peopleview can inherit from there. We can then make a placeview that shows places in a treeview. My final goal here is to make views plugins, and to change the sidebar to have at the top a series of small icons: one icon to minimize the sidebar, one icon to switch view type (so you could cycle person view from flat view to treeview, pedigree view from horizontal to vertical, ...), and one icon for configuration, which would bring up a configuration dialog related to the view seen. That would be better usability than having view configuration scattered around. Eg the configuration dialog of a listview can show the column editor in a tab, for a treeview the column editor in a tab and how the top nodes must be formed in another, .... Benny > > I have looked at PageView but haven't made any changes yet. I created a > PersonView which inherits from ListView - it displays the tree and the > search/filter works but nothing else. > > What is the best way for me to contribute this to the project? > > Regards, > > > Nick. > > Benny Malengier wrote: >> >> All this discussion is nice, but as indicated, it has been discussed >> many, many times before. >> I have a clear idea from the past what has to happen to make place >> more workable while not turning GRAMPS into a place management >> software instead of a genealogy software. >> >> I want to be firm on this, changing place handling can only be added >> to GRAMPS if some old,and in need of maintenance code, is rewritten >> first. It is unacceptable that features are always added on top of the >> existing infrastructure, without redoing stuff from time to time. >> >> So if anybody is serious of changing the place infrastructure, the >> first thing that must happen is: help with the rewrite of PageView.py >> and the models for the listviews. PersonView should inherit from the >> same classes as the other listviews, all views must be navigationviews >> (backward/forward). >> I started by rewriting the listview model in /gui/views/models, same >> must happen for a treeview model. As a bonus making sure views can be >> pluggable would be nice (you could then experiment with different >> place views). >> >> Once this is in place, without changing the database structure, one >> can already show places in a treeview just as persons is done, which >> would make the navigation of places already much more easy and would >> allow some other things in software only (drop down of already used >> countries, ...). >> >> Sorry to say things a bit sharply, but I really feel in this one that >> some of the interface fundamentals must be cleaned up before adding >> things like a new place structure on top of it. >> Anyway, the design of another place structure would take a lot of >> work. I really don't care much in this case for the 'trust me, I'll >> start coding and you'll see when it is finished that it is good' >> approach. I don't mind loosing some control, but things must be done >> logically correct so that maintenance is clear. >> >> Benny >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment - and >> focus on what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> > |
From: Nick H. <nic...@ho...> - 2009-09-17 00:44:23
|
Benny Malengier wrote: > 2009/9/16 Nick Hall <nic...@ho...>: > >> Benny, >> >> I'd like to help with the re-write and then perhaps test a new place view. >> >> So far I have split out the code for PeopleModel so that it inherits from a >> new TreeBaseModel. I have also enhanced the node map so that it supports >> more than two levels of hierarchy. >> > > Great to hear this. > Unfortunately, I leave for conference friday and have very little time now. > The best way forward is that: > 1. I review your code. Send it my way or add it to a bug list > I was hoping that after changing PeopleModel and creating the new TreeBaseModel then I could create a patch that would work. However, PersonView accesses the node map data structures directly. As I have changed the implementation of the node map this will break things. It is probably better if I send you fully working code, but I am happy to send you something to look at earlier. > 2. Depending on my judgement, I give you svn access and check your > code post change instead of pre change > I don't mind sending you patches. > 3. I let you know how I think PageView should be split up. The idea is > to have a series of objects that slowly adds functionality, with real > views inheriting from the base view that they need. > So all listviews should be bookmarkviews and navigation views. > Something like Pedigreeview would not be a listview, but still a > bookmarkview or navigationview, something like the GrampletView would > inherit from the base class as it does not need navigation or > bookmark. > So we will have: PageView -> BookMarkView -> NavigationView -> ListView All list based views will inherit from ListView. Pedigreeview and RelationshipView will inherit from NavigationView. GrampletView will inherit from PageView. GeoView will inherit from HTMLView which inherits from PageView. Have I got BookMarkView and NavigationView the right way? > All should move to src/gui/views > I have read the GEP. Do you want to split PageView, BookMarkView, NavigationView and ListView into separate files? > 4. I think treeview should extend listview, and then peopleview can > inherit from there. We can then make a placeview that shows places in > a treeview. > > Possibly but they should be very similar. treeview will have functionality for expand/collapse nodes and will have to deal with nodes with handles differently from those without. listview has column sorting functionality but treeview does not. Do we want to add column sorting treeviews? > My final goal here is to make views plugins, and to change the sidebar > to have at the top a series of small icons: one icon to minimize the > sidebar, one icon to switch view type (so you could cycle person view > from flat view to treeview, pedigree view from horizontal to vertical, > ...), and one icon for configuration, which would bring up a > configuration dialog related to the view seen. That would be better > usability than having view configuration scattered around. Eg the > configuration dialog of a listview can show the column editor in a > tab, for a treeview the column editor in a tab and how the top nodes > must be formed in another, .... > > Yes, that sounds good. Are you planning this for 3.2 or is it more of a long-term goal? > Benny > >> I have looked at PageView but haven't made any changes yet. I created a >> PersonView which inherits from ListView - it displays the tree and the >> search/filter works but nothing else. >> >> What is the best way for me to contribute this to the project? >> >> Regards, >> >> >> Nick. >> >> Benny Malengier wrote: >> >>> All this discussion is nice, but as indicated, it has been discussed >>> many, many times before. >>> I have a clear idea from the past what has to happen to make place >>> more workable while not turning GRAMPS into a place management >>> software instead of a genealogy software. >>> >>> I want to be firm on this, changing place handling can only be added >>> to GRAMPS if some old,and in need of maintenance code, is rewritten >>> first. It is unacceptable that features are always added on top of the >>> existing infrastructure, without redoing stuff from time to time. >>> >>> So if anybody is serious of changing the place infrastructure, the >>> first thing that must happen is: help with the rewrite of PageView.py >>> and the models for the listviews. PersonView should inherit from the >>> same classes as the other listviews, all views must be navigationviews >>> (backward/forward). >>> I started by rewriting the listview model in /gui/views/models, same >>> must happen for a treeview model. As a bonus making sure views can be >>> pluggable would be nice (you could then experiment with different >>> place views). >>> >>> Once this is in place, without changing the database structure, one >>> can already show places in a treeview just as persons is done, which >>> would make the navigation of places already much more easy and would >>> allow some other things in software only (drop down of already used >>> countries, ...). >>> >>> Sorry to say things a bit sharply, but I really feel in this one that >>> some of the interface fundamentals must be cleaned up before adding >>> things like a new place structure on top of it. >>> Anyway, the design of another place structure would take a lot of >>> work. I really don't care much in this case for the 'trust me, I'll >>> start coding and you'll see when it is finished that it is good' >>> approach. I don't mind loosing some control, but things must be done >>> logically correct so that maintenance is clear. >>> >>> Benny >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day trial. Simplify your report design, integration and deployment - and >>> focus on what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >>> >>> > > > |
From: Benny M. <ben...@gm...> - 2009-09-17 07:28:27
|
2009/9/17 Nick Hall <nic...@ho...>: > > > Benny Malengier wrote: >> >> 2009/9/16 Nick Hall <nic...@ho...>: >> >>> >>> Benny, >>> >>> I'd like to help with the re-write and then perhaps test a new place >>> view. >>> >>> So far I have split out the code for PeopleModel so that it inherits from >>> a >>> new TreeBaseModel. I have also enhanced the node map so that it supports >>> more than two levels of hierarchy. >>> >> >> Great to hear this. >> Unfortunately, I leave for conference friday and have very little time >> now. >> The best way forward is that: >> 1. I review your code. Send it my way or add it to a bug list >> > > I was hoping that after changing PeopleModel and creating the new > TreeBaseModel then I could create a patch that would work. However, > PersonView accesses the node map data structures directly. As I have > changed the implementation of the node map this will break things. I'd be interested in seeing the node implementation. The work I did with src/gui/views/flatbasemodel is a nice speedup over the old implementation. The aim would be to do as good with treemodels. But for place, I would guess there should be a node for country, one for state, one for city, so more than one node. I did not yet think this out myself if different nodemaps are needed for that, or one can design one to do it > > It is probably better if I send you fully working code, but I am happy to > send you something to look at earlier. it's good to share design ideas before all code is finished. >> >> 2. Depending on my judgement, I give you svn access and check your >> code post change instead of pre change >> > > I don't mind sending you patches. yes, but I don't have time to review all patches in a timely manner. I still have one from you in my inbox ... >> 3. I let you know how I think PageView should be split up. The idea is >> to have a series of objects that slowly adds functionality, with real >> views inheriting from the base view that they need. >> So all listviews should be bookmarkviews and navigation views. >> Something like Pedigreeview would not be a listview, but still a >> bookmarkview or navigationview, something like the GrampletView would >> inherit from the base class as it does not need navigation or >> bookmark. >> > > So we will have: > > PageView -> BookMarkView -> NavigationView -> ListView > All list based views will inherit from ListView. > > Pedigreeview and RelationshipView will inherit from NavigationView. > GrampletView will inherit from PageView. > GeoView will inherit from HTMLView which inherits from PageView. > > Have I got BookMarkView and NavigationView the right way? Yes, this one has me annoyed too. I believe every navigationview should be a bookmarkview, so perhaps better to make it one single class instead of split over two. If split, the order if the split (first bookmark then navigation) is not the point. Perhaps we can also put all functionality for an 'active' item in a single class. Now only person has an 'active person' signal which treeview responds too, same thing is wanted for places, families, ... . Then outside actions can change the active object and the view updates. Doug would like to have primary active, secondary active, ... also, that is, he would like to put 2 person views in his setup, and have one react to/emit the primary active signal, the other to the secondary active. Well, just something to keep in the back of our mind. > >> All should move to src/gui/views >> > > I have read the GEP. > > Do you want to split PageView, BookMarkView, NavigationView and ListView > into separate files? yes, so views/pageview.py with PageView, .... Note that there is a bug item to move to setup.py for installation. That would save us a lot of time as we no longer have to change Makefile.am for every file moved. If I say a view would have a configuration screen, then that means a hook for that is added to PageView, ... . As I'd like to have views pluggable, ViewManager would obtain the list of views to show, and load them. The configuration of views would have a general section, where people can add/remove views or sort them differently. >> 4. I think treeview should extend listview, and then peopleview can >> inherit from there. We can then make a placeview that shows places in >> a treeview. >> >> > > Possibly but they should be very similar. treeview will have functionality > for expand/collapse nodes and will have to deal with nodes with handles > differently from those without. listview has column sorting functionality > but treeview does not. Do we want to add column sorting treeviews? It is one of the most requested features: http://www.gramps-project.org/bugs/view.php?id=568 I have assigned it to myself when I started the work on flatbasemodel. So yes, I am hoping that the approach there allows for quick sort in the treemodel. Note that I would not make the the root node sortable, clicking a column would eg sort on date within a surname. I would however add also a person view based on flatbasemodel as a view, and allow switching from treeview to flatview. In flatview one can sort on all columns. Well, this is only in the idea phase for myself, I did not start any of the tree stuff, except some ideas in my head. >> My final goal here is to make views plugins, and to change the sidebar >> to have at the top a series of small icons: one icon to minimize the >> sidebar, one icon to switch view type (so you could cycle person view >> from flat view to treeview, pedigree view from horizontal to vertical, >> ...), and one icon for configuration, which would bring up a >> configuration dialog related to the view seen. That would be better >> usability than having view configuration scattered around. Eg the >> configuration dialog of a listview can show the column editor in a >> tab, for a treeview the column editor in a tab and how the top nodes >> must be formed in another, .... >> >> > > Yes, that sounds good. Are you planning this for 3.2 or is it more of a > long-term goal? 3.2 is for beginning of 2010, so if this is reachable with a conclusion around new year, then there are some months for testing and making it solid, before 3.2 is released. That is the same for all new stuff, it should land at the latest around new year. Benny > >> Benny >> >>> >>> I have looked at PageView but haven't made any changes yet. I created a >>> PersonView which inherits from ListView - it displays the tree and the >>> search/filter works but nothing else. >>> >>> What is the best way for me to contribute this to the project? >>> >>> Regards, >>> >>> >>> Nick. >>> >>> Benny Malengier wrote: >>> >>>> >>>> All this discussion is nice, but as indicated, it has been discussed >>>> many, many times before. >>>> I have a clear idea from the past what has to happen to make place >>>> more workable while not turning GRAMPS into a place management >>>> software instead of a genealogy software. >>>> >>>> I want to be firm on this, changing place handling can only be added >>>> to GRAMPS if some old,and in need of maintenance code, is rewritten >>>> first. It is unacceptable that features are always added on top of the >>>> existing infrastructure, without redoing stuff from time to time. >>>> >>>> So if anybody is serious of changing the place infrastructure, the >>>> first thing that must happen is: help with the rewrite of PageView.py >>>> and the models for the listviews. PersonView should inherit from the >>>> same classes as the other listviews, all views must be navigationviews >>>> (backward/forward). >>>> I started by rewriting the listview model in /gui/views/models, same >>>> must happen for a treeview model. As a bonus making sure views can be >>>> pluggable would be nice (you could then experiment with different >>>> place views). >>>> >>>> Once this is in place, without changing the database structure, one >>>> can already show places in a treeview just as persons is done, which >>>> would make the navigation of places already much more easy and would >>>> allow some other things in software only (drop down of already used >>>> countries, ...). >>>> >>>> Sorry to say things a bit sharply, but I really feel in this one that >>>> some of the interface fundamentals must be cleaned up before adding >>>> things like a new place structure on top of it. >>>> Anyway, the design of another place structure would take a lot of >>>> work. I really don't care much in this case for the 'trust me, I'll >>>> start coding and you'll see when it is finished that it is good' >>>> approach. I don't mind loosing some control, but things must be done >>>> logically correct so that maintenance is clear. >>>> >>>> Benny >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day trial. Simplify your report design, integration and deployment - >>>> and >>>> focus on what you do best, core application coding. Discover what's new >>>> with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>>> >>>> >>>> >> >> >> > |
From: Doug B. <dou...@gm...> - 2009-09-17 10:38:17
|
On Thu, Sep 17, 2009 at 3:28 AM, Benny Malengier <ben...@gm...>wrote: > 2009/9/17 Nick Hall <nic...@ho...>: > > > > > > Benny Malengier wrote: > >> > >> 2009/9/16 Nick Hall <nic...@ho...>: > >> > >>> > >>> Benny, > >>> > >>> I'd like to help with the re-write and then perhaps test a new place > >>> view. > >>> > >>> So far I have split out the code for PeopleModel so that it inherits > from > >>> a > >>> new TreeBaseModel. I have also enhanced the node map so that it > supports > >>> more than two levels of hierarchy. > >>> > >> > >> Great to hear this. > >> Unfortunately, I leave for conference friday and have very little time > >> now. > >> The best way forward is that: > >> 1. I review your code. Send it my way or add it to a bug list > >> > > > > I was hoping that after changing PeopleModel and creating the new > > TreeBaseModel then I could create a patch that would work. However, > > PersonView accesses the node map data structures directly. As I have > > changed the implementation of the node map this will break things. > > I'd be interested in seeing the node implementation. > The work I did with src/gui/views/flatbasemodel is a nice speedup over > the old implementation. The aim would be to do as good with > treemodels. > But for place, I would guess there should be a node for country, one > for state, one for city, so more than one node. I did not yet think > this out myself if different nodemaps are needed for that, or one can > design one to do it > > > > > It is probably better if I send you fully working code, but I am happy to > > send you something to look at earlier. > > it's good to share design ideas before all code is finished. > >> > >> 2. Depending on my judgement, I give you svn access and check your > >> code post change instead of pre change > >> > > > > I don't mind sending you patches. > > yes, but I don't have time to review all patches in a timely manner. I > still have one from you in my inbox ... > > >> 3. I let you know how I think PageView should be split up. The idea is > >> to have a series of objects that slowly adds functionality, with real > >> views inheriting from the base view that they need. > >> So all listviews should be bookmarkviews and navigation views. > >> Something like Pedigreeview would not be a listview, but still a > >> bookmarkview or navigationview, something like the GrampletView would > >> inherit from the base class as it does not need navigation or > >> bookmark. > >> > > > > So we will have: > > > > PageView -> BookMarkView -> NavigationView -> ListView > > All list based views will inherit from ListView. > > > > Pedigreeview and RelationshipView will inherit from NavigationView. > > GrampletView will inherit from PageView. > > GeoView will inherit from HTMLView which inherits from PageView. > > > > Have I got BookMarkView and NavigationView the right way? > > Yes, this one has me annoyed too. I believe every navigationview > should be a bookmarkview, so perhaps better to make it one single > class instead of split over two. If split, the order if the split > (first bookmark then navigation) is not the point. > > Perhaps we can also put all functionality for an 'active' item in a > single class. Now only person has an 'active person' signal which > treeview responds too, same thing is wanted for places, families, ... > . Then outside actions can change the active object and the view > updates. Doug would like to have primary active, secondary active, ... > also, that is, he would like to put 2 person views in his setup, and > have one react to/emit the primary active signal, the other to the > secondary active. Well, just something to keep in the back of our > mind. > Nick, Thanks for tackling this! I think that fixing the Views will allow other enhancements to fall into place. I don't really have an opinion on this primary/secondary idea, but I can give some motivation for this idea. We realized that one can currently add more than one PeopleView (for example) to Gramps. However, it doesn't quite work because when you change the active person, all of the PeopleViews change to that person. If I remember correctly, even changing the person on one view will change the active person which changes the other PeopleViews. I'm not certain that having more than one view of a type is a good idea, nor if it is a god idea to have primary/secondary status among them. But, as Benny said, something to think about as we rework this area. -Doug > > > >> All should move to src/gui/views > >> > > > > I have read the GEP. > > > > Do you want to split PageView, BookMarkView, NavigationView and ListView > > into separate files? > > yes, so views/pageview.py with PageView, .... > Note that there is a bug item to move to setup.py for installation. > That would save us a lot of time as we no longer have to change > Makefile.am for every file moved. > If I say a view would have a configuration screen, then that means a > hook for that is added to PageView, ... . > As I'd like to have views pluggable, ViewManager would obtain the list > of views to show, and load them. The configuration of views would have > a general section, where people can add/remove views or sort them > differently. > > >> 4. I think treeview should extend listview, and then peopleview can > >> inherit from there. We can then make a placeview that shows places in > >> a treeview. > >> > >> > > > > Possibly but they should be very similar. treeview will have > functionality > > for expand/collapse nodes and will have to deal with nodes with handles > > differently from those without. listview has column sorting > functionality > > but treeview does not. Do we want to add column sorting treeviews? > > It is one of the most requested features: > http://www.gramps-project.org/bugs/view.php?id=568 > > I have assigned it to myself when I started the work on flatbasemodel. > So yes, I am hoping that the approach there allows for quick sort in > the treemodel. > Note that I would not make the the root node sortable, clicking a > column would eg sort on date within a surname. > I would however add also a person view based on flatbasemodel as a > view, and allow switching from treeview to flatview. In flatview one > can sort on all columns. > Well, this is only in the idea phase for myself, I did not start any > of the tree stuff, except some ideas in my head. > > >> My final goal here is to make views plugins, and to change the sidebar > >> to have at the top a series of small icons: one icon to minimize the > >> sidebar, one icon to switch view type (so you could cycle person view > >> from flat view to treeview, pedigree view from horizontal to vertical, > >> ...), and one icon for configuration, which would bring up a > >> configuration dialog related to the view seen. That would be better > >> usability than having view configuration scattered around. Eg the > >> configuration dialog of a listview can show the column editor in a > >> tab, for a treeview the column editor in a tab and how the top nodes > >> must be formed in another, .... > >> > >> > > > > Yes, that sounds good. Are you planning this for 3.2 or is it more of a > > long-term goal? > > 3.2 is for beginning of 2010, so if this is reachable with a > conclusion around new year, then there are some months for testing and > making it solid, before 3.2 is released. > That is the same for all new stuff, it should land at the latest > around new year. > > Benny > > > >> Benny > >> > >>> > >>> I have looked at PageView but haven't made any changes yet. I created a > >>> PersonView which inherits from ListView - it displays the tree and the > >>> search/filter works but nothing else. > >>> > >>> What is the best way for me to contribute this to the project? > >>> > >>> Regards, > >>> > >>> > >>> Nick. > >>> > >>> Benny Malengier wrote: > >>> > >>>> > >>>> All this discussion is nice, but as indicated, it has been discussed > >>>> many, many times before. > >>>> I have a clear idea from the past what has to happen to make place > >>>> more workable while not turning GRAMPS into a place management > >>>> software instead of a genealogy software. > >>>> > >>>> I want to be firm on this, changing place handling can only be added > >>>> to GRAMPS if some old,and in need of maintenance code, is rewritten > >>>> first. It is unacceptable that features are always added on top of the > >>>> existing infrastructure, without redoing stuff from time to time. > >>>> > >>>> So if anybody is serious of changing the place infrastructure, the > >>>> first thing that must happen is: help with the rewrite of PageView.py > >>>> and the models for the listviews. PersonView should inherit from the > >>>> same classes as the other listviews, all views must be navigationviews > >>>> (backward/forward). > >>>> I started by rewriting the listview model in /gui/views/models, same > >>>> must happen for a treeview model. As a bonus making sure views can be > >>>> pluggable would be nice (you could then experiment with different > >>>> place views). > >>>> > >>>> Once this is in place, without changing the database structure, one > >>>> can already show places in a treeview just as persons is done, which > >>>> would make the navigation of places already much more easy and would > >>>> allow some other things in software only (drop down of already used > >>>> countries, ...). > >>>> > >>>> Sorry to say things a bit sharply, but I really feel in this one that > >>>> some of the interface fundamentals must be cleaned up before adding > >>>> things like a new place structure on top of it. > >>>> Anyway, the design of another place structure would take a lot of > >>>> work. I really don't care much in this case for the 'trust me, I'll > >>>> start coding and you'll see when it is finished that it is good' > >>>> approach. I don't mind loosing some control, but things must be done > >>>> logically correct so that maintenance is clear. > >>>> > >>>> Benny > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > >>>> 30-Day trial. Simplify your report design, integration and deployment > - > >>>> and > >>>> focus on what you do best, core application coding. Discover what's > new > >>>> with > >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july > >>>> _______________________________________________ > >>>> Gramps-devel mailing list > >>>> Gra...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >>>> > >>>> > >>>> > >>>> > >> > >> > >> > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <nic...@ho...> - 2009-09-17 11:24:58
|
Doug Blank wrote: > On Thu, Sep 17, 2009 at 3:28 AM, Benny Malengier > <ben...@gm... <mailto:ben...@gm...>> wrote: > > 2009/9/17 Nick Hall <nic...@ho... > <mailto:nic...@ho...>>: > > > > > > Benny Malengier wrote: > >> > >> 2009/9/16 Nick Hall <nic...@ho... > <mailto:nic...@ho...>>: > >> > >>> > >>> Benny, > >>> > >>> I'd like to help with the re-write and then perhaps test a new > place > >>> view. > >>> > >>> So far I have split out the code for PeopleModel so that it > inherits from > >>> a > >>> new TreeBaseModel. I have also enhanced the node map so that > it supports > >>> more than two levels of hierarchy. > >>> > >> > >> Great to hear this. > >> Unfortunately, I leave for conference friday and have very > little time > >> now. > >> The best way forward is that: > >> 1. I review your code. Send it my way or add it to a bug list > >> > > > > I was hoping that after changing PeopleModel and creating the new > > TreeBaseModel then I could create a patch that would work. However, > > PersonView accesses the node map data structures directly. As I > have > > changed the implementation of the node map this will break things. > > I'd be interested in seeing the node implementation. > The work I did with src/gui/views/flatbasemodel is a nice speedup over > the old implementation. The aim would be to do as good with > treemodels. > But for place, I would guess there should be a node for country, one > for state, one for city, so more than one node. I did not yet think > this out myself if different nodemaps are needed for that, or one can > design one to do it > > > > > It is probably better if I send you fully working code, but I am > happy to > > send you something to look at earlier. > > it's good to share design ideas before all code is finished. > >> > >> 2. Depending on my judgement, I give you svn access and check your > >> code post change instead of pre change > >> > > > > I don't mind sending you patches. > > yes, but I don't have time to review all patches in a timely manner. I > still have one from you in my inbox ... > > >> 3. I let you know how I think PageView should be split up. The > idea is > >> to have a series of objects that slowly adds functionality, > with real > >> views inheriting from the base view that they need. > >> So all listviews should be bookmarkviews and navigation views. > >> Something like Pedigreeview would not be a listview, but still a > >> bookmarkview or navigationview, something like the GrampletView > would > >> inherit from the base class as it does not need navigation or > >> bookmark. > >> > > > > So we will have: > > > > PageView -> BookMarkView -> NavigationView -> ListView > > All list based views will inherit from ListView. > > > > Pedigreeview and RelationshipView will inherit from NavigationView. > > GrampletView will inherit from PageView. > > GeoView will inherit from HTMLView which inherits from PageView. > > > > Have I got BookMarkView and NavigationView the right way? > > Yes, this one has me annoyed too. I believe every navigationview > should be a bookmarkview, so perhaps better to make it one single > class instead of split over two. If split, the order if the split > (first bookmark then navigation) is not the point. > > Perhaps we can also put all functionality for an 'active' item in a > single class. Now only person has an 'active person' signal which > treeview responds too, same thing is wanted for places, families, ... > . Then outside actions can change the active object and the view > updates. Doug would like to have primary active, secondary active, ... > also, that is, he would like to put 2 person views in his setup, and > have one react to/emit the primary active signal, the other to the > secondary active. Well, just something to keep in the back of our > mind. > > > Nick, > > Thanks for tackling this! I think that fixing the Views will allow > other enhancements to fall into place. > > I don't really have an opinion on this primary/secondary idea, but I > can give some motivation for this idea. We realized that one can > currently add more than one PeopleView (for example) to Gramps. > However, it doesn't quite work because when you change the active > person, all of the PeopleViews change to that person. If I remember > correctly, even changing the person on one view will change the active > person which changes the other PeopleViews. Thanks for clarifying this. I have just tried adding another person view, and as you say, it works but is linked to the first person view and also the pedigree view and relationship view. Where there is only one person view the link to the pedigree view and relationship view is useful. If there is more than one person view which active person signals do the pedigree view and relationship view respond to? Can the user choose? If a gramplet responds to active person signals, which ones? Should it be possible to have 3 person views? > > I'm not certain that having more than one view of a type is a good > idea, nor if it is a god idea to have primary/secondary status among > them. But, as Benny said, something to think about as we rework this area. > I'll keep this in mind but it would be probably best to have only one active object of each type at a time. > -Doug > > > > > > >> All should move to src/gui/views > >> > > > > I have read the GEP. > > > > Do you want to split PageView, BookMarkView, NavigationView and > ListView > > into separate files? > > yes, so views/pageview.py with PageView, .... > Note that there is a bug item to move to setup.py for installation. > That would save us a lot of time as we no longer have to change > Makefile.am for every file moved. > If I say a view would have a configuration screen, then that means a > hook for that is added to PageView, ... . > As I'd like to have views pluggable, ViewManager would obtain the list > of views to show, and load them. The configuration of views would have > a general section, where people can add/remove views or sort them > differently. > > >> 4. I think treeview should extend listview, and then peopleview can > >> inherit from there. We can then make a placeview that shows > places in > >> a treeview. > >> > >> > > > > Possibly but they should be very similar. treeview will have > functionality > > for expand/collapse nodes and will have to deal with nodes with > handles > > differently from those without. listview has column sorting > functionality > > but treeview does not. Do we want to add column sorting treeviews? > > It is one of the most requested features: > http://www.gramps-project.org/bugs/view.php?id=568 > > I have assigned it to myself when I started the work on flatbasemodel. > So yes, I am hoping that the approach there allows for quick sort in > the treemodel. > Note that I would not make the the root node sortable, clicking a > column would eg sort on date within a surname. > I would however add also a person view based on flatbasemodel as a > view, and allow switching from treeview to flatview. In flatview one > can sort on all columns. > Well, this is only in the idea phase for myself, I did not start any > of the tree stuff, except some ideas in my head. > > >> My final goal here is to make views plugins, and to change the > sidebar > >> to have at the top a series of small icons: one icon to > minimize the > >> sidebar, one icon to switch view type (so you could cycle > person view > >> from flat view to treeview, pedigree view from horizontal to > vertical, > >> ...), and one icon for configuration, which would bring up a > >> configuration dialog related to the view seen. That would be better > >> usability than having view configuration scattered around. Eg the > >> configuration dialog of a listview can show the column editor in a > >> tab, for a treeview the column editor in a tab and how the top > nodes > >> must be formed in another, .... > >> > >> > > > > Yes, that sounds good. Are you planning this for 3.2 or is it > more of a > > long-term goal? > > 3.2 is for beginning of 2010, so if this is reachable with a > conclusion around new year, then there are some months for testing and > making it solid, before 3.2 is released. > That is the same for all new stuff, it should land at the latest > around new year. > > Benny > > > >> Benny > >> > >>> > >>> I have looked at PageView but haven't made any changes yet. I > created a > >>> PersonView which inherits from ListView - it displays the tree > and the > >>> search/filter works but nothing else. > >>> > >>> What is the best way for me to contribute this to the project? > >>> > >>> Regards, > >>> > >>> > >>> Nick. > >>> > >>> Benny Malengier wrote: > >>> > >>>> > >>>> All this discussion is nice, but as indicated, it has been > discussed > >>>> many, many times before. > >>>> I have a clear idea from the past what has to happen to make > place > >>>> more workable while not turning GRAMPS into a place management > >>>> software instead of a genealogy software. > >>>> > >>>> I want to be firm on this, changing place handling can only > be added > >>>> to GRAMPS if some old,and in need of maintenance code, is > rewritten > >>>> first. It is unacceptable that features are always added on > top of the > >>>> existing infrastructure, without redoing stuff from time to time. > >>>> > >>>> So if anybody is serious of changing the place > infrastructure, the > >>>> first thing that must happen is: help with the rewrite of > PageView.py > >>>> and the models for the listviews. PersonView should inherit > from the > >>>> same classes as the other listviews, all views must be > navigationviews > >>>> (backward/forward). > >>>> I started by rewriting the listview model in > /gui/views/models, same > >>>> must happen for a treeview model. As a bonus making sure > views can be > >>>> pluggable would be nice (you could then experiment with different > >>>> place views). > >>>> > >>>> Once this is in place, without changing the database > structure, one > >>>> can already show places in a treeview just as persons is > done, which > >>>> would make the navigation of places already much more easy > and would > >>>> allow some other things in software only (drop down of > already used > >>>> countries, ...). > >>>> > >>>> Sorry to say things a bit sharply, but I really feel in this > one that > >>>> some of the interface fundamentals must be cleaned up before > adding > >>>> things like a new place structure on top of it. > >>>> Anyway, the design of another place structure would take a lot of > >>>> work. I really don't care much in this case for the 'trust > me, I'll > >>>> start coding and you'll see when it is finished that it is good' > >>>> approach. I don't mind loosing some control, but things must > be done > >>>> logically correct so that maintenance is clear. > >>>> > >>>> Benny > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 > >>>> 30-Day trial. Simplify your report design, integration and > deployment - > >>>> and > >>>> focus on what you do best, core application coding. Discover > what's new > >>>> with > >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july > >>>> _______________________________________________ > >>>> Gramps-devel mailing list > >>>> Gra...@li... > <mailto:Gra...@li...> > >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >>>> > >>>> > >>>> > >>>> > >> > >> > >> > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. > Jumpstart your > developing skills, take BlackBerry mobile applications to market > and stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Benny M. <ben...@gm...> - 2009-09-17 14:43:54
|
2009/9/17 Nick Hall <nic...@ho...>: > > > Doug Blank wrote: >> >> On Thu, Sep 17, 2009 at 3:28 AM, Benny Malengier >> <ben...@gm... <mailto:ben...@gm...>> wrote: >> >> 2009/9/17 Nick Hall <nic...@ho... >> <mailto:nic...@ho...>>: >> > >> > >> > Benny Malengier wrote: >> >> >> >> 2009/9/16 Nick Hall <nic...@ho... >> <mailto:nic...@ho...>>: >> >> >> >>> >> >>> Benny, >> >>> >> >>> I'd like to help with the re-write and then perhaps test a new >> place >> >>> view. >> >>> >> >>> So far I have split out the code for PeopleModel so that it >> inherits from >> >>> a >> >>> new TreeBaseModel. I have also enhanced the node map so that >> it supports >> >>> more than two levels of hierarchy. >> >>> >> >> >> >> Great to hear this. >> >> Unfortunately, I leave for conference friday and have very >> little time >> >> now. >> >> The best way forward is that: >> >> 1. I review your code. Send it my way or add it to a bug list >> >> >> > >> > I was hoping that after changing PeopleModel and creating the new >> > TreeBaseModel then I could create a patch that would work. However, >> > PersonView accesses the node map data structures directly. As I >> have >> > changed the implementation of the node map this will break things. >> >> I'd be interested in seeing the node implementation. >> The work I did with src/gui/views/flatbasemodel is a nice speedup over >> the old implementation. The aim would be to do as good with >> treemodels. >> But for place, I would guess there should be a node for country, one >> for state, one for city, so more than one node. I did not yet think >> this out myself if different nodemaps are needed for that, or one can >> design one to do it >> >> > >> > It is probably better if I send you fully working code, but I am >> happy to >> > send you something to look at earlier. >> >> it's good to share design ideas before all code is finished. >> >> >> >> 2. Depending on my judgement, I give you svn access and check your >> >> code post change instead of pre change >> >> >> > >> > I don't mind sending you patches. >> >> yes, but I don't have time to review all patches in a timely manner. I >> still have one from you in my inbox ... >> >> >> 3. I let you know how I think PageView should be split up. The >> idea is >> >> to have a series of objects that slowly adds functionality, >> with real >> >> views inheriting from the base view that they need. >> >> So all listviews should be bookmarkviews and navigation views. >> >> Something like Pedigreeview would not be a listview, but still a >> >> bookmarkview or navigationview, something like the GrampletView >> would >> >> inherit from the base class as it does not need navigation or >> >> bookmark. >> >> >> > >> > So we will have: >> > >> > PageView -> BookMarkView -> NavigationView -> ListView >> > All list based views will inherit from ListView. >> > >> > Pedigreeview and RelationshipView will inherit from NavigationView. >> > GrampletView will inherit from PageView. >> > GeoView will inherit from HTMLView which inherits from PageView. >> > >> > Have I got BookMarkView and NavigationView the right way? >> >> Yes, this one has me annoyed too. I believe every navigationview >> should be a bookmarkview, so perhaps better to make it one single >> class instead of split over two. If split, the order if the split >> (first bookmark then navigation) is not the point. >> >> Perhaps we can also put all functionality for an 'active' item in a >> single class. Now only person has an 'active person' signal which >> treeview responds too, same thing is wanted for places, families, ... >> . Then outside actions can change the active object and the view >> updates. Doug would like to have primary active, secondary active, ... >> also, that is, he would like to put 2 person views in his setup, and >> have one react to/emit the primary active signal, the other to the >> secondary active. Well, just something to keep in the back of our >> mind. >> >> >> Nick, >> >> Thanks for tackling this! I think that fixing the Views will allow other >> enhancements to fall into place. >> >> I don't really have an opinion on this primary/secondary idea, but I can >> give some motivation for this idea. We realized that one can currently add >> more than one PeopleView (for example) to Gramps. However, it doesn't quite >> work because when you change the active person, all of the PeopleViews >> change to that person. If I remember correctly, even changing the person on >> one view will change the active person which changes the other PeopleViews. > > Thanks for clarifying this. > > I have just tried adding another person view, and as you say, it works but > is linked to the first person view and also the pedigree view and > relationship view. Where there is only one person view the link to the > pedigree view and relationship view is useful. > > If there is more than one person view which active person signals do the > pedigree view and relationship view respond to? Can the user choose? If a > gramplet responds to active person signals, which ones? Should it be > possible to have 3 person views? > >> >> I'm not certain that having more than one view of a type is a good idea, >> nor if it is a god idea to have primary/secondary status among them. But, as >> Benny said, something to think about as we rework this area. >> > I'll keep this in mind but it would be probably best to have only one active > object of each type at a time. Yes, well, multiple views also means one could do split views and such. Not saying that we need that though. I would expect that it might be as easy as viewmanager/displaystate having a counter for a viewclass and the signal to active-object be connected to only the view with counter 0. Anyway, I am in favour of blocking multiple same object views in viewmanager if we don't support it explicitly. Benny |