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