Menu
▾
▴
Re: [Gramps-devel] History and active signals for all primary objects
|
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
>
|