2008/12/14 Douglas S. Blank <firstname.lastname@example.org>
I've committed a new Gramplet that will automatically re-run the selected
Quick View when the active person changes. This can make Quick Views a
nice part of a customized view as you can detach them from the gramplets
page and have them always reflecting the currently selected person when
you are on another view.
To complete this, I added the ability for Gramplets to have interactive
options (rather than having to edit the gramplets.ini file). Only a couple
of Gramplets have I added such options (Pedigree and Quick View) but will
add the others as time goes on.
Thanks to Benny for the nicely designed Quick Views, and Brian for the
nicely designed Options. I was able to reuse both and they made coding
this pretty quick. A good example of being able to re-use via nice
Note: if you run the Quick View Gramplet, you'll notice that only the
People Quick Views will run. The problem is that only the People view has
a signal that gets emitted when the People view changes. Do we want to be
1) know when we change selection on the other views?
The long open TODO of adding backward and forward arrows to all views would need this, so if added, it should work like Person View so that adding these buttons (see the history on Person view in which you move). So a change is registered to the history of the view to enable backward/forward move
2) be able to select a row in other views programatically?
This should be possible now I believe as the views have Bookmarks, and a bookmarkview allows to jump to the selected bookmark
3) be able to get the handle of the currently select item?
I suppose this is possible now, perhaps just not as an easy convenience function. Not sure why you need it. Note that multiple select is possible on many views, so this must be handled logically equal on all views.
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....
Feedback welcomed on all of the above.
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
Gramps-devel mailing list