2008/12/15 Douglas S. Blank <dblank@cs.brynmawr.edu>
> 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.

Ok, sounds fine to me. I was just asking to see if there were any related
changes that one wanted to make since I'm going to be in there anyway.

> Anyway, the active person does not change by moving to a different person

Unless I misunderstand you, I don't think this is correct. If I move the
selected row in the People View, then the active person does change. For
example, in the Python Gramplet if I enter:


then move the People View selected row, and look at the active person
again, it is different. Of course, that is what emits the change-active
signal that triggers the refreshing of related views.

Indeed, but the active person can also change from an external place. The active person also changes in the pedigree view, ... . This is all specific for a person though and is probably the reason the signal was added and the code is there in dbstate. Before gramplets, this was not needed for the other views
If you envision a use for two person views, or two family views, then the signal must be view identified somehow, with different signal emitted for the second view. I leave it to you if you think that is useful.

If no one has objections, I think I'll just add change-active-* signals
for all of the views so that they can send and receive them so that
Gramplets can be synched with them.

Yes, that looks like the thing to do. If all pageviews have them, then add code to the PageView.ListView class, I find it easier if equal code is in a shared top class. As PersonView is quite different from the others programatically (that would be a nice code rewrite, to have all listviews inherit again from the same base class as much a possible) you might need to do it only for the not person view like that.
A quick glance at the code makes me think the code in the person views for this can also be moved to PageView.PersonNavView.

The way I would like to see this evolve (It is not like this now, NavView is only used for Person Views)

PageView  : the base for views
        ---> GrampletView.    Why is this now inheriting from PersonNavView????
        ---> HTMLView  --> GeoView
  --->  BookMarkView : the functionlity to offer a bookmark menu
          --->  NavView : a new class giving all the functionality to offer a history in the view
                 ---> PedigreeView
                 ---> RelationshipView
                 ---> ListView : the base class for all the views showing a treeview listing of the objects
                       --> all the normal dataviews
                       --> PersonView: the special one for performance reasons :-)

In the above schemew, the addition of the 'active-changed' signal is part of NavView in my opinion. Which would be then easy to add.
To improve the above, it might be nice to change PersonView in such a way that it inherits from an 'ExtendedListView' that has the specifics for the ordering of data along parent nodes (the family names in person view, but in a place view this could then be eg Country ! ), or even better, give ListView two modes one can switch between: flat list and organized list (are you not the guy who also wanted to be able to sort on the person view ;-) )

Anyway, when adding the signal if you could keep above scheme in your minds eye, I would be very gratefull.



> (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, ...).
> Benny
>> -Doug