2010/3/25 Alain Aupeix <firstname.lastname@example.org>
Benny Malengier a écrit :
>ok, I see now the change, but a little thing is ennoying.
> Jerome, if you read what I said, you can see that the error isn't here
> now with trunk 14924, but there is a new problem, we can't now in the
> same condition 'family > member > modify a family event', it does
> nothing, even for example with right-click on a family event we
> have the
> Modify possibility...
> That was why I said the problem had been evacuated...
> No, it is actually fixed.
> Clicking a family event cannot open the family event, so it opens the
> family editor. In your case, the family editor is already open, so it
> changes focus to the family editor (see the window outline changing).
In my case, the person window was covering exactly the family window, so
I didn't seen that the focus was given to family window.
Wouldn't it be possible the same time you give the focus to family
window, to set family window on top ?
This is what I say in the rest of the mail. At the moment the person editors spawned from the family editor are defined as children of the family editor. So they are always above it, and when you close the family editor, the person editors close with it.
So we would need to change this behavior. Somebody should try if that workflow works ok or not, we cannot just change it now without a bit of usability test.
So, try it Alain, in editfamily.py go to line 884 and change
and write back with what you think of that.
That will give you the behavior you want. You should do the same in the other EditPerson calls in this file (eg on child edit in the child list).