2008/12/15 Douglas S. Blank <dblank@cs.brynmawr.edu>
>> If we do want this functionality, then other tables will be able to have
>> some of the same functionality as the People view. (Some thought may
>> want
>> to be made as to store this functionality in the view rather than the
>> DbManager, but it isn't clear to me how we could do that).
> I am lost in this remark and have no time to check the code about what you
> mean. If DbManager stores things about the people view, that would be most
> strange. I would expect it to manage the family trees and at most be able
> to
> know what the default person of a family tree is....
> Benny

Oops, I meant DbState. Because the active person is handled in the
DbState, one can't have multiple People Views that are independent of one
another. Of course, if they are independent of one another, then they
don't behave the same way. I'm just thinking out loud, wondering if we
should rearrange the organization a little.

Slippery slope ahead :-)
I don't mind something different, but would want a serious use-case or problem before we embark on such a thing. The fact that there is only one active object is a central thing at the moment. I see no way on how to have two different active objects and still have an interface that is logic and consistent.
Anyway, the active person does not change by moving to a different person (you can activate it by click in context menu on person editor eg go to family editor then edit one of the children, set active by context cmenu lick), having a second personview centered on a person not the active person would only mean having code in personview to track the active person or not, each with it's own history, and only one of the two setting the active person, as needed in other parts of GRAMPS (plugins, quickview, ...).