On Sat, Jan 31, 2009 at 3:00 AM, Benny Malengier <benny.malengier@gmail.com> wrote:

2009/1/31 Doug Blank <doug.blank@gmail.com>

Ok, great information in this thread! Thanks all.

So, it sounds like we can summarize this as follows:

1) The "Relationship Calculator" Tool gives the same information as the status line. It is quick, and doesn't show in-law relationships.

2) The Quick View "Relation to Home Person" finds the closest common relative between two people, does take into account some in-laws, and is still very quick.

3) The Family Lines show some of these connections, but not all.

4) The Disconnected Person Filter will show you only people that aren't connected to anyone else... it doesn't show people that aren't connected to an arbitrary person

So, it turns out that I wasn't really interested in the relationship between two people, I was more interested in how/if they were connected. I also didn't mind if GRAMPS wanted to chug through the data for awhile, as it would save me time from doing it by hand. So, it sounds like a new use. I'm not convinced that we need yet another variation, but I've added an experimental, slow, thorough gramplet called, for the moment, Deep Connections. You can see a picture here:


Perhaps this should be a 3rd-party plugin? Let me know if you find this useful, and different enough to include in GRAMPS.

I have two remarks

1/ not everything should be a gramplet now. I guess you did this because  of the threading possibilities. This form factor looks more suited to me as a tool with a start, pauze and continue button.

2/this can use up a lot CPU cycles. We must be very carefull that normal users do not think GRAMPS is bad because it is slow/unresponsive, while the reason behind it is that they loaded to many intensive gramplets. As we allow all the gramplets, the user will think it should not matter he puts 15 of them on his 1Ghz laptop.
It short, _we_ have to make sure GRAMPS works good also if the user does dumb things.

In light of the above I would do the following recommendation:
1/if this is a gramplet, then or a 3th party plugin. That would be a pity though, as many people would benefit from this functionality or an official  GRAMPLET that does not respond to user changes but has a start button to start it searching. Then it would be ok in GRAMPS officially, as the user understands why things suddenly slow down. Perhaps it is like that the pause changing in start, as there is no code  I can't know. (nomally there is one button, start, after click it becomes pause, after click it becomes continue, on change of active/home person it becomes start again)
2/as a tool, it can go into GRAMPS. A user specifically calls a tool, so he does not mind slower functioning (if he can interrupt)
3/We should define  some 'best practices' around the gramplets:
* there are too many gramplets, we must help the user find the one he needs. So the add a gramplet should perhaps be subdivided in categories: the most usefull are shown, then at the bottom submenu for the other gramplets: menu for 3th party installed ones (important to get feedback on upgrade of gramps base!!), menu for advanced ones (session, python), ...
* should we not limit how many gramplets can be added?
* clearly one can now create quickly good looking gramplets with a unified structure to do things we used to do with the tools. It is a pity if this means all is now written as a Gramplet instead of a Tool. Perhaps a general tool can be made that essentially runs a gramplet in it's window (but is called from the tools menu). Is this possible? It would be a new way of writing a tool. Obviously, such a tool should not be available also as a Gramplet.


I agree with everything you say. Here is a short term solution for 3.1:

1) Add a path to a gramplet's name: "Python Gramplet" becomes "System/Python Gramplet" (or something) which gets turned into a series of pulldown menus:

   Python Gramplet
Data Entry

We can see how a particular set of groupings work and adjust. I prefer functional categories, with alphabetical inside those.

2) Write a tool frame for holding a gramplet. That should be trivial. I agree, it should be a gramplet OR a tool, not both.

As to the number of Gramplets, I'm reminded of plugins for projects like Wordpress. There must be hundreds, and even plugins that manage plugins. I agree that the "paradox of choice" can leave users overwhelmed. But I see a vast future of functionality that we are just now beginning to tap...

Thanks for the feedback!









This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
Gramps-devel mailing list