>>> BTW: your addition of best games to the database
>>> switcher. I'm not sure that this is sensible all the
>>> time. I admit that I use the switcher just for what its
>>> name says: switching databases. For this reason I'd like
>>> to have a _small_ window. Usually it's 2x2 bases not
>>> larger.
>>
>> Please notice that the games list in "db switcher" window
>> is different from the one into "best games" window.
>
> Yes. Still, what I want to point out is that it is probably
> not the perfect place at least if it has to be there and is
> not optional.
>
> This placement goes a bit in the direction of, I think,
> Gerds suggestion to move db switching functionality to the
> games list. Though I am not sure myself that it belongs
> there either (I prefer dedicated windows instead of
> "everything crowded in one place" kind of GUI) at least I'd
> find it very helpful that the db switcher can be kept a
> small window. The Games List by definition is a at least
> "wide" window due to the ammount of data to show there by
> default.
>
> Thus, if the feedback is to unify games list and db
> switcher, I'd vote for having db switching in the games list
> as an option and keep db switcher small.
>
>> The idea that i wanted to show is a sort of "database"
>> window where typical operations (load/copy/search games)
>> can be perfomed all in one place. I think that the ideas
>> and opinion of scid users can be very useful to find the
>> optimal solution.
>
> Thats why I placed my vote ;)
There is also another small but important difference between the two
options. In Fulvio's implementation changing the database in the switcher
changes the games in his list but also the active game on the board. My idea
was to allow to have a look to the games of another base without changing
the game on the board. So I do not want to "to move db switching
functionality to the games list". Only to switch the db of the game list.
-------------
> I understand your point and i agree with you, however there are some
technical difficulties to a fully general purpose gameslist window:
> 1) In fact glist windows are independent and there are no problems with
multiple instances.
> However glist.create need a layout string to save differents column layout
and sort criteria.
> Now this is automatic: best games and db switcher can have they different
column order and sort criteria.
> With only one general purpose gameslist window the user will have to
manually select the preferred layout each time.
> 2) You need to decide when to call glist.update Actually this is a mess:
for example i found out that there are 71 reference to
::windows::gamelist::Refresh.
> For a general purpose gameslist we need to write some sort of event based
system for filters: glist window register itself to the correspondent filter
and the filter notify the registered windows when it changes.
> I understand the advantages of a general purpose gameslist window, for
example it will be useful sometimes to have two database games list opened
at the same time.
> However i don't know if it's worth the effort.
> I will be in spain the next week, i think we can wait to hear the opinions
of scid users about this.
>From this 71 references around 40 are not necessary and duplicates. The
advantage is to have them, where they are necessary. They are the perfect
hook. Registering multiple windows for changes had already been done with
the old best game windows. So I think this can work in a similar way. So
there is no need of implementing a new logic.
Gerd
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
