Hello,
Having multiple Scid running does not solve the issues. Pain point is the reset
of the filter after each move on the board and how to limit statistics.
I think that there is no real redesign necessary and it also should not
generate that many bugs.
The algorithms needed are all implemented and tested. The UIs are implemented
and tested.
What are the real changes:
1. List window
a) Today the filter of a database is reset after each move. Instead keep
the filter in future unchanged. This means filtering by the current board
position is a search option independent from the filter definition.
b) Today the games in the game list window are filtered by the current
position, if a tree window is open. Instead allow the user an explicit decision
by adding a checkbox at the bottom of the list window to enable or disable this
filtering. If 1a) is implemented then there is the workaround just to open and
discard a tree window for this database, but a dedicated check box improves
usability.
2. Tree window
a) Today the statistics are filtered only by the board position. Now allow
to define an additional header filter for it. Then the games going into the
statistics are filtered by both filters.
Both parts do not depend on each other. So it is also possible to implement
only one of them.
Gerd
Von: Steven [mailto:stevena...@yahoo.com]
Gesendet: Dienstag, 7. September 2010 16:30
An: scid-users@lists.sourceforge.net; Fulvio
Betreff: Re: [Scid-users] Some thoughts about filters
Instead of having multiple windows, and multiple filters... etc, involving much
redesign,
coding and bug-fixing, why not simply implement a database locking mechanism
and open multiple instances of Scid.
The mechanism will simply test if a database is already open read-write, and
accordingly open it read-only. In this way games can be copied between DBs,
independant filters are easily achieved, and all with hardly any new code.
The only other issue AFAICS is the handling of the options file that get saved
when
Scid closes... How to do this best i'm not sure, but this issue seems less
critical
than the alternatives.
As other people have commented, Scid is (perhaps) becoming less stable, and
feature creep is obviously the most likey reason.
Steven
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
