OSX Xboard 4.7.2 .app

[JoshPettus]

well in gtk currently, the copy, paste shortcuts are reserved for xboard's copy and paste games. (A little problematic as you often accidentally paste xboard's game info into whatever dialog rather then what you wanted in the clipboard: chat for instance) And the copy and paste of from the OS doesn't exist in the edit menu. So it's good that it's in GTK's right click menu at least. I don't know what we can do to simplify everything.

Mostly I was wondering if we could relay ICStext into the GTK right click menu rather then a popup Dialog box as it would look better and more streamlined.

[hgm]

That should not be true: the XBoard key bindings only work if the board window has focus. When a dialog has focus, and in particular when a text edit inside a dialog has focus, the key bindings function as they would for that text edit. The fact that you can paste games in text edits proves that for Ctrl-V. Ctrl-C and Ctrl-X should work just as well.

As to the Text Menu: in any case we would have to implement the standard functions ourselves in the code that handles the Text Menu. We don't want two menus, or a dialog plus a menu to pop up at the same time. And you can only request GTK to pop up the standard menu or not, not ask it to add items to it, or tell what would be in there. The issue you are raising is more how this should look: as a dialog with buttons, or as a pop-up menu. In WinBoard the choice was made for a pop-up menu.

I am not convinced this matters very much. In WinBoard the piece menu in Edit Position mode is a menu, while the promotion popup is a dialog with buttons. In theory a dialog is more flexible, as it could also contain other items than buttons. But currently this is not used, and I wonder if it could ever be used sensibly. Menu items are smaller than the currently-used buttons. That means you have to be more careful in positioning your mouse to hit them. But with buttons you have to move the pointer further to reach them, and you can afford fewer of them before the dialog gets unweildly large. Considering this stand-off, I just wanted to stick with what we already have. Another aspect is this: GTK menus always pop down once you select an item from them. Dialogs don't (unless you make the program request it, such as I do in the New Variant dialog). This means the current ICS Text Menu dialog can in principle be kept open, next to the board and ICS Console, for as long as the user wants (when he popped it up through the View menu). Depending on the commands he defined in it, (e.g. designed to rapidly communicate with his bughouse partner), that could be much more convenient than having to pop it up by right-clicking for every command he wanted to select.

[JoshPettus]

I see your point about the dialog ICS text. I wonder if we should make it configurable from within xboard as well. Wonder what's the best way to do that.

As for copy paste, because we put the menubar in the OS menubar position, it is active while xboard, or any of it's sub windows, are active. Essentially app-wide. (this is the same if the windows are top level or not.) If you press cmd-v you get an error, game not found in file. unless there is a game in clipboard.

There is probably a way to create a separate menubar for the axillary windows when they are active. But that's not the way we have it currently.

[hgm]

Hmm, that is a pretty annoying design. That the menu bar is valid for all sub windows can be defended, but I don't think in Windows that accelerators for the menu bar would work when widgets within that window have focus that would use these by themselves.

Basically this means that Ctrl-V and Ctrl-C are not acceptable as accelerators for the main menu, in OS X.

[JoshPettus]

well we just have to come up with some more modifiers, shift-cmd C/V is taken. What about alt-cmd C/V?
---

Is there a way to have it switch the command ourselves when the main board is highlighted? So copy paste game is active when that board is active and regular OS copy paste when a dialog is active?

[hgm]

Indeed, we should rethink the key bindings. I think at some time paste game even was Alt-C in WinBoard, and I changed it to Ctrl-C. I also noticed that XBoard (the GTK version at least) does not accept plain Left and Right Arrow to step through the game, but requires Alt-Left and Alt-Right (annoying!). In Xaw the key bindings had to be handled by the user code, so I could easily bind multiple keystrokes to the same function (which did not even have to be a menu item). But in GTK the system handles it.

What exactly are the available modifier keys on a Mac? On PC (USA keyboard) we have Ctrl, Shift and Alt ('Meta' in GDK speak). With USA International there also is Alt-Graphics, but I typically try to stay away from that, because this keyboard style is unusable for the blind. Does Mac also have 3 keys, or are there more? (Most PCs nowadays also support a 'Windows hot key'.)

It is important that we use no keystrokes that are needed in text edits. The most important of those are Ctrl-C, Ctrl-V, Ctrl-X, Ctrl-A, Left and Right Arrow, Home, End, Del, Backspace. (At least, I suppose these are also used in OS X for copy, paste, cut, select all, cursor motion and right/left deletion.) In XBoard they are now used as accelerators for Copy Game, Paste Game, Retract Move, Analyze Mode, unused, unused, Revert, Truncate, unused, unused, respectively. The Left/Right arrows should really be dupliate bindings for the < and > buttons, however. (The reason for them not being the only bindings for this is that in the version for the blind they are neded for other purposes.)

[JoshPettus]

I noticed the alt/arrow for controlling movement. Quite annoying

here is what a basic osx keyboard looks like

http://i.stack.imgur.com/bi2gw.jpg

As you can see the "windows" key is replaced with the Apple/Command/Meta key, and functions as the default modifier and not a shortcut to some silly start menu. eg: ⌘-Q ⌘-C ⌘-V Option(alt) and Control. (Fn is used for laptop functions)

[JoshPettus]

If I recall correctly, we put in code to change all instances of ctrl to meta when compiling for apple. So we don't want to use that key as part of a cmd-ctrl combination. (would make it convoluted for windows as well)

[hgm]

So basically you have one key extra, as Ctrl is now not used and replaced everywhere by the Apple key. So a solution would be to use Ctrl-C, Ctrl-V for the accelerators Copy Game, Paste Game etc, so that the standard keystrokes Apple-C, Apple-V keep working in dialogs.

[JoshPettus]

Sounds good, if you can get it to work. I thought in the xboard code ctrl-c and ctrl-v were already used for copy paste game. Should we add the regular copy paste to the edit menu too? Or should the OS already associate those keyboard shortcuts?