OSX Xboard 4.7.2 .app

[hgm]

I thought in the xboard code ctrl-c and ctrl-v were already used for copy paste game.

Indeed, but b handling the key binding in the automatic way, the OS X vesion automatically changed that to Apple-C and Apple-V, because in OS X the use of Apple in stead of Ctrl is the standard. But ince the menu is always up, and overrides widget-specific bindings,we should actually stay away from anything that is standard.

[JoshPettus]

I'm sure your busy, but just to list off the things that seem to be missing in your branch for your convenience.

1. The last patch with editing ~~/ into the user conf in args.h

Code: Select all

    case ArgFilename:
      if(*(char**)ad->argLoc == NULL) break; // just in case
      { char buf[MSG_SIZ];
        snprintf(buf, MSG_SIZ, "%s", *(char**)ad->argLoc);
#ifdef __APPLE__
        if(strstr(buf, DATADIR) == buf)
          snprintf(buf, MSG_SIZ, "~~%s", *(char**)ad->argLoc + strlen(DATADIR));
#endif
        if (strchr(buf, '\"')) {
          fprintf(f, OPTCHAR "%s" SEPCHAR "'%s'\n", ad->argName, buf);
        } else {
          fprintf(f, OPTCHAR "%s" SEPCHAR "\"%s\"\n", ad->argName, buf);
        }
      }
      break;
    case ArgBoardSize:

2. Some bit of code that suppressed one of the calls keeping it from opening xboard repeatedly on the second launch.


3. The new bit of code for infoProc

Code: Select all

InfoProc ()
{
#ifdef __APPLE__
    char buf[MSG_SIZ];
    snprintf(buf, MSG_SIZ, "%s ./info.command", appData.sysOpen);
    system(buf);
#else
    char buf[MSG_SIZ];
    snprintf(buf, sizeof(buf), "xterm -e info --directory %s --directory . -f %s &",
       INFODIR, INFOFILE);
    system(buf);
#endif
}

[JoshPettus]

Dang shame

I found a great theme that made it look even more native by mimicking the aqua interface. It would be perfect except in one minor area, the preview buttons for the board/piece colors are replaced by the buttons as well. I'm not sure how to have my cake and eat it.

[/img]

[JoshPettus]

Never mind! I found one that works much better!

http://dolsilwa.deviantart.com/art/elem ... -210121746

[hgm]

I had not much time to work on XBoard the past week, and wanted to wait a bit anyway, to prevent mixing of patches for the ICS Console with others, before the former was well debugged.

Note that the current interface for selecting square colors is basically an outdated legacy of Xaw. I am pretty sure GTK offers an official 'color picker' dialog, and the R/G/B/D buttons should really be replaced by a single button (like 'Browse' for text-edits) to invoke it. I am not sure how necessary it would be to offer a color preview in the dialog.

[JoshPettus]

I had not much time to work on XBoard the past week...

Don't worry about it! there is no rush! I had forgot about the InfoProc bit so I wanted to make sure it was mentioned.

... I am not sure how necessary it would be to offer a color preview in the dialog.

With a proper color picker window probably not. But no worries for now, that second theme handles it correctly as is. And looks better as a whole too.

[JoshPettus]

I realize you're busy and this is just an idea for very minor esthetical function, so lets save it for later. Anyway I saw on the gtk-quartz description that you could manipulate an application's dock tile.

I saw this section in the macintegration lib:
http://gtk-osx.sourceforge.net/gtk-mac- ... n-resource

My suspicion is that we can use this to switch the dock icon from black to white according to who's turn it is similar to how it's done in linux.

I think I'll call the two icons XBoard_w.icns and XBoard_b.icns, and both will be in the "/Xboard.app/Contents/Resource" folder.

Personally, I hide my dock when until my cursor is on the edge of the screen. But someone will think it snazzy.

[JoshPettus]

Dang, I was wrong...This repeating open bug was in the last xboard.app release and so was in the savanah banch. Why I didn't notice before, i don't know. I thought I tested that part. I have no idea why it's creeping up again. I really thought we fixed it.

For jokes I put in the debug code we had before.

Code: Select all

25556 Start XBoard: argc = 1, arg = NONE
 25556 Signal: suppress = 0, path = /Applications/Xboard/joshua-Sjeng_11.2.pgn
 25567 Start XBoard: argc = 2, arg = /Applications/Xboard/joshua-Sjeng_11.2.pgn
 25567 Signal: suppress = 0, path = /Applications/Xboard/joshua-Sjeng_11.2.pgn
 25576 Start XBoard: argc = 2, arg = /Applications/Xboard/joshua-Sjeng_11.2.pgn
 25576 Signal: suppress = 0, path = /Applications/Xboard/joshua-Sjeng_11.2.pgn
 25584 Start XBoard: argc = 2, arg = /Applications/Xboard/joshua-Sjeng_11.2.pgn
 25584 Signal: suppress = 0, path = /Applications/Xboard/joshua-Sjeng_11.2.pgn
 25592 Start XBoard: argc = 2, arg = /Applications/Xboard/joshua-Sjeng_11.2.pgn
 25592 Signal: suppress = 0, path = /Applications/Xboard/joshua-Sjeng_11.2.pgn
....

And goes on, for as many times as I let xboard open.

If I understand it correctly, It doesn't look like the suppress is suppressing. But the line of code that we had before is there in xboard.c. Not sure what's going on.

[JoshPettus]

Hate to point out another bug, as you are busy. And haven't had a chance to look at the 500 other things.



Unfortunately, when xboard starts it doesn't update the menubar with what has been already opened by the commandline/user .conf file. This is particularly noticeable with the check on "save settings on exit" To get it to display you must select it (disabling what was open) and select it again.

I'm really not sure what we can do to fix this, but Gimp doesn't appear to have this problem.

[hgm]

Well, my main problem with XBoard currently is that the ICS Console patch completely broke the Xaw build, and that it doesn't seem trivial to get it running again. I don't want to make my current master the 'official' version by pushing it to Savannah before I have solved that.

The problem you report here does not seem to exist in the Linux version. Dialogs that are open at startup are popped up by exactly the same routines as when you pop them up from the menu later. These routines do contain explicit calls to MarkMenu() in order to tick the menu item, and the corresponding PopDown() will then untick them.

So it is mysterious that when popping up during the initialization these MarkMenu() calls seem uneffective. Perhaps they are always ineffective, but replaced by an automatic response of the items to a click.

What happens when you close such a window by clicking the window-close button rather than the menu item? Does that untick the menu item? If it does that would be prove that the MarkMenu() calls do work, and that clearing the checkbox does not occur just becouse you clicked a checked menu item.

Another test would be if you pop up something later. The new ICS/Chat Console can be popped up without clciking a menu item, by just starting to type to the board, in ICS mode. (In 4.7.3 the ICS Input Box should behave similarly.) Perhaps you can check if in that case the item gets checked.