Hello Pascal,
I am sorry but I cannot follow you. The use case I described is basic to
annotate a game or keep own opening analysis up to date. It is also very
natural to store the own analysis not in a growing reference database with
more than 1.000.000 games, but in a separate private small database. If I
have to copy my analysis all the time to the reference database whenever I
want to update it and afterwards back and then delete it in there
,
something went wrong!
You are right the game list is a function local to a base. But if the
database is in tree mode, the position in the game on the board is just a
filter for these gamelist. It does not matter to which database this game
belongs. Also merging a game from the list into the game shown on the board
does not require any additional (visible) UI functionality. It is just:
merge this game [into the game on the board].
A note related to the other point. I found how to save a windows layout, but
it ignores detached windows.
Gerd
Von: Pascal Georges [mailto:[email protected]]
Gesendet: Montag, 16. März 2009 22:15
An: Alexander Wagner
Cc: [email protected]
Betreff: Re: [Scid-users] Scid usability issues
2009/3/16 Alexander Wagner <[email protected]>
Pascal Georges wrote:
Hi!
Anyway, the behaviour of Scid was changed here only
recently. Actually, the intention was to be more logical.
The original behaviour was as you describe as your wish. But
indeed your're right, it broke merging games from the list
of games indeed, this menu point does not make sense
anymore.
I don't follow you : could you explain ?
I remember some discussion of this point in the past and you
changed Scids code to show the first game of the filter if
one switches databases. In the past, Scid stayed on the very
game one was at regardless of DB switching. This is what
changed.
When a search is performed, the first game in the filter is loaded (quite
logical). That's all. This has nothing to do with the discussion about the
board reflecting selected base.
Now:
- Open a base A, go to some game Z at some position there.
- Open a base B, say as tree. The filter will set for the
very position as in base A, however, right now you're
still in game Z.
- Switch to base B.
Now, your are at the first game of the filter for base B,
this is actually game Y, and indeed at the position you
were looking at in base A.
But you're in a different game. You're now in game Y.
That is the important point here.
- Open the games list.
- Right click on the first game in the list, choose "Merge
game". This will now try to merge game Y with game Y!
Of course. The merge function in game list merges the game you click on to
the loaded game. You should have clicked on game Y2. Those functions are
unrelated (Tree and Game list).
=> It does not work, you can not merge a game with
itself, even if you can, it just doesn't make sense.
Indeed.
Even if you open the context menu of the second game in
the list and call merge the same way, it will be merged
into game Y, that is the merged game would live in base B.
Your merged lines will not live in Z in base A as your
intention was.
Game list is a function local to a base. It does not work between two bases.
For that games have to be copied from one base to another. Note that merging
games between two bases is not hard technically, but a simple UI to do that
is missing. To copy games to the target base may be less error prone
(clipbase is there for that).
The more I think about Gerds comment the more I feel he's
right: switching bases should probably not change the games.
I think it would be an horrible mess. Maybe some entries are missing like
"merge this game to current game in base <X>". Nothing more.
Pascal
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
