On 01/12/2011 11:35 PM, Joost 't Hart wrote: Hi!
>> So the >> program behaves correct. > > Well, my initial impression was different, because I could not find any > way to load another game; > until I realized that closing the tree window might help. This is a problem where I currently can't see a really good solution. With the filter patch enabled we get a (IMHO) very useful function, e.g. it is possible to restrict the games list to those games in a given position with a given player. However, at the moment you actually need to know what you did for you to know which filters are enabled so you can understand what is displayed. E.g. you do a header search for all games by Kasparov. The games window shows all games by him. All right. same behaviour as in all version of Scid. You clean the the header search, al games are back. In the backend you have the db filter working for this. Now the same with some position on board and the tree opened. This gets the tree filter working. If you look up the games list you get all games that match the current position. Sensible as well. Once you close the tree window all games are back as the tree filter is cleaned. Finally, you open the tree window, go to some position, and initiate a header search. Now you'll get the logical AND of the header search and the tree search in your games list. Very sensible as well. You can clean either filter by closing the tree window or cleaning the filter by the button respectively. (The first question that arises here is if "clean filter" should also clean the tree filter. I think "no".) This is again all very logical. However, things get a bit "messy" if you have more than one base opened and freeze the tree of some base at a given position and initiate different header searches for different bases. Say you analyse an opening and want to see Kasparovs games from a OTB database and compare it with some games of Ulrich Stefan in your CC database. So you've two header searches, one against your OTB database for Kasparov, one for your CC database for Stefan, and just in case if you happen to analyse one of your own ongoing CC games even a third one initiated hidden to you entirely by Scids CC functions. Given, that header searches can be quite complex and even ran in sequence using booleans you might end up with a very complex query where you actually don't even know what you asked for, unless you keep a sheet of paper and a pencil handy and jot it down. An especially difficult case is probably, that the tree statistics is calculated for the full base while the best games window applies the db filter, so if you count up the games in the tree you get more than you see in the best games. Nothing wrong with any of this, but it is hard to grasp, indeed, and we should think of a way to tell the user more precisely what he currently sees. (I admit, that if I wake up my notebook from hiberantion in the evening to track recent changes in my CC games it might very well happen that I don't know what filters I initiated yesterday, so I actually close down quite a bit and reopen it to come to a "known state" again.) >> Currently the tree filter is still active, if the tree window is disabled. > > What do you mean by "disabled"? I think "close the tree window". >> It is just not updated. > > The main thing that puzzles me is what can cause the tree filter to > result in "no games" (in tree window and game list). I feel that this > should never happen, unless I am in a position that has not been added > to the base yet. > > I mean, if the filter is not changed by the start position change than > the original game should still be there (although it does not contain > the position on the board). If the filter _is_ changed by that action, > than the current game should be in the list, as it does contain the > position on the board. > > Maybe the filter _result_ should be updated as soon as I save the game > to the base? Or is that tricky to implement? I can check this. There's also another update missing for the best games as I noticed recently. (Ie. it gets no update if you initiate a header search unless the tree changes.) >> It may be a better idea it close the filter and >> recreate it when the window is enabled again. So you do not need to close >> it. >> The second interesting possibility is to decouple the filter of the game >> list and the existence of the tree window. I am not really sure that this is the solution, as this introduces yet another result list. >> A switch at the bottom of the >> list window could enable/disable the filtering of its games independent >> whether a statistic window is open. Then you could disable the filter there. > > Yes, maybe. But the user needs a full grasp of the filter cascading > mechanism in order to understand that the alternative "Search/Reset > filter" operation does not help (as this clears only the filter that he > explicitly set himself - and I did not do this). Agree. I could actually introduce a "clean tree filter" button, actually easily, but is it really clear that the tree is effectively a filter? It's sort of hidden. Plus, what would then be the meaning of the trees display, if I just drop the tree filter? cu Alexander ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
