A few thoughts on 2.2

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

A few thoughts on 2.2

Don Allingham
We have been making some significant progress on the 2.1/2.2 branch of
GRAMPS. While this version is a long way from being ready to release, it
has become quite an exciting time for the project. Some of the new
features that we have already implemented are:

1) Sharable events
2) Repositories
3) A new Map View
4) Intelligent menus and toolbars
5) A new Pedigree View that displays photos
6) A simplified Edit Person dialog
7) Start of an improved Family View.
8) Major database performance improvements for some searches (over 100x
   faster)

Some screenshots are available at the Developer's site.
http://developers.gramps-project.org/tiki-browse_gallery.php?galleryId=1


Architectural changes include:

1) New "pluggable view" architecture that allows us to easily add new
   views into the program.
2) Removal of much of the GNOME dependent code, relying more on GTK.
   The program can now be built (at the cost of a few features)
   without GNOME libraries.
3) A much cleaner internal architecture

With the removal of the GNOME dependencies, the issue of porting to
other platforms starts to come up (especially since there is a serious
project porting GTK to OS X). I've posted my thoughts on this to the
GRAMPS blog site (http://blog.gramps-project.org)

Don


--
Don Allingham
http://don.allingham.org

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

Joachim Breitner
Hi,

Am Freitag, den 30.12.2005, 16:12 -0700 schrieb Don Allingham:
> 7) Start of an improved Family View.

Looks nice. One thing I have been missing in the family view is a button
next to each child which will make that person the active person.
Currently, I have to click on the child and then press the "<=" button,
which is one click too much, IMHO.

Also, in the new view (as of
http://developers.gramps-project.org/tiki-browse_image.php?imageId=4 ),
the "=>" button to move to the parent's family has disappeared. Is the
new downwards button for that?

Personally, I'd like to have buttons for every child for all child
actions (looking at the context menu, I find "select this person", "edit
person", "edit relationship" and "delete relationship") per child, i.e.
a column in the child view that contains these or some of these four
buttons.

The advantage is one click less and intuitive discovery of features, the
downside is that this might be less HIG-compliant and a bit bloated.

Thanks,
Joachim

--
Joachim "nomeata" Breitner
  mail: [hidden email] | ICQ# 74513189 | GPG-Key: 4743206C
  JID: [hidden email] | http://www.joachim-breitner.de/
  Debian Developer: [hidden email]
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

Don Allingham
On Sat, 2005-12-31 at 11:55 +0100, Joachim Breitner wrote:
> Hi,
>
> Am Freitag, den 30.12.2005, 16:12 -0700 schrieb Don Allingham:
> > 7) Start of an improved Family View.
>
> Looks nice. One thing I have been missing in the family view is a button
> next to each child which will make that person the active person.
> Currently, I have to click on the child and then press the "<=" button,
> which is one click too much, IMHO.

This is a limitation of GTK. We cannot embed an button in the list.
We've already looked into this.

>
> Also, in the new view (as of
> http://developers.gramps-project.org/tiki-browse_image.php?imageId=4 ),
> the "=>" button to move to the parent's family has disappeared. Is the
> new downwards button for that?

Yes. Since we have a top-down approach on this, you move the parents
"down" to the active person, and the children "up" to the active person.

> Personally, I'd like to have buttons for every child for all child
> actions (looking at the context menu, I find "select this person", "edit
> person", "edit relationship" and "delete relationship") per child, i.e.
> a column in the child view that contains these or some of these four
> buttons.
>
> The advantage is one click less and intuitive discovery of features, the
> downside is that this might be less HIG-compliant and a bit bloated.
>
> Thanks,
> Joachim
>
--
Don Allingham
http://don.allingham.org

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

Joachim Breitner
Hi,

Am Samstag, den 31.12.2005, 08:22 -0700 schrieb Don Allingham:
> On Sat, 2005-12-31 at 11:55 +0100, Joachim Breitner wrote:
> > Looks nice. One thing I have been missing in the family view is a button
> > next to each child which will make that person the active person.
> > Currently, I have to click on the child and then press the "<=" button,
> > which is one click too much, IMHO.
>
> This is a limitation of GTK. We cannot embed an button in the list.
> We've already looked into this.

I searched the archive, but I couln't find it. Skimming through the gtk
docs, it seems that we nee something like GtkCellRendererToggle, that
behaves like a button. That should be possible to implement, but that is
something that can easily be contributed, to not distract the gramps
developers from their core work :-)

The question is: Is this actually wanted, or rather not?

Thanks and a happy new year,
Joachim

--
Joachim Breitner
  e-Mail: [hidden email]
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

Doug Blank
In reply to this post by Joachim Breitner
Joachim said,

> Am Freitag, den 30.12.2005, 16:12 -0700 schrieb Don Allingham:
>> 7) Start of an improved Family View.
>
> Looks nice. One thing I have been missing in the family view is a button
> next to each child which will make that person the active person.
> Currently, I have to click on the child and then press the "<=" button,
> which is one click too much, IMHO.

I agree that getting the person to be the active person should be easier.
In fact, I always thought that in the current GUI that the right-click on
a child, then select "active person" is not the best, intuitive method. I
think that the default double-click action on any person should be to take
them to the active person position.

I do think having that many buttons for all of the children is too much,
even if it were possible.

-Doug




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

Don Allingham
In reply to this post by Joachim Breitner
I had tried this a while ago, and then abandoned it. If someone wants to
do this, I would be interested. If I remember, there were several
problems. I think (but I'm not sure) that the CellRenderer object has to
have some type of value associated with it. A CellRendererToggle has a
True/False state, a CellRendererCombo has a text value associated with
it, etc. Another problem is that we would be responsible for all
widget-like functions, including redrawing and resizing.

As far as HIG compliance, I believe in adhering to the HIG. Adding a
column of buttons would not be the default, but would be something that
is added using the Column Editor. Since the user makes a conscious
choice to add the column of buttons, they have chosen any violation of
the HIG. And as long as this is the user's choice, I can live with this.

Don

On Sat, 2005-12-31 at 17:33 +0100, Joachim Breitner wrote:

> Hi,
>
> Am Samstag, den 31.12.2005, 08:22 -0700 schrieb Don Allingham:
> > On Sat, 2005-12-31 at 11:55 +0100, Joachim Breitner wrote:
> > > Looks nice. One thing I have been missing in the family view is a button
> > > next to each child which will make that person the active person.
> > > Currently, I have to click on the child and then press the "<=" button,
> > > which is one click too much, IMHO.
> >
> > This is a limitation of GTK. We cannot embed an button in the list.
> > We've already looked into this.
>
> I searched the archive, but I couln't find it. Skimming through the gtk
> docs, it seems that we nee something like GtkCellRendererToggle, that
> behaves like a button. That should be possible to implement, but that is
> something that can easily be contributed, to not distract the gramps
> developers from their core work :-)
>
> The question is: Is this actually wanted, or rather not?
>
> Thanks and a happy new year,
> Joachim
>
--
Don Allingham
http://don.allingham.org

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

Don Allingham
In reply to this post by Doug Blank
On Sat, 2005-12-31 at 11:54 -0500, [hidden email] wrote:

> Joachim said,
>
> > Am Freitag, den 30.12.2005, 16:12 -0700 schrieb Don Allingham:
> >> 7) Start of an improved Family View.
> >
> > Looks nice. One thing I have been missing in the family view is a button
> > next to each child which will make that person the active person.
> > Currently, I have to click on the child and then press the "<=" button,
> > which is one click too much, IMHO.
>
> I agree that getting the person to be the active person should be easier.
> In fact, I always thought that in the current GUI that the right-click on
> a child, then select "active person" is not the best, intuitive method. I
> think that the default double-click action on any person should be to take
> them to the active person position.
The problem is consistency. We have a lot of possible actions in the
Family View - more than we can comfortably apply to buttons. As Joachim
pointed out, you can use the arrow button next to the child list to make
a child the active person - you don't have to use the context menu.

I would like to be as consistent as possible. Throughout the interface,
double clicking on a person in a list brings up the object in an Editor.
If we change the definition here, it could be confusing for many users.

However, that being said, I personally find the current Family View to
be very inconsistent and confusing.

I think the best approach would be to define the screen, define the
required actions, prioritize and then figure out what actions to assign
to buttons, menus, and clicks.

I try to post an explanation of my this screenshot in a day or so, and
hopefully we can work on what is good, what is bad, and what needs to be
assigned to what.

http://developers.gramps-project.org/show_image.php?id=4

I don't see this as a final product.

>
> I do think having that many buttons for all of the children is too much,
> even if it were possible.
>
> -Doug

I would agree with this. However, I think Joachim's embedded buttons
would work as long as it is not the default. It is different if the user
has chosen to do this.

I recently had someone send me a screenshot of Legacy's equivalent view.
It had buttons all over the place with tiny icons and no description.
Personally, I thought it was a little intimidating.

Don

--
Don Allingham
http://don.allingham.org

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

Steve Hall-4

  [Sorry this response is long, I'm passionate about Family View. :) ]

On Sat, 2005-12-31 at 11:34 -0700, Don Allingham wrote:

> On Sat, 2005-12-31 at 11:54 -0500, [hidden email] wrote:
> > Joachim said,
> > > Am Freitag, den 30.12.2005, 16:12 -0700 schrieb Don Allingham:
> > > >
> > > > 7) Start of an improved Family View.
> > >
> > > Looks nice. One thing I have been missing in the family view is
> > > a button next to each child which will make that person the
> > > active person. Currently, I have to click on the child and then
> > > press the "<=" button, which is one click too much, IMHO.

Me too, we need to figure a way to make this a single motion. It is
the most common action in family view, but it always requires two
distinct interactions.

> > I think that the default double-click action on any person should
> > be to take them to the active person position.
[snip]
> Throughout the interface, double clicking on a person in a list
> brings up the object in an Editor. If we change the definition here,
> it could be confusing for many users.

Agreed, double-clicking is intuitive and consistent to open/edit the
individual.

> However, that being said, I personally find the current Family View
> to be very inconsistent and confusing.

Neither existing or new screenshot work for me yet either...

> I think the best approach would be to define the screen, define the
> required actions, prioritize and then figure out what actions to
> assign to buttons, menus, and clicks.

Good idea.

> I try to post an explanation of my this screenshot in a day or so,
> and hopefully we can work on what is good, what is bad, and what
> needs to be assigned to what.
>
>   http://developers.gramps-project.org/show_image.php?id=4
>
> I don't see this as a final product.

Looking forward to hearing your thoughts. For me, this view has been a
struggle since the beginning. I think it keeps boiling down to the
thought below.

If Edit dialogs (Person, Marriage/Relationship, Modify Parents, etc.)
are where the user edits the data, Views (sidebar) should be for
viewing the data, the Pedigree View being an excellent example. It is
intuitive, quick, and discoverable. And it indicates everything on the
screen that one expects from a pedigree chart.

Not so for the Family View. It *should* be the electronic fulfilment
satisfied by the age old family group sheet: display a family (parents
and children) with as many facts as it can for the purposes of
understanding subtleties in the data. Pedigree is overall view, Family
up close.

However both the existing and devel Family Views maintain the same two
problems:

1. They do not display enough facts about the individuals to be a
   satisfactory close up view.
2. There are clouded by a number of editing widgets that further
   detract from the essential navigability of the form.

The first item is tough given current monitor resolutions. On paper,
typical forms have Born, Bapt., Marr., Death, Burial for two parents
and 10 children, plus occupations, military, church affiliation, other
spouses, plus room for each parent name. In the computer version, it
might be reasonable to slough off places, baptism/christening, and
burial since they are easily discoverable by editing the individual.
Gramps could automatically further condense out day and then month
info, and township, city info when there is not enough room. Certainly
not perfect (or easy) against the precedence we have had in paper for
decades, but a fair compromise given the pixels we have to work with.

However marriages of children are important, they can not be sloughed
off. This is why two-action navigation to the children's families is
problematic. It's the intuitive route to view a child's child and
bounce between the family's families quickly while sifting through the
facts.

An overlay on top of this problem are the editing widgets the user is
currently required to sift through to see data and find navigation.
Since the general toolbar and menu make these redundant, the editing
portions being indicated in the Family View can be eliminated. There
should be no need for a special button to add information in this
view, it is already intuitive via toolbar and edit dialogs.

> > I do think having that many buttons for all of the children is too
> > much, even if it were possible.
>
> I would agree with this. However, I think Joachim's embedded buttons
> would work as long as it is not the default. It is different if the
> user has chosen to do this.

Obviously from my comments above, I am arguing that this a fundamental
feature of the Family View and should be the default. To not have them
would be to keep it unusable. ;)

I also believe there is predominant precedence that these are quite
usable in this specific implementation:

  Family Tree Maker (colored arrows):
    http://www.ftm2006.com/images/FTMShotFamilyView.gif
  Personal Ancestral File:
    http://appdb.winehq.org/appimage.php?id=665
  RootsMagic:
    http://rootsmagic.com/famview.htm
  Family Historian (double chevrons):
    <a href="http://www.family-historian.co.uk/tour/Tour1%20-%20Property%">http://www.family-historian.co.uk/tour/Tour1%20-%20Property%
20Dialog.htm
  Family Tree Legends (home icon):
    http://www.familytreelegends.com/software/tour
  Legacy (blue numbers):
    http://www.legacyfamilytree.com/_images/FamilyViewLarge.gif


> I recently had someone send me a screenshot of Legacy's equivalent
> view. It had buttons all over the place with tiny icons and no
> description. Personally, I thought it was a little intimidating.

Some of these are defintely widget happy, but I thought the first
three were simple and pretty intuitive.


--
Steve Hall  [ digitect mindspring com ]




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

romjerome
> >I also believe there is predominant precedence that these are quite
> > usable in this specific implementation:
> >
> >  Family Tree Maker (colored arrows):
> >    http://www.ftm2006.com/images/FTMShotFamilyView.gif
> >  Personal Ancestral File:
> >    http://appdb.winehq.org/appimage.php?id=665
> >  RootsMagic:
> >    http://rootsmagic.com/famview.htm
> >  Family Historian (double chevrons):
> >    <a href="http://www.family-historian.co.uk/tour/Tour1%20-%20Property%">http://www.family-historian.co.uk/tour/Tour1%20-%20Property%
> >20Dialog.htm
> >  Family Tree Legends (home icon):
> >    http://www.familytreelegends.com/software/tour
> >  Legacy (blue numbers):
> >    http://www.legacyfamilytree.com/_images/FamilyViewLarge.gif

I add some screenshots :

Heredis :
http://www.heredis.com/fr/images/Descriptifs/ImagesPC/General-H8.jpg
Généalogos :
http://www.genealogos.com/descriptifs/800/img12.jpg
Reunion :
http://www.leisterpro.com/doc/Version7/NewFeatures/FlippedNames.gif

Happy new year !
Jérôme




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

romjerome
In reply to this post by Steve Hall-4
If you want idea for the next gramps display, a "french" blog list a lot of
genealogical program (don't need to understand french ... use the URL link)
http://geneabax-blog.blogspot.com/
I find an other family view and some good link for GNU/Linux users ;)
Familienbande :
http://www.familienbande-genealogie.de/Bild1.htm

Jérôme




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2 (family view)

Eero Tamminen-3
In reply to this post by Steve Hall-4
Hi,

On Sunday 01 January 2006 08:07, Steve Hall wrote:
[...]

> If Edit dialogs (Person, Marriage/Relationship, Modify Parents, etc.)
> are where the user edits the data, Views (sidebar) should be for
> viewing the data, the Pedigree View being an excellent example. It is
> intuitive, quick, and discoverable. And it indicates everything on the
> screen that one expects from a pedigree chart.
>
> Not so for the Family View. It *should* be the electronic fulfilment
> satisfied by the age old family group sheet: display a family (parents
> and children) with as many facts as it can for the purposes of
> understanding subtleties in the data. Pedigree is overall view, Family
> up close.
>
> However both the existing and devel Family Views maintain the same two
> problems:
>
> 1. They do not display enough facts about the individuals to be a
>    satisfactory close up view.
> 2. There are clouded by a number of editing widgets that further
>    detract from the essential navigability of the form.

To me "view only" family view + separate editing dialogs sounds good
and fits logically to the rest of the UI nicely.

Do you have any glade mockups of what this could look like?

I think it would need mockups also of the editing dialogs.
(My own awkward point has been editing marriage information, but
how that's done is propbably changing now with the new shared events...)


> The first item is tough given current monitor resolutions. On paper,
> typical forms have Born, Bapt., Marr., Death, Burial for two parents
> and 10 children, plus occupations, military, church affiliation, other
> spouses, plus room for each parent name. In the computer version, it
> might be reasonable to slough off places, baptism/christening, and
> burial since they are easily discoverable by editing the individual.
> Gramps could automatically further condense out day and then month
> info, and township, city info when there is not enough room. Certainly
> not perfect (or easy) against the precedence we have had in paper for
> decades, but a fair compromise given the pixels we have to work with.

I think most of the other genealogy programs UIs look too busy
when compared to the elegant Gramps UI.


> However marriages of children are important, they can not be sloughed
> off. This is why two-action navigation to the children's families is
> problematic. It's the intuitive route to view a child's child and
> bounce between the family's families quickly while sifting through the
> facts.
>
> An overlay on top of this problem are the editing widgets the user is
> currently required to sift through to see data and find navigation.
> Since the general toolbar and menu make these redundant, the editing
> portions being indicated in the Family View can be eliminated. There
> should be no need for a special button to add information in this
> view, it is already intuitive via toolbar and edit dialogs.

Or editing could be done by double-clicking to the parent/child/relation.
IMHO relation should be shown as something that can be clicked
to edit it.

Whether all this is UI-wise possible is another matter.

What if the parents would be on the top as a pair, and each child
(possibly with some info about his/her family) would a separate tab in
a notebook below?   First item in the tab would the relation to parents.


        - Eero


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2 (map view)

Eero Tamminen-3
In reply to this post by Don Allingham
Hi,

On Saturday 31 December 2005 01:12, Don Allingham wrote:

> We have been making some significant progress on the 2.1/2.2 branch of
> GRAMPS. While this version is a long way from being ready to release, it
> has become quite an exciting time for the project. Some of the new
> features that we have already implemented are:
>
> 1) Sharable events
> 2) Repositories
> 3) A new Map View
> 4) Intelligent menus and toolbars
> 5) A new Pedigree View that displays photos
> 6) A simplified Edit Person dialog
> 7) Start of an improved Family View.
> 8) Major database performance improvements for some searches (over 100x
>    faster)
>
> Some screenshots are available at the Developer's site.
> http://developers.gramps-project.org/tiki-browse_gallery.php?galleryId=1

I looked at the map view and wondered where the map comes from?
About all the people I have in my small Gramps database are from Finland,
so the whole world map wouldn't be so useful.

Would it be possible to:
- Use my own map
- For the map to have other aspect ratio than current world map
- Enter map extents as co-ordinates
?


        - Eero


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: map view

Martin Hawlisch
Hi!

> Von: Eero Tamminen <[hidden email]>
> I looked at the map view and wondered where the map comes from?
> About all the people I have in my small Gramps database are from Finland,
> so the whole world map wouldn't be so useful.
>
> Would it be possible to:
> - Use my own map
> - For the map to have other aspect ratio than current world map
> - Enter map extents as co-ordinates
> ?

You are right, the MapView is far from being usable. The current version is
simply a start to see what can be done without writing much code.

We wanted the MapView to not depend on any other package, didnt want to
require some hundreds MB of data to be downloaded, and the data required
needs to be freely available. So I started using the most simple way:
Scaling a NASA Image (http://visibleearth.nasa.gov/view_rec.php?id=2433).
Right, this is currently not usable when zooming in much, but optional
higher-resolution images could be provided as data-packs (I started on that,
but it is currently on hold).

For a geo-coded database of places I currently used the dataset provided by
xearth for debugging only. Other databases exist, for example we could use
the files provided by the GEOnet Names Server
(http://earth-info.nga.mil/gns/html/index.html).

An other idea is using vector-data instead of the NASA image, for example
the freely available VMAP0/VMAP1 data
(http://www.mapability.com/index1.html?http&&&www.mapability.com/info/vmap0_index.html).
But that requires a rendering engine in python. For example Geocanvas
(http://geocanvas.sourceforge.net/) could be used, but is far from being
finished. I simply didnt have the time to dig deeper into all this GIS
stuff.

An other idea was to embed mozilla into gramps and use Google Maps for that.
Should be easy to write a plugin that generates the XML-Data that is
required for that. That could then be used to add a Map to the web page
generatot too.

So you can be sure, the MapView in the current way will change, but dont
expect that to happen soon as we currently work on more important areas,
like functional data editing because many core parts of gramps have been
revamped in 2.1/2.1.

Any tips or pointers to free data and python integrated GIS-Packages are
welcome ;-)

Cheers,
  Martin.

P.S. Happy new year to all of you!



--
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: map view

bm-7
Hi,

I can only say, keep it simple, keep it functional.
For some python tools with GIS: http://freegis.org/database/?cat=21

For genealogy, I see only 2 uses for maps:
1/impress people with map graphics
2/do analysis/research.

The second I find useful. I'm thinking: I have a person born in
Steenvoorde and
one married in Veurne. This says little. On a map, one could notice these
places are close by, so there could be a link between the people. For this to
be functional, map should be combined with filters: show people born from
1800-1880, or people with common surname, ... Otherwise it would be one
big red
dot.

What is NOT needed in my opinion:
-/being able to search the street someone lives: just link to appropriate free
sites on the net
-/zoom in on a location. Why would you need that? Just provide predefined
scales.
-/have more detail than normal country map. It suffices to know
relatively where
the family lives, so you can see patterns.

For the implementation: in Europe http://www.viamichelin.com/ (search on eg
Berlin and set scale to City or Area) looks sufficient: you have a slider
indicating the scale (eg. world, continent, country, county/province/region),
arrows to move up/down/left/right.

Note that latitude and longitude are not always used, so the location editor
should perhaps allow for other formats? Even if mapview does not make it into
2.2 allowing users to input in the correct coordinates to use later is
important.
My government gives on their GIS site
(http://geo-vlaanderen.gisvlaanderen.be/geo-vlaanderen/straten/ or
http://geo-vlaanderen.gisvlaanderen.be/geo-vlaanderen/ikonos/)
locations in the
Lambert72 projection system (should you know dutch:
http://nl.wikipedia.org/wiki/Rijksdriehoeksco%C3%B6rdinaten , it's a bit like
the english UTM
http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system).

It would be hard for normal users to enter/know these coordinates and
that will
be very important to make the mapview possible. I've send my government a mail
asking for a list of coordinates of the communities (longitude/lattitude or
some other coordinate system) and if they have a free map. I'll let you know
what they answer (if they answer...).

Benny

Quoting Martin Hawlisch <[hidden email]>:

> Hi!
>
>> Von: Eero Tamminen <[hidden email]>
>> I looked at the map view and wondered where the map comes from?
>> About all the people I have in my small Gramps database are from Finland,
>> so the whole world map wouldn't be so useful.
>>
>> Would it be possible to:
>> - Use my own map
>> - For the map to have other aspect ratio than current world map
>> - Enter map extents as co-ordinates
>> ?
>
> You are right, the MapView is far from being usable. The current version is
> simply a start to see what can be done without writing much code.
>
> We wanted the MapView to not depend on any other package, didnt want to
> require some hundreds MB of data to be downloaded, and the data required
> needs to be freely available. So I started using the most simple way:
> Scaling a NASA Image (http://visibleearth.nasa.gov/view_rec.php?id=2433).
> Right, this is currently not usable when zooming in much, but optional
> higher-resolution images could be provided as data-packs (I started on that,
> but it is currently on hold).
>
> For a geo-coded database of places I currently used the dataset provided by
> xearth for debugging only. Other databases exist, for example we could use
> the files provided by the GEOnet Names Server
> (http://earth-info.nga.mil/gns/html/index.html).
>
> An other idea is using vector-data instead of the NASA image, for example
> the freely available VMAP0/VMAP1 data
> (http://www.mapability.com/index1.html?http&&&www.mapability.com/info/vmap0_index.html).
> But that requires a rendering engine in python. For example Geocanvas
> (http://geocanvas.sourceforge.net/) could be used, but is far from being
> finished. I simply didnt have the time to dig deeper into all this GIS
> stuff.
>
> An other idea was to embed mozilla into gramps and use Google Maps for that.
> Should be easy to write a plugin that generates the XML-Data that is
> required for that. That could then be used to add a Map to the web page
> generatot too.
>
> So you can be sure, the MapView in the current way will change, but dont
> expect that to happen soon as we currently work on more important areas,
> like functional data editing because many core parts of gramps have been
> revamped in 2.1/2.1.
>
> Any tips or pointers to free data and python integrated GIS-Packages are
> welcome ;-)
>
> Cheers,
>  Martin.
>
> P.S. Happy new year to all of you!
>
>
>
> --
> Telefonieren Sie schon oder sparen Sie noch?
> NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

Stian Jordet
In reply to this post by Don Allingham
fre, 30,.12.2005 kl. 16.12 -0700, skrev Don Allingham:
> We have been making some significant progress on the 2.1/2.2 branch of
> GRAMPS. While this version is a long way from being ready to release, it
> has become quite an exciting time for the project. Some of the new
> features that we have already implemented are:

I guess this is the right time for me to promote my number one wishlist.
As I wished for 2.0, I still wish for 2.2; to be able to embed the media
objects inside the database, to be able to have _everything_ in just one
(big) file.

This would of course be optional, and also have the possibility to save
the media objects as individual files as well.

Last time I seemed to be the only one wanting this feature, so I guess
I'm the only one now as well. But despite the fact that it probably
won't be implemented, I thought this was the right time to mention it
again.

Thanks for your faboulous work on Gramps!

Best regards,
Stian



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: A few thoughts on 2.2

Brian Matherly-2
I too support embedding the objects in the database. This brings up a point I've been meaning to ask for some time:
 
 What naming convention to people use for media objects?
 If it is a picture of a person, you can obviously just use their name. But what if you have two pictures of that person?
 If it is a family, what do you call it?
 If it is a document (a scan of a ship manifest, or census) what should it be named?
 How about obituaries (scans or transcriptions)?
 
 I have a particularly hard time with group pictures. Often a group picture has the names of the people written on the back of it relative to their position on the front. When I scan the picture to put it on my computer, I could just scan the back, but that is inconvenient. What do other people do in this situation.

 Perhaps Gramps could take control of media organization. It could do this one of two ways (or both):
 
 Storage outside the database:
 This would work just as it does now, however instead of simply storing a path to an object (which can change) it would make a copy of the specified object and would give it a name based on a naming convention. The user can fill in information about the media object - at least as much as is known - such as:
       Media type: Obituary, individual picture, group picture, census, birth certificate
       Date of creation
       location of creation
       Related surnames
       Whatever else applies.
 The name would become a combination of the information entered by the user and possibly the Gramps ID. All files would be stored in a common location for easy backup. Management of the objects would happen from within the Gramps interface.
 
 Storage inside the database:
 Warning, your database may become quite large. But who really cares. Storage is cheap.
 
 In my humble opinion, either of these approaches would be better than only storing a path to the media. I really want Gramps to be in charge of the management of my Media.
 
 ~Brian
 
----- Original Message ----
From: Stian Jordet <[hidden email]>
To: Don Allingham <[hidden email]>
Cc: [hidden email]
Sent: Sat 07 Jan 2006 01:15:42 PM CST
Subject: Re: [Gramps-devel] A few thoughts on 2.2

I guess this is the right time for me to promote my number one wishlist.
As I wished for 2.0, I still wish for 2.2; to be able to embed the media
objects inside the database, to be able to have _everything_ in just one
(big) file.

This would of course be optional, and also have the possibility to save
the media objects as individual files as well.

Last time I seemed to be the only one wanting this feature, so I guess
I'm the only one now as well. But despite the fact that it probably
won't be implemented, I thought this was the right time to mention it
again.

Thanks for your faboulous work on Gramps!

Best regards,
Stian






-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel