OSX XBoard/WinBoard.app 4.7.3 Release Thread

[Josh Pettus]

Haha, fair enough.

I still think a dialog box for selecting the engine logo folder in the Board menu would be useful. Me declaring to use that folder outside of the app, and only that, doesn't seem right. If it's not too much of a problem that is.
---------------------
There is one more minor bug, which we discussed before. But we didn't get to a resolution. I don't know if we can.

If you recall, there seems to be a problem in the menubar syncing the checkmarks with the popup windows regardless of their actual toggle state. It's not just the windows, but the modes too.
This does work in the gtk menubar in linux, right?
I still have the picture that illustrates this: (for the record, it's an old screenshot. The Engine Output Icons work now)



It may be a bug with the gtkintegration library, but Gimp doesn't seem to have that problem.\
I did try to mention it on the gtk osx bug mailing list, but they correctly took me for the clueless individual I am, and ignored it.

[Josh Pettus]

Oh wow, Opening the Tournament window crashes with a Segfault 11. I believe it's the only window that has an issue. Any idea what could be going on there?

[H.G.Muller]

This works in GTK, and I suppose it is a problem in GTKOSX. My guess was (but only you can verify that) that the checkmarks only toggle when you click the menu item. XBoard calls GTK functions to check / uncheck menu items also on other occasions (in fact always, even if the state changed because you clivked the item). For instance if you close the window by the window-close button, if the Engine-Output window opens because you click 'Analyze Mode', or the Comment dialog pops up because you pressed the > button to step to a move with a comment. There are also cases where clicking an already checked item should not uncheck it (Analyze mode would start / stop the analysis with the second engine, Machine Match would defer the unchecking until the game finishes).

These GTK calls don't seem to be routed through to the OS X menus. I guess we should simply consider that a GTKOSX bug, and not try to work around it, but just wait for it to be fixed. Unless the trick is that you have to call gtk_application_sync_menu_bar(theApp) each time you changed a check-mark or grayout. You could add that as the last statement of xboard.c:EnableNamedMenuItem() and xoptions.c:MarkMenuItem(). (Eventually these would have to be enclosed by #ifdef __APPLE__ to not break Linux compiling.) The latter might be a problem, as theApp is not known there. You could move the entire function to xboard.c to cure that, or declare an

extern GtkosxApplication *theApp;

somewhere in xoptions.c.

[H.G.Muller]

Oh wow, Opening the Tournament window crashes with a Segfault 11. I believe it's the only window that has an issue. Any idea what could be going on there?

The Load Engine, View Board and Game List are OK? (These are the only windows that use listboxes.)

The way I debug that kind of stuff is to uncomment the line

Code: Select all

//printf("option =%2d, top =%2d\n", i, top);


in xoptions.c, and see what it prints before it segfaults. That tells which element of the dialog it was working on while it crashed.

[Edit] Oops, never mind! It crashes for me too, in the GTK build.

[Josh Pettus]

That actually helped!
I did end up putting MarkMenuItem in the xboard.c. Probably did it all wrong but It still helped.

Code: Select all

void
EnableNamedMenuItem (char *menuRef, int state)
{
    MenuItem *item = MenuNameToItem(menuRef);

    if(item && item->handle) gtk_widget_set_sensitive(item->handle, state);
void    gtk_application_sync_menu_bar(theApp);
}

void
MarkMenuItem (char *menuRef, int state)
{
    MenuItem *item = MenuNameToItem(menuRef);
   
    if(item && item->handle) {
        ((GtkCheckMenuItem *) (item->handle))->active = state;
    }

void    gtk_application_sync_menu_bar(theApp);
}


Anyway, now the check marks reflect an active state of the window. A few issues. A) They don't automatically appear if xboard is launched with a window open. B) If you close a window manually by clicking on the "x" it doesn't update the menu. C) The xboard mode menu still doesn't reflect which mode xboard is in. (You switch modes and the checkmark on the old mode is still active) Anything we can do to fix any of these?

[H.G.Muller]

OK, I pushed a fix. The font patch had broken something, or rather activated a latent bug.

[H.G.Muller]

Probably did it all wrong but It still helped.

You should not have the 'void' in front of the gtk calls. (That is only for declarations, not for when you actually use the function.) Otherwise it looks OK.

Anyway, now the check marks reflect an active state of the window. A few issues. A) They don't automatically appear if xboard is launched with a window open. B) If you close a window manually by clicking on the "x" it doesn't update the menu. C) The xboard mode menu still doesn't reflect which mode xboard is in. (You switch modes and the checkmark on the old mode is still active) Anything we can do to fix any of these?

Well, check first if deleting the void helps. I don't understand why these cases should be exceptional. There are separate functions ModeHighlight and InitMenuMarkers, but in the end they all call MarkMenuItem().

The problem with the x buttons could be that we somehow fail to catch that signal, so that OS X closes the dialog for us, rather than allowing XBoard to do it. As debugging aid you could put in MarkMenuItem the line

Code: Select all

    printf("mark %s %d\n", menuRef, state);


which should warn us if XBoard makes at least an attempt to check (1) or uncheck (0) a given menu item.

[Josh Pettus]

Then I get gtk_application_sync_menu_bar as an undefined symbol in both functions. But isn't it defined above?

[H.G.Muller]

Oops. It has to be gtkosx_application_sync_menu_bar.

I guess before it did mistake it for a declaration (because of the preceding void). But then I don't understand how it could have had any effect at all...

[Edit] And menubar is one word.

The manual discription says it works on the menu bar of the 'active window' I hope this sin't a problem if one of the other windows has focus...

[Josh Pettus]

I'm wondering the same thing. Magic I guess... or maybe the moving of the markmenuitem helped.

Anyway once i put in the right function it seemed to work just fine. It even updates when I close the window!

[Josh Pettus]

I just tested out your latest commit, works great!

I guess that's it for the bugs and needed OSX stuff. My list is crossed off. Thanks a lot!

Well, could we put a set logo directory in the Board menu? That's the only other thing I think we need.

[H.G.Muller]

Well, this would be easy enough, just adding a line

Code: Select all

{ 0, 0, 0, NULL, (void*) &appData.logoDir, "", NULL, PathName, N_("Directory with engine logos") },


in the list of initializers for boardOptions[], in dialogs.c.

But wouldn't it be better to configure it to a fixed folder inside the bundle, with the -logoDir option? If we do supply logos with the bundle for FICS and Fairy-Max, people would lose them when they would alter the logo directory.

[Edit] How are the engines in the bundle organized anyway? Are they all in the same directory, such as in /usr/games in Linux, or are they each in their own folder, as in Windows? In the latter case it would be much more convenient to take the logos for -autoLogo from the engine directory (looking for a file logo.png there). The logoDir was really a work-around for the fact that on Linux all engine executables are in the same folder, so that the Windows method did not work. A drawback is that logos are expected to come with the engine package, and it is rather inconvenient, and against the packaging rules of most distros, when the engine packages would have to install files in the XBoard sub-tree. Logical would be to have a /usr/share/games/enginepackagename/logo.png in each engine package, but XBoard cannot know easily the engine package name (e.g. maxqi comes from the fairymax package), and there is the problem with /usr/share or /usr/local/share, etc. I guess it would be very helpful to extend WB protocol with a feature data="datadirpath" to tell XBoard where to look for engine add-ons such as logos. But of course no existing engine would use it anyway, certainly not UCI engines.

We could make the XBoard method a cascade: if an -fd argument was given (i.e. unequal to the default ".") we look for logo.png in that directory, if that file does not exist, we fall back on the logoDir with a png constructed from the 'tidy name' of the engine, as we do in Linux. In fact this would also work conveniently on Linux, as you would use the -fd only with engines imported Windows engines running under wine.

[Josh Pettus]

Well there are the default engines, fairymax 4.8T (you're going to run out of letters soon ) and fruit 2.1. These are in the ~~/Contents/Resources/bin folder with polyglot. So xboard always has defaults. But the thing is, users are always going to plug in engines of their own, and not everyone knows to right click on the app bundle and select "open contents" They would have to find it in the bundle anyway with xboard's menu system to install them. Really with something that is used with xboard in this manner, I feel it needs to be flexable to the users needs. Maybe they want to put their engines somewhere in their home directory, maybe in a folder next to xboard. In that case, I like the idea of supplying logo's with the engines as logo.png, and the logo folder as a backup, but we will still need a place for ICS and user logo's. Perhaps you are right. Inside the app bundle for default. But I think it's still a good idea to give people the option to move it later, if they want, or at least the dialog box has the side effect of visually letting people know where it is if they look through the menus. (Which is always my first step to solving problems, then I look in the help files)

[H.G.Muller]

OK, I see. I guess the best way would be to have XBoard make three tries:
1. logo.png in the engine folder if one was given.
2. <enginecommand>.png in the hard-coded logo folder in the app bundle
3. <enginecommand>.png in the user-specified -logoDir

However, I just placed a call for Linux standardization of logos on TalkChess.
If that gets accepted, Linux engine packages might in the future contain logos,
which would install in /usr/share/games/plugins/logos/. Wouldn't that also happen
when people would install these engines on OS X, then? Or do binary engine
packages for OS X come in a different format, with their own conventions for
where to store the files? What is custom here?

[Josh Pettus]

Well, there is no official repository of software other then the App Store, and I highly doubt chess engines will ever be available there. What you will get is a windows like situation where people see a chess engine binary, download it, and attempt to load it into the GUI. I suppose a person can get a few like crafty from a place like macports, in a very linux like fashion, but the only site that has a lot of mac chess engines, I have seen, is this old site.
http://julien.marcel.free.fr/macchess/Chess_on_Mac/Engines.html

I like your solution of 3 places,
I think the default place should be something like
/Xboard.app/Contents/Resources/share/xboard/logos
However it is you can get there.
DATADIR starts inside the app, right?

[H.G.Muller]

DATADIR is currently set to the bundle path. The master settings file is sought in DATADIR/Contents/Resources/etc.

Perhaps we should contact Julien to discuss with him how to best package engines.

[Josh Pettus]

Well then DATADIR/Contents/Resources/share/xboard/logos would be fine.

As to the best way. Most of the engines on his site and on various authors sites are typically in a zip folder with source, logos, readmes, and various executables for whatever OS they could compile it for.

[H.G.Muller]

That is the same as on Windows. If the logo.png and the executable would in general unzip to the same folder, then the method of looking into the engine folder first should make things work automatically almost always.

[Josh Pettus]

Providing it's not in some silly format like .bmp or .jpeg XD But i agree, I like that system.

[Josh Pettus]

Hmm, I hate to create more work for you but now that I think about it... We now have a great system for the SVG images, xboard knows where it's defaults are, and people can point xboard to their own pieces without messing it up. Now we are about to do the same for engine logos. What about sounds? If people point xboard to any directory for sounds other then default in the app, then those default sound options stop working as well.

That directory is
DATADIR/Contents/Resources/share/xboard/sounds