Hello,
your note that filters are more or less queries is right. In the product they
are called everywhere filters, so I prefer to keep it.
treeFilter and dbFilter are already independent, so there is no need for
changes.
If the user wants to filter by position and header search he performs a third
query, which is the conjunction of the previous one. In the backend its name is
"filter" and it is used by other functions, so I would not change it.
UpdateMainFilter is an optimized way to calculate filter out of treeFilter and
dbFilter. There may be other ways doing this, but I would like to look at this
when everything else is implemented. There may be a direct update between
dbFilter, treeFilter and filter.
treeFilter needs to be recalculated whenever the position on the board changes.
It has a check that it does not calculate the same position twice.
sc_tree_search is maybe slow but it is very fast for what it does and there is
no alternative.
Until now there were only one comment from Joost to my picture in one of the
mails before. the statisticsFitler does not yet exist and I can live with my
personal solution having a hardcoded 2300 limit for large bases. If we agree to
go this way so that the full picture will be implemented, I am willing to help.
A statisticsFilter could be something like
MINIMAL_ELO_FOR_EACH_PLAYER && MINIMAL_ELO_AVERAGE_FOR_BOTH_PLAYER
This could be saved as a database dependend property and loaded and evaluated
at Scid startup or open of this base.
Gerd
----- Ursprüngliche Nachricht -----
Von: Fulvio
Gesendet: 25.01.11 10:45 Uhr
An: Gerd Lorscheid
Betreff: Re: [Scid-users] Best Games List/Games list + Filter interaction was:
Potential data loss using trees
Gerd Lorscheid wrote:
> Hello,
>
> What I have implemented is the following:
> I have added a checkbox, which controls whether the games in the list are
> filtered by the actual position.
Ok, the user interface is perfect in my opinion.
Can we try to discuss how to do that, maybe starting with making a
common c++ backend.?
First of all i want to delete the function:
updateMainFilter( scidBaseT * dbase)
(BTW, Filter::Merge is a misleading name.
When i encountered:
"dbase->filter->Merge (dbase->treeFilter, dbase->dbFilter);"
i expected dbase->filter to become itself more dbase->treeFilter more
dbase->dbFilter.
Is "dbase->filter = dbase->treeFilter & dbase->dbFilter;" clearer, isn't
it? )
Let's try to use the common database->query->view terminology.
- One file.si4 is a database
- dbFilter is a query in that database
- treeFilter is a different query in that database
- The "Game List" window is the view of the dbFilter query
- The "Tree" window is the view of the treeFilter query
Obviously each query needs to be completely separated and independent.
This is a basic stuff, so i suppose there is no need to argue.
IMHO, what we need to do:
1) The sc_tree functions should change only the dbase->treeFilter
2) The sc_search functions should change only the dbase->dbFilter
3) When the "Game List" window wants a query of dbFilter & "the current
board position" we deal with that (your approach of calling
sc_tree_search is the cleanest, but is the slowest too)
Do we agree on this?
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
