#0010556: Merging embedded events

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

#0010556: Merging embedded events

"Alois Pöttker"
Feature request #10556 fro me describe the advantages of event merging inside the person / family editor.
 
Working sequence: After selecting excactly two events the merging button gets sensitivity. Pressing the merge button the known event merge dialog pops up, the event will be choosen and with ok both events will be merged as usual.
 
Implementation: Different files of GUI - editor - displaytabs (mostly attacted to the eventembelist.py file) are extended. Only in the event tab is multi selection of rows enabled. Main call ist MergeEvent(self, dbstate, uistate, track, handle1, handle2), all merging will be done in the method. Afterwards model will be rebuild, the event list will be refreshed.
 
Reg. our new pull request policy therefore a request for approval.
 
KR
Alois

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: #0010556: Merging embedded events

paul womack
"Alois Pöttker" wrote:
> Feature request #10556 fro me describe the advantages of event merging inside the person / family editor.
> Working sequence: After selecting excactly two events the merging button gets sensitivity. Pressing the merge button the known event merge dialog pops up, the event will be choosen and with ok both events will be merged as usual.
> Implementation: Different files of GUI - editor - displaytabs (mostly attacted to the eventembelist.py file) are extended. Only in the event tab is multi selection of rows enabled. Main call ist MergeEvent(self, dbstate, uistate, track, handle1, handle2), all merging will be done in the method. Afterwards model will be rebuild, the event list will be refreshed.
> Reg. our new pull request policy therefore a request for approval.

I would (as a design principle) prefer to improve the event filtering in the Event view, rather than add Event merging
to the Person view.

If "current active person" were available as a filter in the Event view, merging a person's
events would (of course) be trivial.

And extended filters are of general utility.

  BugBear


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: #0010556: Merging embedded events

Doug-11
On 24/04/18 10:56, paul womack wrote:

> "Alois Pöttker" wrote:
>> Feature request #10556 fro me describe the advantages of
>> event merging inside the person / family editor.
>> Working sequence: After selecting excactly two events the
>> merging button gets sensitivity. Pressing the merge
>> button the known event merge dialog pops up, the event
>> will be choosen and with ok both events will be merged as
>> usual.
>> Implementation: Different files of GUI - editor -
>> displaytabs (mostly attacted to the eventembelist.py
>> file) are extended. Only in the event tab is multi
>> selection of rows enabled. Main call ist MergeEvent(self,
>> dbstate, uistate, track, handle1, handle2), all merging
>> will be done in the method. Afterwards model will be
>> rebuild, the event list will be refreshed.
>> Reg. our new pull request policy therefore a request for
>> approval.
>
> I would (as a design principle) prefer to improve the
> event filtering in the Event view, rather than add Event
> merging
> to the Person view.
>
> If "current active person" were available as a filter in
> the Event view, merging a person's
> events would (of course) be trivial.
>
> And extended filters are of general utility.
>
>  BugBear

A "current active person" filter would be really helpful for
multi-stage filters, where now needing to enter a Person ID
gets in the way.

And not only "current active person". Wherever filter rules
have the form "XXX with <Id>" it would be useful to have
filters for "current active xxxx", e.g. event, place, etc.

Doug

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: #0010556: Merging embedded events

Nick Hall
In reply to this post by paul womack
On 24/04/18 10:56, paul womack wrote:
> I would (as a design principle) prefer to improve the event filtering
> in the Event view

I agree.  We should avoid adding extra functionality to the editors.

Adding a checkbox in the event view to filter all events for the active
person would be a better solution.

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: #0010556: Merging embedded events

Helge.Herz-2
Hi all,
did you also think about the amount of mouse clicks to change the active
person if the event view is active? BTW: what's about double family
events in the event view?
OK, I see, there are circumstances to merge events using the event view.
In most cases (of course as I use Gramps) I see double events using the
person or the family editor.
So, for my opinion: To merge these doubles using the event view is
really "far away".

There was a discussion some days ago how to improve the team work for
Gramps (Gramps project governance). During this discussion came up by
Brian this priority list, I really like:
1) Design integrity
2) Application stability
3) Application usability
4) Web presence (Wiki, webpage, documentation, etc)
5) Translations
6) Releasing new features
7) Increasing community participation
My be I'm wrong, but it's really a "Design integrity" cause against
"Application usability" to avoid extra functions to the editors?

I would prefer and suggest an deep improvement of the editors to improve
usability:
+ user defined column order (including storage for the next session)
+ user defined column width (including storage for the next session)!!
+ and last but not least (if possible, I don't want to jump from one
window or view to an other window or view during research) user driven
merges for events of the same type or persons or citations or... (may
be, just by a selector column and an action button - see what FTM provides)

If you are still focussed on a solution for the event view (or as
addition to my own suggestion above) I would like suggest also a global
gramplet to define/change the active person like a selection in the
person view. I personally miss this function especially using the
relation view (I like to use it during research / add data).

Helge

Am 15.05.2018 um 20:19 schrieb Nick Hall:

> On 24/04/18 10:56, paul womack wrote:
>> I would (as a design principle) prefer to improve the event filtering
>> in the Event view
>
> I agree.  We should avoid adding extra functionality to the editors.
>
> Adding a checkbox in the event view to filter all events for the active
> person would be a better solution.
>
> Nick.
>
>
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: #0010556: Merging embedded events

Nick Hall
On 15/05/18 22:07, Helge Herz wrote:

> There was a discussion some days ago how to improve the team work for
> Gramps (Gramps project governance). During this discussion came up by
> Brian this priority list, I really like:
> 1) Design integrity
> 2) Application stability
> 3) Application usability
> 4) Web presence (Wiki, webpage, documentation, etc)
> 5) Translations
> 6) Releasing new features
> 7) Increasing community participation
> My be I'm wrong, but it's really a "Design integrity" cause against
> "Application usability" to avoid extra functions to the editors?

Correct.  The primary function of data editors is to edit data. Adding
extra functionality may be useful for some users but will confuse
others.  Read our UI style guide paying particular attention to the data
editor and Aunt Martha sections:

https://gramps-project.org/wiki/index.php?title=UI_style


>
> I would prefer and suggest an deep improvement of the editors to improve
> usability:
> + user defined column order (including storage for the next session)
> + user defined column width (including storage for the next session)!!

I have no objection to this.

> + and last but not least (if possible, I don't want to jump from one
> window or view to an other window or view during research) user driven
> merges for events of the same type or persons or citations or... (may
> be, just by a selector column and an action button - see what FTM provides)

This is where I have a problem.   The purpose of the person editor is
for editing person objects, not merging events.

The direction that I think we should go is to create a person viewer. 
This would show the relationships, events and other information about a
person in a rich format possibly incorporating data from many objects. 
The viewer could then have buttons to edit and merge events.  You can
think of the viewer as an extended and enhanced relationship view.

I also question whether it would be better to provide a de-duplication
tool rather than merging many separate events.


Regards,


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: #0010556: Merging embedded events

Stephen Adams
In reply to this post by Helge.Herz-2

I would also add "multi column sorting option" for example sort first by event type then by date, with the typical first arrow clicked is the priority.

On Tue, May 15, 2018 at 5:07 PM, Helge Herz <[hidden email]> wrote:
I would prefer and suggest an deep improvement of the editors to improve
usability:
+ user defined column order (including storage for the next session)
+ user defined column width (including storage for the next session)!!
+ and last but not least (if possible, I don't want to jump from one
window or view to an other window or view during research) user driven
merges for events of the same type or persons or citations or... (may
be, just by a selector column and an action button - see what FTM provides)
 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: #0010556: Merging embedded events

Stephen Adams
By this logic:

On Tue, May 15, 2018 at 6:09 PM, Nick Hall <[hidden email]> wrote:
This is where I have a problem.   The purpose of the person editor is for editing person objects, not merging events

You should not be able to edit or create events, or for that matter edit or create places...  Even though I'm on the person screen it's also quite readily apparent that I  may be manipulating events or other data.

Steve 


On Tue, May 15, 2018 at 8:12 PM, Stephen Adams <[hidden email]> wrote:

I would also add "multi column sorting option" for example sort first by event type then by date, with the typical first arrow clicked is the priority.

On Tue, May 15, 2018 at 5:07 PM, Helge Herz <[hidden email]> wrote:
I would prefer and suggest an deep improvement of the editors to improve
usability:
+ user defined column order (including storage for the next session)
+ user defined column width (including storage for the next session)!!
+ and last but not least (if possible, I don't want to jump from one
window or view to an other window or view during research) user driven
merges for events of the same type or persons or citations or... (may
be, just by a selector column and an action button - see what FTM provides)
 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: #0010556: Merging embedded events

enno
In reply to this post by Nick Hall
Op 16-05-18 om 00:09 schreef Nick Hall:
> This is where I have a problem.   The purpose of the person editor is
> for editing person objects, not merging events.
H'm. They can be added, edited, and removed from there. Why not merge?

> The direction that I think we should go is to create a person viewer. 
> This would show the relationships, events and other information about
> a person in a rich format possibly incorporating data from many
> objects.  The viewer could then have buttons to edit and merge
> events.  You can think of the viewer as an extended and enhanced
> relationship view.
Some time ago, we had a discussion about using a selected person as a
filter for the other views, so that they would only show families,
events, places, notes, sources, citations that are relevant for that
person. Would that work?

> I also question whether it would be better to provide a de-duplication
> tool rather than merging many separate events.
Oh, yes, I really like that. I have many duplicate events resulting from
merging persons, which were either existing duplicates, or came from a
GEDCOM with updates.

Regards,

Enno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: #0010556: Merging embedded events

Nick Hall
On 21/05/18 12:27, Enno Borgsteede wrote:
Op 16-05-18 om 00:09 schreef Nick Hall:
This is where I have a problem.   The purpose of the person editor is for editing person objects, not merging events.
H'm. They can be added, edited, and removed from there. Why not merge?

The direction that I think we should go is to create a person viewer.  This would show the relationships, events and other information about a person in a rich format possibly incorporating data from many objects.  The viewer could then have buttons to edit and merge events.  You can think of the viewer as an extended and enhanced relationship view.
Some time ago, we had a discussion about using a selected person as a filter for the other views, so that they would only show families, events, places, notes, sources, citations that are relevant for that person. Would that work?

Yes, but there is a better alternative.

Suppose you want to see all the events for a given person.  You could open the person editor for the person or filter the events in the event view, but these give limited information without opening more editors.

The idea of a viewer is to provide all the useful information in one place.

I demonstrated a prototype in the past, but now I propose extending the relationship view, possibly as a third-party addon to begin with.  More about this at a later date - we should be concentrating on getting 5.0 out now.  Just be aware that I am looking at the bigger picture when making design decisions.

Regards,


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel