On 01/18/2011 04:11 AM, Benoit St-Pierre wrote: Hi!
>> I want to switch between databases with one mouse-click. This may be no >> "standard", but sorry I cannot live without it. > > I too like to switch with the Database Switcher. So what is your point then? > I am not suggesting that we remove the Switcher and build it into the menu. Eh??? "In contemporary GUI, these kinds of switchers are in a menu." (Not that I care about contemporary GUIs to much, some even removed menus for some thing called ribbon.) > I am merely saying that merging games between databases should be > accessible via the menu. > As is switching between databases: File/Switch to Database [1-9]. So we get another 5 enties in the File menu that do nothing beyond switching to another base. (Scid can only handle up to 5 bases btw.) Given your suggestion to stick to standards we would however add a "Windows" menu for this. It has no other use in Scids working environment and it doesn't translate to the concept of Scid, as unfortunately, Scid does not use the same concept of windows as you have in many other apps. You just don't open another "window" like in your editor. (At some point you really have to understand this major difference, it is important.) So we have to name it something differently. Ups, we lost the standard. What did we win here? Besides, "windows" is actually a menu with an entirely different functionality in Scid. So we rewrite that concept and menu as well, but it opens windows. Hm, we'd have to reinvent a name for window. Probably dialogues? Then we improve the games list to allow for multiple selections and add copy & paste functionality there. Maybe on the go we copy some 10.000 games via system clipboard as this is the standard way to do it in ... Notepad. IMHO we do not win anything in this way. > More generaly, every action possible in Scid should be accessible in the menu. Actually, I think it is. It just depends on where this menu is sensible and where not. The most sensible ones are smart context menus. > I vaguely recall that in Nicbase, it was possible to filter and export > at the same time. It would be more transparent to the user to add "copy all games to base X" in games list. > Perhaps the Search menu could be expanded to include actions like that. What search do you want, we have several: Board / Header / Material / Pattern? Doesn't make sense to add it to the search dialouges(!) here. If then probably better to the games list. >> I want to see how many games are filtered in a database without any click. > > One gets information by looking at windows or by outputing reports. > How many games there is in a filter is obtained by looking at the > Gamelist window. Nope. I usually look at the db switcher. But I'm old fashioned. > The Gamelist window is very important, so important it's always there > in databases. I disagree here, I really have it open in very rare cases. Needs to much space. > Since right-click opens up a contextual menu, it always depend upon context. > So we need is to attach relevant actions to the proper contexts. > What are the relevant actions in the Gamelist window? [Seems something got lost here.] >> I want to drag and drop databases to copy games instead of ... hmm ... what >> is here the "standard"? > > Depends on the verb: exporting, porting, merging, etc. > It would be nice to export a complete filter into another Scid database. > In the Tools menu, we already have the Export/All filter games. > > When you're in your Gamelist Window, you can right-click and already > merge at least one game in another database. NO! You merge it into the game displayed on the main board. You DO NOT "merge games into a database", but into a game itself. It is vitally important to understand some concepts working with Scid. I feel if you can understand chess, however, things in Scid are quite simple. > So it's not impossible to imagine that we right-click to merge all the > games in a filter into another database. Merge would definitely be the wrong word here. At some silent minute you should really start to comprehend the difference between a record based applications (commonly called database) like Scid and a file based application like your text editor. They HAVE to behave differently. Still this suggestion sounds sensible if named properly. However, I believe d&d in the DB switcher is much simpler than RMB->Copy to base-> Popup to select base. Plus you'd have to handle the case that the base in question is not opened, followed by an open dialogue to open it, but if the're already 5 bases open you can't so you tell the user here "sorry". > (Perhaps it's already possible and is only a limitation to Scid under > OSX, I can't check now.) They build from the same source. > Drag& drop and contextual menus are cool, but they're only tricks. NO. In an ideal GUI they're actually centre of the whole thing. Unfortunately, it is quite a task to do it properly. (That you feel they are only a trick may stem from your lack of 2/3 of a mouse on OSX ;) Really, I have to say this at least once: Shane invented some very fine tools and workflows within Scid that are sensible in many respects and usually perfectly fit the tasks at hand. Many suggestions I feel stem from not understanding or not knowing Scids functions. Usually changing Scids GUI ends up in screwing the program and its uses. One should be VERY careful with that and at every change think at least twice about it and it effects, if it really makes sense or just looks like it makes sense and instead breaks many other really good functions. Usually the latter is the case (at least my little experience). Your suggestions concerning DB switcher are IMHO not thought through to the end as is the suggestion to integrate it with the games list. 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
