Enhancements to place hierarchy

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Enhancements to place hierarchy

Nick Hall
I have been thinking about possible enhancements to the place
hierarchy.  The following is a list with related bug reports and feature
requests:

1. Place displayer

7942: Make place title date dependent
8057: Need a way to disable auto updating of place titles

I have a prototype for this that I am testing.  The idea is to construct
a place title dynamically from place names.

2. Sidebar filter

7860: sidebar Filters dont match placetypes in new placeview

This is a request for an updated place sidebar filter. The suggestion in
the bug report sounds reasonable.

3. Place reference editor

8058: Enclosing places tab should work like other similar tabs
8056: Places cannot be dragged into the "Enclosed by" list

I have started to code a new place reference editor.  The "enclosed by"
tab in the place editor could then have the standard "add", "share" and
"edit" buttons.

4. Tree View and selector

7943: Place tree view: show every hierarchy possibility

I can understand why this has been requested, but don't really know what
we want.

We are also thinking about database enhancements for v4.2.

A.  Place names

Add a language code, date, and source citation list to all place names.

B. Place types

Allow more than one place type.  Each place type would have a date and
source citation list.

C. Place references

Add a hierarchy type and source citation list.  Hierarchy types could
include "Political", "Religious", "Geographic" etc...

I doubt that I can manage all of these for v4.2, so your comments would
be useful.  What is most important for you?  How far should we enhance
the current functionality?  Is it getting too complicated?

Regards,


Nick.


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Philip Weiss
B. Place types
Allow more than one place type.  Each place type would have a date and
source citation list.

In a previous message to the list I've asked about this, but I've since changed my mind and probably wouldn't use it.  I've come to the conclusion that I want to treat Washington the state as a different place than Washington the territory, and Lubeck the city as a different entity than Lubeck the Free Hanseatic City (i.e., country). (Obviously, if the feature were added, it's not like I have to use it.  I'm just saying I've come around to where I probably wouldn't.)

3. Place reference editor
8058: Enclosing places tab should work like other similar tabs
8056: Places cannot be dragged into the "Enclosed by" list
I have started to code a new place reference editor.  The "enclosed by"
tab in the place editor could then have the standard "add", "share" and
"edit" buttons. 
4. Tree View and selector
7943: Place tree view: show every hierarchy possibility
I can understand why this has been requested, but don't really know what
we want.

I think I would be more interested in something similar but not exactly a tree view.  What's kind of in my mind is a Relationships view but for Places.  It would serve two purposes.  The first is a nice view of what containing places I need to look for records in.  I.e., Death is in place X. What entities will have records for that place?  For that, I need to look at the city, county, parish, etc that the death occurred in.  Having a way to see that would be helpful.  The second is I may want to jump around to add, remove, or edit related places in the hierarchy.  For people and families, the Relationship view has been so much more useful for that than the Person or Family views.  I wish we had something similar for Citations/Sources/Repositories, Places, and Events.

Thanks for all the hard work on places.  I hope this doesn't come off as carping about it being done badly, cause I love the hierarchy work.

Phil.


On Wed, Jan 21, 2015 at 4:10 PM, Nick Hall <[hidden email]> wrote:
I have been thinking about possible enhancements to the place
hierarchy.  The following is a list with related bug reports and feature
requests:

1. Place displayer

7942: Make place title date dependent
8057: Need a way to disable auto updating of place titles

I have a prototype for this that I am testing.  The idea is to construct
a place title dynamically from place names.

2. Sidebar filter

7860: sidebar Filters dont match placetypes in new placeview

This is a request for an updated place sidebar filter. The suggestion in
the bug report sounds reasonable.

3. Place reference editor

8058: Enclosing places tab should work like other similar tabs
8056: Places cannot be dragged into the "Enclosed by" list

I have started to code a new place reference editor.  The "enclosed by"
tab in the place editor could then have the standard "add", "share" and
"edit" buttons.

4. Tree View and selector

7943: Place tree view: show every hierarchy possibility

I can understand why this has been requested, but don't really know what
we want.

We are also thinking about database enhancements for v4.2.

A.  Place names

Add a language code, date, and source citation list to all place names.

B. Place types

Allow more than one place type.  Each place type would have a date and
source citation list.

C. Place references

Add a hierarchy type and source citation list.  Hierarchy types could
include "Political", "Religious", "Geographic" etc...

I doubt that I can manage all of these for v4.2, so your comments would
be useful.  What is most important for you?  How far should we enhance
the current functionality?  Is it getting too complicated?

Regards,


Nick.


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Ron Johnson
In reply to this post by Nick Hall
On 01/22/2015 12:38 AM, Philip Weiss wrote:
[snip]
4. Tree View and selector
7943: Place tree view: show every hierarchy possibility
I can understand why this has been requested, but don't really know what
we want.

I think I would be more interested in something similar but not exactly a tree view.  What's kind of in my mind is a Relationships view but for Places.  It would serve two purposes.  The first is a nice view of what containing places I need to look for records in.  I.e., Death is in place X. What entities will have records for that place?  For that, I need to look at the city, county, parish, etc that the death occurred in.  Having a way to see that would be helpful.  The second is I may want to jump around to add, remove, or edit related places in the hierarchy.  For people and families, the Relationship view has been so much more useful for that than the Person or Family views.  I wish we had something similar for Citations/Sources/Repositories, Places, and Events.

+1.  This is pretty much what I was talking about...

Thanks for all the hard work on places.  I hope this doesn't come off as carping about it being done badly, cause I love the hierarchy work.

My places just need more cleaning up...  :(

-- 
My word, man!  Don't you know your quantum statistics?

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Sebastian Schubert
In reply to this post by Nick Hall
Hi Nick,

here my *personal* view.

On 22/01/15 01:10, Nick Hall wrote:
> 1. Place displayer
>
> 7942: Make place title date dependent
> 8057: Need a way to disable auto updating of place titles
>
> I have a prototype for this that I am testing.  The idea is to construct
> a place title dynamically from place names.

> 4. Tree View and selector
>
> 7943: Place tree view: show every hierarchy possibility
>
> I can understand why this has been requested, but don't really know what
> we want.

I am certainly biased because two of the requests are by me. I find the
 date-dependent place title essential for the inclusion of a place
hierarchy in a genealogical program. With a fixed title, the place
hierarchy exists in the data only for its own sake. Thus, I would put
the priority here.

With the implementation of a varying place title, the currently shown
place hierarchy in the places view becomes even more arbitrary. It's
hard to find a place without using the search tool. This is inconvenient
but not a showstopper.

> We are also thinking about database enhancements for v4.2.
>
> A.  Place names
>
> Add a language code, date, and source citation list to all place names.

So far the simple list of alternative names was sufficient for me.
However, if a more detailed approach was available, I would use it.

> B. Place types
>
> Allow more than one place type.  Each place type would have a date and
> source citation list.

Currently, the place type is not that important for me so I created a
"Diverse" place type for the cases when it changed. Again, I would use a
more detailed approach.

> C. Place references
>
> Add a hierarchy type and source citation list.  Hierarchy types could
> include "Political", "Religious", "Geographic" etc...

Currently, I think, I would not use this feature.

Thanks a lot for your great work!

Sebastian

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Nick Hall
In reply to this post by Philip Weiss
On 22/01/15 06:38, Philip Weiss wrote:

> I think I would be more interested in something similar but not
> exactly a tree view.  What's kind of in my mind is a Relationships
> view but for Places.  It would serve two purposes.  The first is a
> nice view of what containing places I need to look for records in.  
> I.e., Death is in place X. What entities will have records for that
> place?  For that, I need to look at the city, county, parish, etc that
> the death occurred in.  Having a way to see that would be helpful.  
> The second is I may want to jump around to add, remove, or edit
> related places in the hierarchy.  For people and families, the
> Relationship view has been so much more useful for that than the
> Person or Family views.  I wish we had something similar for
> Citations/Sources/Repositories, Places, and Events.
>

I wrote a prototype back in March 2014 to demonstrate the concept of a
viewer.  A viewer was optimised to view data rather than edit it.

I wrote three viewers:

Person
Event
Citation/Source/Repository

These viewers were based upon the Relationship view.  The idea was that
several layers of objects could be displayed.

The prototype got virtually no response from the other developers, so I
abandoned it.  There is still a branch called "viewer" on my SF git
fork, if anyone is interested.

Nick.


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Nick Hall
In reply to this post by Sebastian Schubert
Sebastian,

It was your personal view I was asking for.

I agree with you that a place displayer is essential.  It has already been written and will be included in v4.2.  We could possibly also offer it in v4.1.2 as an experimental feature.

A new sidebar filter can be offered as a third-party plugin at any time.

I'm not sure about a new place reference editor.  I'll probably have to write it before I can make up my mind.

Unfortunately, at the moment, Gramps views only allow an object to appear once in a hierarchy.  Changing this would involve a big re-write.  I'm still trying to think of other ideas.

The good news is that we have a new developer who would like to write the code to enhance place names.

Nick.


On 22/01/15 15:16, Sebastian Schubert wrote:
Hi Nick,

here my *personal* view.

On 22/01/15 01:10, Nick Hall wrote:
1. Place displayer

7942: Make place title date dependent
8057: Need a way to disable auto updating of place titles

I have a prototype for this that I am testing.  The idea is to construct 
a place title dynamically from place names.

      
4. Tree View and selector

7943: Place tree view: show every hierarchy possibility

I can understand why this has been requested, but don't really know what 
we want.
I am certainly biased because two of the requests are by me. I find the
 date-dependent place title essential for the inclusion of a place
hierarchy in a genealogical program. With a fixed title, the place
hierarchy exists in the data only for its own sake. Thus, I would put
the priority here.

With the implementation of a varying place title, the currently shown
place hierarchy in the places view becomes even more arbitrary. It's
hard to find a place without using the search tool. This is inconvenient
but not a showstopper.

We are also thinking about database enhancements for v4.2.

A.  Place names

Add a language code, date, and source citation list to all place names.
So far the simple list of alternative names was sufficient for me.
However, if a more detailed approach was available, I would use it.

B. Place types
here my *personal* view.

Allow more than one place type.  Each place type would have a date and 
source citation list.
Currently, the place type is not that important for me so I created a
"Diverse" place type for the cases when it changed. Again, I would use a
more detailed approach.

C. Place references

Add a hierarchy type and source citation list.  Hierarchy types could 
include "Political", "Religious", "Geographic" etc...
Currently, I think, I would not use this feature.

Thanks a lot for your great work!

Sebastian




------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

enno
In reply to this post by Nick Hall
Nick,

I hope I'm not too late ... :-)
> We are also thinking about database enhancements for v4.2.
>
> A.  Place names
>
> Add a language code, date, and source citation list to all place names.
Not on the name level. I prefer the GEDCOM X approach, where a place can
have multiple names with a language code each, and a type, date (range),
and citation list.
> B. Place types
>
> Allow more than one place type.  Each place type would have a date and
> source citation list.
Not needed. One can easily define multiple places with the same name and
a different type, date, and citation list.
> C. Place references
>
> Add a hierarchy type and source citation list.  Hierarchy types could
> include "Political", "Religious", "Geographic" etc...
I think that the hierarchy type can be derived from the enclosing type,
meaning that if the latter is a parish, it's obvious.
> I doubt that I can manage all of these for v4.2, so your comments would
> be useful.  What is most important for you?  How far should we enhance
> the current functionality?  Is it getting too complicated?
Looking at what's currently in master, I'd say the language code is
important to me, if it's kept simple, like in GEDCOM X. This can be
easily done by adding a language code to the alternative names as they
appear in master. For symmetry, the main name needs a language code too,
of course.

My other wish is to have the titles generated, as an option.

thanks,

Enno


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Nick Hall
Enno,

I don't expect v4.2 to be released until June, so we still have some time.

An example would be helpful.  I'm after user input here and I don't
think many people will be familiar with GEDCOM X.

In Gramps, I think that we should have one place object per place.  I
don't want to create a separate place for the Duchy of Prussia, the
Kingdom of Prussia, and the Free State of Prussia for example.   This
information, if required, should be part of an object representing Prussia.

Places can also change name over time.  Saint Petersburg is a good
example.  It should be the same place object, even when called Leningrad
or Petrograd.

Do we want to model name changes?  Do we want to model type changes?  
What should the user interface look like?

Nick.


On 23/01/15 22:15, Enno Borgsteede wrote:

> I hope I'm not too late ...:-)
>> >We are also thinking about database enhancements for v4.2.
>> >
>> >A.  Place names
>> >
>> >Add a language code, date, and source citation list to all place names.
> Not on the name level. I prefer the GEDCOM X approach, where a place can
> have multiple names with a language code each, and a type, date (range),
> and citation list.
>> >B. Place types
>> >
>> >Allow more than one place type.  Each place type would have a date and
>> >source citation list.
> Not needed. One can easily define multiple places with the same name and
> a different type, date, and citation list.
>> >C. Place references
>> >
>> >Add a hierarchy type and source citation list.  Hierarchy types could
>> >include "Political", "Religious", "Geographic" etc...
> I think that the hierarchy type can be derived from the enclosing type,
> meaning that if the latter is a parish, it's obvious.
>> >I doubt that I can manage all of these for v4.2, so your comments would
>> >be useful.  What is most important for you?  How far should we enhance
>> >the current functionality?  Is it getting too complicated?
> Looking at what's currently in master, I'd say the language code is
> important to me, if it's kept simple, like in GEDCOM X. This can be
> easily done by adding a language code to the alternative names as they
> appear in master. For symmetry, the main name needs a language code too,
> of course.


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

enno
Nick,

> I don't expect v4.2 to be released until June, so we still have some time.
>
> An example would be helpful.  I'm after user input here and I don't
> think many people will be familiar with GEDCOM X.
>
> In Gramps, I think that we should have one place object per place.  I
> don't want to create a separate place for the Duchy of Prussia, the
> Kingdom of Prussia, and the Free State of Prussia for example.   This
> information, if required, should be part of an object representing Prussia.
>
> Places can also change name over time.  Saint Petersburg is a good
> example.  It should be the same place object, even when called Leningrad
> or Petrograd.
>
> Do we want to model name changes?  Do we want to model type changes?
> What should the user interface look like?
Well, I'm quite a minimalist, and I still work with 3.4, and will
probably continue to do so until 4.2 is released, so we have some time
indeed.

Having one place object per place makes sense, and implies that name and
type can change over time, although that is somewhat against the GEDCOM
X model. That's not that bad though, because I don't see much reason to
support GEDCOM X other than to talk to FamilySearch servers, and type is
an optional field in GEDCOM X anyway.

All in all, I don't really want to duplicate the full functionality of
the GOV, and in many cases, I don't care whether Preussen was a kingdom
or a free state, just like I can't really distinguish boroughs from
other things that are also quite alien to me. In an minimalist approach,
I work with enough levels to make a place description unique, and right
to its era, and that's it. Preussen may then be the top level of the
hierarchy for the 18th century, no matter kingdom, republic, whatever.
Type country would be enough, and the only thing I do care about is that
it works right at the GEDCOM (X) level, both ways, meaning that I would
love to see a qualified name being matched with existing locations on
import, wherever possible.

In my own tree, there aren't many place changes, because my own country
has been quite stable over years, and immigrant data applies to small
eras, so I don't always care about name changes in their place of
origin. I do care about proper data exchange though, and the big sites
don't really care about such changes. They just want some sort of
normalized string, one that I may not really like to use in my own
reports or screens, but 'must' be available on export. That's my
ecosystem, and the main requirement for that probably is that we succeed
in making Gramps a little smarter here.

regards,

Enno


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Nick Hall
On 25/01/15 21:22, Enno Borgsteede wrote:
> Well, I'm quite a minimalist, and I still work with 3.4, and will
> probably continue to do so until 4.2 is released, so we have some time
> indeed.

The initial implementation is fairly minimal.

> Having one place object per place makes sense, and implies that name and
> type can change over time, although that is somewhat against the GEDCOM
> X model. That's not that bad though, because I don't see much reason to
> support GEDCOM X other than to talk to FamilySearch servers, and type is
> an optional field in GEDCOM X anyway.

We can still use GEDCOM X to transfer data, even if our database doesn't
mirror its design.

>
> All in all, I don't really want to duplicate the full functionality of
> the GOV, and in many cases, I don't care whether Preussen was a kingdom
> or a free state, just like I can't really distinguish boroughs from
> other things that are also quite alien to me. In an minimalist approach,
> I work with enough levels to make a place description unique, and right
> to its era, and that's it. Preussen may then be the top level of the
> hierarchy for the 18th century, no matter kingdom, republic, whatever.
> Type country would be enough, and the only thing I do care about is that
> it works right at the GEDCOM (X) level, both ways, meaning that I would
> love to see a qualified name being matched with existing locations on
> import, wherever possible.

I don't want to duplicate the functionality of any site.

GEDCOM X provides a name and type for each level of jurisdiction, which
should be enough for matching places on import.

> In my own tree, there aren't many place changes, because my own country
> has been quite stable over years, and immigrant data applies to small
> eras, so I don't always care about name changes in their place of
> origin. I do care about proper data exchange though, and the big sites
> don't really care about such changes. They just want some sort of
> normalized string, one that I may not really like to use in my own
> reports or screens, but 'must' be available on export. That's my
> ecosystem, and the main requirement for that probably is that we succeed
> in making Gramps a little smarter here.

We don't have to export a hierarchy of places.  It is easy to format a
normalised string.

Nick.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Sebastian Schubert
In reply to this post by Nick Hall
Hi Nick,
> 1. Place displayer
>
> 7942: Make place title date dependent
> 8057: Need a way to disable auto updating of place titles
>
> I have a prototype for this that I am testing.  The idea is to construct
> a place title dynamically from place names.

I've seen that you commited your changes. Thanks a lot for that! Do you
want bug reports already? Here or on the bug tracker?

Anyway, I guess you cannot stop me now :), so here two comments:

1) The dynamic title misses higher levels if a date of type "after" is
used. For example:

A is in B between 400 and 1200. B is in C after 600. An event with date
1000 happening in A shows "A, B" as the place although I would expect
"A, B, C".

2) With dynamic title generation, the given title of a place is
obviously not that important anymore. However, as far as I can see, the
automatic generation of the title in the place editor is disabled in all
cases now. Here, I would propose to re-enable it if the displayed title
is generated dynamically. Without that, one would have unnecessary work.

Cheers,
Sebastian

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Nick Hall
On 28/01/15 19:49, Sebastian Schubert wrote:

> I've seen that you commited your changes. Thanks a lot for that! Do you
> want bug reports already? Here or on the bug tracker?
>
> Anyway, I guess you cannot stop me now:), so here two comments:
>
> 1) The dynamic title misses higher levels if a date of type "after" is
> used. For example:
>
> A is in B between 400 and 1200. B is in C after 600. An event with date
> 1000 happening in A shows "A, B" as the place although I would expect
> "A, B, C".

Make sure that the "Date after range" in the Date tab of the
Perferences, is set to a large number (>400).

>
> 2) With dynamic title generation, the given title of a place is
> obviously not that important anymore. However, as far as I can see, the
> automatic generation of the title in the place editor is disabled in all
> cases now. Here, I would propose to re-enable it if the displayed title
> is generated dynamically. Without that, one would have unnecessary work.

If you have the place displayer set to "Automatic", just leave the title
field empty.

Nick.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Sebastian Schubert
Hi Nick,

On 28/01/15 21:37, Nick Hall wrote:

> On 28/01/15 19:49, Sebastian Schubert wrote:
>> 1) The dynamic title misses higher levels if a date of type "after" is
>> used. For example:
>>
>> A is in B between 400 and 1200. B is in C after 600. An event with date
>> 1000 happening in A shows "A, B" as the place although I would expect
>> "A, B, C".
>
> Make sure that the "Date after range" in the Date tab of the
> Perferences, is set to a large number (>400).

Thanks for the hint. Didn't know the settings and it is working fine
now! Thanks a lot!

>> 2) With dynamic title generation, the given title of a place is
>> obviously not that important anymore. However, as far as I can see, the
>> automatic generation of the title in the place editor is disabled in all
>> cases now. Here, I would propose to re-enable it if the displayed title
>> is generated dynamically. Without that, one would have unnecessary work.
>
> If you have the place displayer set to "Automatic", just leave the title
> field empty.

Gramps doesn't let me save a place without title. "You must enter a
title before saving." So alternatively, disable this warning with
automatic title generation?

Cheers
Sebastian

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Nick Hall
On 29/01/15 09:05, Sebastian Schubert wrote:
>> If you have the place displayer set to "Automatic", just leave the title
>> >field empty.
> Gramps doesn't let me save a place without title. "You must enter a
> title before saving." So alternatively, disable this warning with
> automatic title generation?

I have removed the check for empty titles in the place editor.

Should we hide the title field when automatic title generation is selected?

Nick.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Enhancements to place hierarchy

Sebastian Schubert
>>> If you have the place displayer set to "Automatic", just leave the title
>>> >field empty.
>> Gramps doesn't let me save a place without title. "You must enter a
>> title before saving." So alternatively, disable this warning with
>> automatic title generation?
>
> I have removed the check for empty titles in the place editor.

Thanks.

> Should we hide the title field when automatic title generation is selected?

Can you grey out the field and its content? I would suggest that and
adding a tooltip about the "automatic title" option. By that one can
still see what the content of the field in the data is.

Cheers
Sebastian


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users