From: Benny M. <ben...@gm...> - 2010-01-11 20:14:35
|
2010/1/11 Gerald Britton <ger...@gm...>: > +1 > > I've always been bugged that the person object is just Person, family > just Family etc. but a media object is a MediaObject. Of course it's > an object! It's redundant to say so (kinda like saying the NTFS is > "NT" technology -- something I've actually heard in seminars. > Actually, that's worse than MediaObject.) > > Aesthically, I would rather that the objects had similar name lengths. > Today we have: > > Person > Family > Event > Place > Source > Note > > but: > > MediaObject > Repository > > If the last two were just: > > Media > Repos Not sure about Repo, but feel free to do perl -pi -w -e "s/L{MediaObject}/Media/g;" *.py Which in one line should changes all those Repository I would leave or change to Repo, but as Repository is also an english string, the a check of all changes would be needed, as strings should not change Benny > > you could make some code prettier where you put these things in a list > of tuples (happens a lot). > > > > On Mon, Jan 11, 2010 at 12:42 PM, Nick Hall <nic...@ho...> wrote: >> Doug, >> >> Comments below. >> >> Doug Blank wrote: >>> On Sun, Jan 10, 2010 at 2:50 PM, Nick Hall <nic...@ho... >>> <mailto:nic...@ho...>> wrote: >>> >>> Commit 14023 implements this change. >>> >>> The active status is now moved from DbState and into instances of the >>> History class. These instances are kept track of in the DisplayStatus >>> (commonly the uistate variable). >>> >>> The History objects hold a list of handles of the objects that >>> have been >>> visited and are in the history. They also emit an 'active-changed' >>> signal when their contents changes. >>> >>> A new History object is created for each type of object handle that is >>> stored. The object type for history is referred to as the navigation >>> type. The 8 types are: 'Person', 'Family', 'Event', 'Place', >>> 'Repository', 'Source', 'Media' and 'Note'. >>> >>> All plugins (view, gramplets etc..) that are linked together and >>> respond >>> to the same signals share the same History object. To enable plugins >>> with the same navigation type to be unlinked I have created the >>> concept >>> of a navigation group. Plugins sharing the same navigation type and >>> group share the same History object, so there will be a separate >>> History >>> object for every unique navigation type/group combination. Navigation >>> groups are assigned in the constructors of views and gramplets. >>> Navigation groups are integers and the default is group 0. >>> >>> At the moment all views and gramplets belong to group 0, so they >>> are all >>> linked for a given navigation type. >>> >>> There are a few things I need to look at but the everything that I >>> have >>> committed should work. Let me know if there are any problems. >>> >>> I need to look at the following: >>> >>> 1. Changing the navigation types to lower case. >>> 2. Investigate why the active person is accessed in grampscli.py >>> 3. Look at removing RecentDocs in DisplayState.py >>> >>> I also noticed 2 existing bugs that I will investigate: >>> >>> 1. When the selection changes a previous row can remain >>> highlighted but >>> not selected. >>> 2. The new place tree view does not expand properly when the selection >>> changes. >>> >>> Regards, >>> >>> Nick. >>> >>> >>> Nick, >>> >>> This looks very good, and cleans this up the code very nicely. One >>> related point that would be nice to deal with at this point (and >>> related to the signal names) is that it might be handy to have >>> something like: >>> >>> def get_active_object(self, nav_type): >>> """ >>> Return the object of the active handle for the given >>> navigation type. >>> """ >>> handle = self.uistate.get_active(nav_type, self.nav_group) >>> if handle: >>> return getattr(self.dbstate.db, "get_%s_from_handle" % >>> nav_type.lower())(handle) >>> >> >> Yes, I thought about doing this but decided to just provide functions to >> set and get the object handles. It takes only one line to get a handle >> from an object or an object from a handle. When changing some of the >> code it would have been slightly easier with this function though. >> >> I have no objection to this being added. >> >>> Now, this is a little ugly, but it would be nice to have a generic way >>> of mapping those nav_types that are primary objects to be able to just >>> get the object. There may be nav_types that aren't primary objects >>> (nor perhaps any kind of object) in the future. >> >> I considered making the nav_types classes instead of strings or numeric >> constants. The advantage of strings is that no imports are needed and >> the function calls are very readable. >> >> I looked in the config file to see what you meant by the lower case - >> this just confused things even further. The view categories have the >> first character uppercase. The keys are lower case but they use "repo" >> for "Repository". I was thing of just a string representation of the class: >> >> print gen.lib.Person.__name__ >> >> I got it wrong with "Media" which should have been "MediaObject" if I >> used that approach. >> >> The get_<object>_from_handle functions would use "object" as the >> <object> for "Media". >> >> Things are not consistent, it would be good to tidy this up. >> >> I don't like the term object for media. It would be useful to a >> function in gen.db to get a general object: >> >> get_from_handle('Person', handle) >> >>> >>> Perhaps these kinds of functions should be in a base class that >>> gramplets derive from? >> >> If we decide to do this then we should make it available in DisplayState. >> >>> >>> On a related note, if these objects knew how to display themselves, >>> this Gramplet would be done: >>> >>> def main(self): # return false finishes >>> for name in ["Person", "Family", "Place"]: >>> active_obj = self.get_active_object(name) >>> self.append_text(_("Active %s: %s") % (name, str(active_obj))) >>> self.append_text("\n") >>> >> >> I created a function in Utils to do this: >> >> Utils.navigation_label(db, nav_type, handle) >> >> It is used for the text in the status bar and for bookmarks at the moment. >> >>> I see that we have code sprinkled throughout Gramps that maps "Person" >>> (for example) to the related method calls. It would be nice to have a >>> definitive place where that happened (perhaps in the database?). That >>> would be another place to standardize a string-name for objects (and >>> maybe list them all). >> >> Yes, I like the idea of standardising this in the database. >> >> Regards, >> >> >> Nick. >> >>> >>> $.02 >>> >>> -Doug >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution >>> fast and easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> <mailto:Gra...@li...> >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > > -- > Gerald Britton > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |