Re: [Gramps-devel] Merging DisplayModel and Models

[Don A. <don...@co...>]

Richard,

I like the idea of moving the rendering to the View instead of the
Model. The current scheme was originally done to make the move from 1.0
to 2.0 easier, since it followed the TreeModel implementation used in
1.0 (before we used our own custom GenericTreeModel). To be honest, the
idea of moving the rendering into the TreeView never occurred to me :-)

I think proceeding with this would be a good idea, but lets hold off
checking it in until after 2.2.5. This big of a change needs more than a
week or so for verification.

While originally we were looking at 2.2.5 this weekend, it looks like it
will probably hold off until next weekend. I want to give the current
round of optimizations a bit of time to be tested and I want to knock
off a few more bugs.

Don

On Thu, 2007-01-18 at 10:37 +0000, Richard Taylor wrote:
> Don
>=20
> I think that it is time that we merged the two model implementations.=20
>=20
> I have been looking through the DisplayModels and seeing what should be d=
one.=20
>=20
> I'll start with a view of the main differences between the approaches.
>=20
> 1. yours builds an index list when the Model is initialized in rebuild_da=
ta.=20
> Whereas mine does not build an index but keeps a database cursor open to =
act=20
> as the index. The advantage of my approach is that it never has to iterat=
e=20
> through the whole index, the disavantage is that it will only work in a m=
odal=20
> dialog because the database backend can't deal with keeping the cursor op=
en.=20
> The advantage of your approach is that it works in non-modal dialogs and =
it=20
> allows for ordering of the index other than the database order. The order=
ing=20
> is important for non default locals.
>=20
> 2. both models use a similar object cache mechanism.
>=20
> 3. both models have just about reached the limit of optimisation for iter=
/path=20
> mappings.
>=20
> 4. your model encodes the columns into the model, my model only has one c=
olumn=20
> that contains the primary object. In your model the column rendering is d=
one=20
> using methods in the model whereas in mine the column rendering methods a=
re=20
> in the View. I am not sure what the advantage of your approach is but the=
=20
> advantage of my approach is that you can have different View classes that=
 use=20
> the same model but display different columns. Future enhancements like co=
lumn=20
> reordering, user selectable columns etc. are easier to deal with if the=20
> column rendering is in the view.
>=20
> 5. because your model has a complete copy of the index it can support bot=
h=20
> filtered and non-filtered modes. My model requires and different=20
> implementation for the filtered mode.
>=20
> So to summarize: your model is better because it allows locale based sort=
ing,=20
> filtering and non-model dialogs. My model is better because it separates =
the=20
> job of rendering columns into the View (and it is a bit quicker).
>=20
> So I propose that we refactor your implementation to remove the column=20
> rendering and put it in the views. This would mean that we can junk the s=
tuff=20
> in Models/ and I can use your model in the ObjectSelector. (an example of=
 the=20
> column rendering code can be found in: TreeViews/_PersonTreeView.py)
>=20
> What are your views on this?
>=20
> Regards
>=20
> Richard
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Gramps-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel