Alex, > Given your suggestion to stick to standards we would however add a "Windows" > menu for this. You just don't open another "window" like in your editor.
Right: we already have one menu called Windows. I fail to see how this is relevant to our discussion. Let me try again. What I am suggesting is something else: to have access to an app's functionalities through the menus. All the functionalities should be accessible through the menu bar; some useful functionalities should be accessible through the contextual menus. What do you open in Scid? A gamefile, or a database. Can we switch between databases from the menus? Yes: File/Switch to Database... Can we copy a bunch of games to another database? I do not think so. Can you access everything in the Gimp from the menu bar? I think so. Standards are not a matter solely a matter of semantics. *** > So we get another 5 enties in the File menu that do nothing beyond switching > to another base. No, you have one: File/Switch to Database... And it's already there. Scid is a big application, with lots of tools. Chances are it will have lots of stuff in the menu bar. Some can be downsized, like Options. *** > (Scid can only handle up to 5 bases btw.) Under OSX, I have access to nine bases, the ninth being the Clipbase. At least, that's what shows in my menu. I can provide a screenshot. What is the point of that remark anyway? *** > IMHO we do not win anything in this way [to allow for multiple selections and > add copy & paste functionality there]. That's your humble opinion there, and you offer no argument. I offered reasons to improve the contextual menu of the Gamelist window. And Steven submitted that windows get lost. Having access to the Database switcher from the menu bar is helping that. Having access to this functionality in the contextual menu of the Gamelist window might not be a bad idea: we already have Open database there. In fact, I'd rather switch database in the Gamelist window than open a database. One could inspect the content of all the open database more easily that way. *** > It would be more transparent to the user to add "copy all games to base X" in > games list [than exporting directly into another db]. Yes, it would be, and it's the way Scid works. So we should stick with it. As long as we decide that, in Scid, we must first filter the games, then act on them. Fair enough. My point was to say that Scid could add a functionality in Search, where instead of putting the games into a filter, you export the games in another database. You could even ask to delete them. It would be very nice to be able to automatize these tasks, say with macros. This was just an idea from the top of my hat anyway. *** > Nope. I usually look at the db switcher [to get the number of games in my > filters]. Good for you. But you look at a window, which was my point. Obtaining information is not the same thing as changing data, which makes the argument irrelevant to our discussion. To repeat, just to be sure, I'm not suggesting we remove the Database switcher. *** > I disagree here [that the Gamelist window is important], I really have it > open in very rare cases. Needs to much space. Do you look at chess games, Alex? As for myself, I'm going through TWIC each week. In Scid, either I'm checking a chess games or I'm looking at the Games list. (When I have access to docking mode, I put it under my chessboard. That's the only use I have found for docking mode. But I really like it.) Checking a gamelist is where to look to see if we have filtered the games correctly. Checking the gamelist is where to look to have a view of the database as a database. I do not even know why I have to argue for that point. *** > [Seems something got lost here.] Yes, your thoughts about what do you do with the Gamelist window. Start your own user case. Take a person that uses the Gamelist window if need be. You open the Gamelist window. There are chess games. What do you need to do? Write down tasks you'd like to do. After a while, you'd have a nice list of actions that could be callable from the contextual menu. My bet is that "Send filtered games to another database" will be on your list. *** > Merge would definitely be the wrong word here. You're right: it's ambiguous, as we already merge games into other ones. My bad. Sorry. *** > 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. Fair enough. Still, a user might want to send games to another database. I believed in db parlance this is called a merge. My point is not about semantics, but about the fact that exporting (or sending) games might be useful from the contextual menu in the Gamelist window. This might not an important point for you, as you do not care about that window. I would care about it. Would this idea work for you, Steven? *** > Still this suggestion sounds sensible if named properly. Alex, you must realize that this is the only sentence that makes me take the time to respond to you. Two hours, give or take. Two hundred bucks. I believe that Steven might like that kind of compromise too. Of course it makes sense to increase the number of actions one can do with the contextual menu of the Gamelist window! Sheesh! *** > 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". Yes, I understand that there are technical difficulties. If we accept that the user send games to an unopened db, we might need some dialoguing between the user, which slows down a lot. My suggestion would be to export games to already opened db only. Maybe we could reuse some of that File/Switch to database [...] code. *** > In an ideal GUI they're [contextual menu and windows] actually centre of the > whole thing. Unfortunately, it is quite a task to do it properly. I know that under Scid, everything works around windows. I am simply asking that we access to the window's functionality by way of the list of menus (Scid, File, Game, Windows, etc.). The two are not incompatible. *** > 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). Yes, Shane rocks and building a GUI is tough. Don't I know that. Since I am not asking that we remove windows, but only add shortcuts to the menus (the bar and the contextual ones), all this is rendered alien to our discussion. *** > Your suggestions concerning DB switcher are IMHO not thought through to the > end as is the suggestion to integrate it with the games list. I believe that at the time you wrote this you thought that I was against the DB switcher. That's simply not the case. *** > Usual databases for such an app are < 1000 entries. You can dump an entire information system into DevonThink. It's build around AI stuff and can even organize automatically information. In any case, I do not see the point of your scale argument. What's the real difference between exporting 10 citations and 1 millions games to another db? *** > If I take your example seriously you'd have to take databases like "Web of > Science" for comparison (30*10^6 records but the records are much much > slimmer than a usual Scid record.) I am sure they can merge databases, since they're built with relational db and use the concept. *** > Sure. If we implement your suggestion, we would drop all context menues in db > switcher, d&d copy and so on. Then we could move this to a menu. But this > would loose quite some functionality, not? It is IMHO a bad trade. I already told you that I was not for removing the Database Switcher. That's not my point. I am not talking about a trade here. *** > I may remind you that you especially prised Scids D&D copy in your tutorial > some time ago, and if I remember correctly wanted to improve context menues > in the DB switcher as well. Moveing them into a menu does not allow to have a > context menu for a menu entry. I already told you that I was not for removing the Database Switcher. You're editorializing for no good reason here. *** > There is a difference between a reference manager handling some 1000 records > and a database operating on several million records. 10^3 to 10^6 to be > precisely. A factor of 10^3, so to say. This is a lot. And your point is? See how this kind of sentence makes you feel. Yet, I would be interested to know why the scale matters. *** > d&d copy like Scids would not make any sens[e] in an editor ;) Semantics again. You can litterally do that in DevonThink. You can also litterally to that in TextEdit. You can also do that in VIM, albeit with keystrokes. You can also litterally do that with Textmate. You can of course do that with the Finder. Shuffling files and bunches of texts around is what most computers users do when they're not surfing or writing emails. *** > BTW: while I'm at it: any news from the tutorial front? You've just took all my time for Scid for the week. Here are two reasons to invest more than that. The first one is simply that Scid is not for the casual user and the advanced user does not need tutorials, but an active mailing list. The second one has to do with these kinds of sentence: > Not that I care about contemporary GUIs to much [...] > (At some point you really have to understand this major difference, it is > important.) > 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. > But I'm old fashioned. > I feel if you can understand chess, however, things in Scid are quite simple. > Maybe on the go we copy some 10.000 games via system clipboard as this is the > standard way to do it in ... Notepad. > Scid has so many weaknesses that I sometimes wonder why we have any user at all ;) > Just another cause not to drop it, right? ;) > There's a saying in my profession: Users don't like to search, they like to > find. > That you feel they are only a trick may stem from your lack of 2/3 of a mouse > on OSX ; [...] *** I sincerely do not know why you get so argumentative. If I said something that ticks you off, please settle this with me alone: you have my email. So be it for now. Bye, B ------------------------------------------------------------------------------ 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
