Re: [Gramps-devel] personview changes

[Doug B. <dou...@gm...>]

On Sat, Nov 7, 2009 at 11:11 AM, Benny Malengier
<ben...@gm...> wrote:
> 2009/11/7 Nick Hall <nic...@ho...>:
>>
>>
>> Benny Malengier wrote:
>>>
>>> These changes are now in trunk. This is however not the final version.
>>> Commit 13515 does the following:
>>>
>>> Personview is now derives of the same classes as the other views, so a
>>> very nice code cleanup
>>> Personview now uses a generic treebasemodel, that in the future will
>>> be reused for other views.
>>> Personview now allows column sorting.
>>>
>>> There are some dramatic slowdowns as to the old code, as well as speed
>>> ups. What is slower:
>>> * showing person view is two times slower
>>> * selecting a person is very slow on large family trees
>>> Dramatically faster is however insert and delete which no longer
>>> depend on the size of the tree, so common actions that happen a lot
>>> during workflow.
>>>
>>> The following work will now be done:
>>>
>>> * fix column order dialog: group columns may not be reordered or
>>> removed, so the column dialog must be aware of this
>>>
>>
>> This will be fairly easy to do but we need to think about how it will work
>> if a view has more than one display mode.
>>
>> Does the view share the column order across all display modes or does each
>> display (model) have its own order?
>>
>> For flat models we display all columns as we do now.
>>
>> There are 2 options for tree models:
>>
>> 1. Display all the columns as we do for the flat model.  The view ignores
>> the hierarchical column and places it as the first column even if the user
>> has disabled it.
>>
>> 2. Remove the hierarchical column from the column selector.  The problem
>> here is that if we share the column order with the flat view where do we put
>> the hierarchical column back in for the flat view?
>>
>> For example, the flat view makes the hierarchical column the third column.
>>  Then the user re-orders the columns for the hierarchical display.  Then the
>> user goes back to the flat view.  Does this cause a problem?  Do we need to
>> store a column order for each display rather than each view.
>

Go gramps team!

> I would remove it from database and have columns in the ini file
> connected to a specific view.  Let's see the others agree.

+1. We should separate display data from the genealogical data. It
should make the genealogy data more safe, and not have to be upgraded
if we separate. There is an additional question about whether it
should be stored in *a* database (separate from the core data) or just
in the ini file. The column ordering doesn't change much, and there
won't be too many, so I think the ini file is fine.

I hope that we can address the views reorg sooner than later. There
are some parts of gramplets/tools that I think can be fixed with this.
Maybe we can have a 3.3 plan in place to come out 6 months after 3.2?

-Doug

>>> * increase speed, I intend to try linked lists instead of the index to
>>> path and path to index maps we used to have. It should be cleaner and
>>> a lot faster. If this works out, also the flatbasemodel will use it,
>>> so as to have one way of coding.
>>>
>>
>> Let me know if you need any help.
>
> yes
>
>>> * increase speed of filter/search on a build tree by keeping the full
>>> tree in memory.
>>>
>>
>> This needs to be done after we decide which approach is best.
>>
> ok
>
>>> * make views plugins, so we can have both tree personview and flat
>>> personview.
>>
>> I assume that you are working on this yourself.
>>
>
> I will do this first
>
>>> My idea now is to have one person selection in the
>>> sidebar, and then on the toolbar reserve a section to switch views of
>>> the same category.
>>>
>>
>> As you know I have started to do some work on the design of a new sidebar in
>> the bug tracker - 0001644: need to brainstorm alternatives to the current
>> sidebar/navbar
>>
>> http://www.gramps-project.org/bugs/view.php?id=1644
>>
>> I had another idea to put a small button bar in the "views" navigation mode
>> of the navigation bar.  Have a look at the "File Browser" sidebar of gedit
>> to see what I mean.  I think that this as closer to your original intentions
>> but will still be flexible for the future.
>>
>> I'll post a summary of my thoughts so far in the original thread.
>
> Ok, as it is november, I think there is too little time to now change
> to dramatically for 3.2, so let's push a real rewrite to 3.3
> In the meantime, I would go for a minimal change:
> 1/ the sidebar shows predefined categories
> 2/different views for the same category show as buttons in the
> toolbar, clicking it removes the previous view and shows the new one.
>
> I think above is least intrusive and allows us to have all fully
> tested before 3.2. Should you have really a lot of time, you can
> already design more extensive changes, but I'm afraid actually doing
> it would not fit in the timeframe of a 3.2 release.


> Benny
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Gramps-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>