OSX XBoard/WinBoard.app 4.7.3 Release Thread

[H.G.Muller]

That all looks OK. And you need the change in SetClockIcon() as well, of course.

As SVG images are text files, I just opened one with an editor, and could see they specify a nominal size of 100x100. Perhaps the OS X dock does not like that size?

[Edit] To directly set the dock icon from file, you would need something like (in the __APPLE__ part of SetClockIcon):

Code: Select all

if(color)
    gtkosx_application_set_dock_icon_resource(theApp, "icon_black", "svg", BUNDLESUBDIR);
else
    gtkosx_application_set_dock_icon_resource(theApp, "icon_white", "svg", BUNDLESUBDIR);


[Josh Pettus]

I don't think that is it. I can manually replace the actual .icns icon by copy pasting a 100x100 pixel image as the icon for the app bundle and that goes directly to the dock when opened. (although looks blurry) The dock itself can be resized to anything and has a myriad of scaling effects, so it resizes these bitmap images to however it needs.

I'll try the resource command, with some png s i made from the svg files.

[Josh Pettus]

Dang,
I tried

Code: Select all

SetClockIcon (int color)
{
    GdkPixbuf *pm = *clockIcons[color];
    if (mainwindowIcon != pm) {
        mainwindowIcon = pm;
#ifdef __APPLE__
        if(color)
            gtkosx_application_set_dock_icon_resource(theApp, "icon_black", "png", "/share/xboard/textures/textures");
        else
            gtkosx_application_set_dock_icon_resource(theApp, "icon_white", "png", "/share/xboard/textures/textures");
#else
        gtk_window_set_icon(GTK_WINDOW(shellWidget), mainwindowIcon);
#endif
    }
}

still no luck, unless i am misunderstanding the subdir part.

[H.G.Muller]

You might, as it is supposed to be relative to the root of the app bundle. So it might not start with '/'.

It could also be that the extension has to be part of the name: "icon_white.svg", "svg", ...

[Josh Pettus]

I tried both, neither worked Is there a way to see if it actually found a file?

[H.G.Muller]

Apparently not. One would have expected the gtkosx function to return a value indicating success, or an error number. But is is defined as a 'void' function, returning nothing. The manual entry for it says:

Code: Select all

subdir :    The subdirectory of $Bundle/Contents/Resources in which to look for the file.

I am not sure what this means, but I don't know how your app bundle is organized. $Bundle is probably the path of the bundle root, (retrieved by the gtkosx_application_get_bundle_path() we used earlier). Do you have sub-directories Contents/Recources in there? It seems essential that the image files reside somewhere in that part of the bundle tree.

It could also be that SVG is not amongst the supported image types.

[Edit] I had a peek to the gtk-mac-integration project at github, and this suggests that we have nothing to gain from using the _resource function in stead of the _pixbuf function. The former just constructs a path from its arguments, and then uses gdk_pixbuf_new_from_file withe that path to create a pixbuf (just as we do already in main()), and then calls the _pixbuf function on it. So we only suffer an extra opportunity to make errors by not understanding exactly how the file-addressing mechanism works here.

If we rely on the filename -> pixbuf retrieval in main(), we can at least test if that is succesful, by adding

Code: Select all

if(!WhiteIcon || !BlackIcon) DisplayError("could not retrieve icons", 0);

after the gdk_pixbuf_new_from_file calls.

[Josh Pettus]

Great thanks! That's really good to know, I put back the old from pixbuf code in the SetClockIcon bit and put in the error bit. It indeed does not see where the files are.
This is with:

Code: Select all

    WhiteIcon  = gdk_pixbuf_new_from_file(SVGDIR "/icon_white.svg", NULL);
    BlackIcon  = gdk_pixbuf_new_from_file(SVGDIR "/icon_black.svg", NULL);

It's also possible svg won't work.
How about we do another #ifdef _APPLE__ here and have it point to the Resource folder and icon_black.png and icon_white.png. How would we do that?

FYI, our app does have the standard $Bundle/Contents/Resources layout. I put all xboard's and gtk's data in there under various subfolders.

[H.G.Muller]

Well, as far as I can see the default pieces (when no -pid is defined) are loaded from SVGDIR. (E.g. SVGDIR/WhiteKing.svg .) This is a symbol that is externally supplied by the config process as a -DSVGDIR=... compiler flag, so I suppose we set it according to the bundle path and where you stored the piece SVGs in the bundle. This means it should also work here. (The icons for the Engine Output window are also coming from there, btw. Do these work?) Provided the icon_white/black.svg are indeed in the same folder as the pieces, I don't understand how it could not work. The gdk_pixbuf_new_from_file is not a gtkosx function, we also use it in Linux, and it certainly understands SVG.

Of course for testing you could replace the filename from which the pixbufs are loaded by something else, where you are sure they are present.

[Josh Pettus]

Interesting.

Well the Engine Output window icons never did work. If we can get them to work with that compiler flag then that would be great!
For testing I tried pointing it to the .svg files with a full directory. It didn't work, but interestingly enough, the png files I made from the Svg ones worked just fine!

I suppose the code just says if there is an error to say "could not retrieve icons". In actuality, I don't think OSX can display SVG files directly in its dock.
GTK's Cairo can though, so I'm sure the Engine Output icons wil work fine once the SVGDIR is defined.

Somehow we have to come up with a symbol to point to thoes for ~~/Contents/Resources/icon_white.png and ~~/Contents/Resources/icon_black.png
Or I can put them in the SVGDIR folder

can we define it as
-DSVGDIR=~~/Contents/Resources/share/xboard/textures/default ?
[EDIT] I tried defining svgdir to it and It didn't work...

[H.G.Muller]

Interesting.

Well the Engine Output window icons never did work. If we can get them to work with that compiler flag then that would be great!
For testing I tried pointing it to the .svg files with a full directory. It didn't work, but interestingly enough, the png files I made from the Svg ones worked just fine!

I suppose the code just says if there is an error to say "could not retrieve icons". In actuality, I don't think OSX can display SVG files directly in its dock.
GTK's Cairo can though, so I'm sure the Engine Output icons wil work fine once the SVGDIR is defined.

Indeed, we just programmed it to show that error popup if the pixbufs were not created by the gdk_pixbuf calls.
We could get more info if we would replace the NULL argument in that call by &i , and the final 0 argument in DisplayError by i . This would pass the error number.

The problem is that the Engine Output icons are read into pixbufs in exactly the same way. So if the pixbuf_from_file cannot do its job on SVG files on OS X, it does not matter which agent will finally attempt to draw it. There would be nothing to draw.

If it works only for PNG, we could change the names from "/icon_white.svg" into "/icon_white.png" ,
and supply the png files in the same directory as the pieces.

If this works a similar operation could be done on gtk/xengineoutput.c, for all the svg icons there.

I don't think the SVGDIR can be the problem. It does get the pieces from there, right? Or have you configured some -pieceImageDirectory?

[Josh Pettus]

Well SVGDIR is not defined in anyway that is useful to the app. Instead it only has what's in the master conf file for -pid. We probably should define it somehow in a portable manner. It could make things a tad simpler. It has to read the files from somewhere. If PGN is the way to go, I'm fine with it. For OSX, I would still like to change icon_white to a white knight, as it would look much better in the dock then the inverse picture.

[H.G.Muller]

Ah, sorry, I did not know that. So you rely on the -pid in the master settings file to get the default pieces? That is very undesirable, because when the user would redefine the -pid, there would not be anything to fall back on for pieces that are missing there.

The proper way to do it would be to define SVG to what it has to be for you in the bundle. For now you could use a similar trick as we do now for DATADIR: #undef SVGDIR and then #define SVGDIR "whatever/path/you/need/to/get/to/the/pieces" .

That would not allow for installing the app in a different path, but if it works, I will write some code for it to take care of that.

[Josh Pettus]

That's quite true, I have already run into a few issues with that with the Shogi and Xiangqi packages, that I had to work around. It really isn't ideal.

Anyway I did try defining SVGDIR to a full dir. Interestingly enough, the svg pieces don't show. (I removed -pid from the master and user confs) But I know it worked because it does find the .png icons I put there. Should the svg pieces be in some sort of subfolder of SVGDIR?

Also the Engine Output window still doesn't work even though I created .png files from them and changed the names accordingly in xengineoutput.c. They are 39x39 which was the .svg default size, I think. Should they be something else?

[H.G.Muller]

I was wondering if we should not solve this problem by having XBoard always change directory to its installation folder, like WinBoard does. In Linux the current directory is not very important, as all files are in fixed places, or at least places known during compile time through the configure process. So all the fle names are absolute paths there. In WinBoard they are mostly relative paths, e.g. Polyglot is always sought in the same forder as winboard.exe, no matter where you installed the latter. So I just keep XBoard where it is, by initializing the variable installDir to ".", and never changing it.

So in the code we inserted near the top of main(), just after we retrieved the bundle_path, we could add a line

Code: Select all

        char *path = gtkosx_application_get_bundle_path();
        SetCurrentDirectory(path); SetCurrentDirectory("Contents/Resources");


So that we are always sure to be in a directory inside the bundle, and can indicate all files relative to that. E.g. by #defining SVGDIR as "." or "svg" or whatever subdirectory of Contents/Resources you are using to store the pieces and icons.

That #define SVG (after #undef) should then be in a place that is globally seen (like common.h), so that also xoutput.c would know about it.

I don't know if it would have any adverse effects to let XBoard always start inside the bundle. (I guess it would try to create its xboard.debug files there, then, rather than in the user's directory.)

[H.G.Muller]

OK, I tried another approach. I just pushed a commit for that to hgm.nubati.net.

I noticed that SVGDIR was used only in 3 places in the entire source: in draw.c to load piece images, in xboard.c to load the taskbar icons, and in xengineoutput.c to load the Engine Output icons. The latter two tasks were basically identical, except that in xengineoutput.c the icons were stored in an array iconsGTK[], while in xboard.c they were stored in separate variables WhiteIcon and BlackIcon. I now combined the code for that in a new routine LoadIconFile(), put in xboard.c, which can be called from the two places with the basename of the icon file to load, so that the caller can the store it where it wants. LoadIconFile appends the extension to the basename, so it can be easily made dependent on the __APPLE__ switch for #defining IMG as either .svg or .png .

Due to this change SVGDIR is used nowhere anymore as a string concatenation (like SVGDIR "/something"), which is a C construct processed at compile time, which would only be possible if SVGDIR was a litteral string constant (like "/usr/local/share/games/xboard/themes/defaults"). So I replaced SVGDIR everywhere in the source (well, only two places now) by a variable svgDir, which is initialized to SVGDIR. In Linux that has the same effect. But it gives us the opportunity to overwrite it at run time, after we retrieved the bundle path. To this end I added a line in the __APPLE__ patch at the top of main():

Code: Select all

        snprintf(svgDir, MSG_SIZ, "%s/Contents/Resources/themes/defaults", path);


which constructs the SVGDIR name from 'path' (the path name of the bundle root).

Please check if the filename this constructs is indeed where you store pieces and icons in the bundle.

This should solve both the icon problem and the reading of default pieces regardless of the -pid setting.

[Josh Pettus]

Nice, looks really clean!

In regards to path here is what I would like it to be

Code: Select all

   snprintf(svgDir, MSG_SIZ, "%s/Contents/Resources/share/xboard/themes/default", path);


(I took to opportunity to change the folder from "textures" to "themes" which makes more sense.)

It now it finds all the svg pieces, and, for once, it loads up the Engine Output icons!
I had to change their sizes from 39x39 to 16x16 to make them fit better.

Now it doesn't find the icon_white.png and icon_black.png

or

Code: Select all

    WhiteIcon  = LoadIconFile("icon_white");
    BlackIcon  = LoadIconFile("icon_black");

I'm not sure why.

[EDIT] Oh I see, you forgot

Code: Select all

void
SetClockIcon (int color)
{
    GdkPixbuf *pm = *clockIcons[color];
    if (mainwindowIcon != pm) {
        mainwindowIcon = pm;
#ifdef __APPLE__
        gtkosx_application_set_dock_icon_pixbuf(theApp, mainwindowIcon);
#else
        gtk_window_set_icon(GTK_WINDOW(shellWidget), mainwindowIcon);
#endif
    }
}

[H.G.Muller]

Ah yes, I had not incorporated that yet, as upto now it was not really working.
So when I would add that, and change the SVGDIR path, would we be OK?

I noticed that in usystem.c DATADIR is used in the code that expands ~~/... in filename options. That would still use the Linux-like path, however, as the __APPLE__-dependent #define of DATADIR to use the retreived bundle path is only in gtk/xboard.c, and does not extend its influence outside it. Would that be a problem? Or is the ~~/ notation not really needed anywhere in the OS X app?

[Josh Pettus]

Yup thoes 2 things and evreything seems to work.

I use the DATADIR ~~/ quite extensively in the master.conf file to find board textures, farirymax, fruit, polyglot, sounds, timestamp, timeseal, engine logos (Although I have it search for a folder outside of xboard.app for that one. Maybe a definable option in the Board menu would be better for this?).

[Josh Pettus]

Just thinking here but we should probably use the gtkosx_application_attention_request () function when a move is made. From what I understand of the function, it will bounce the dock icon for one second if the application is not in focus. Could be useful, could be annoying.

[H.G.Muller]

I think it would be more annoying than useful. For one, I cannot imagine why someone would push XBoard to the background if he is playing a game of chess. And in the unlikely case he would, just having an icon bounce in a corner of the screen for 1 sec is not likely to attract his attention.

XBoard already has the possibility to play a sound on such an event, and that would be far more effective. There also is the option 'raise board', which would make the board pop in front of everything else. I think that would also be triggered by a move. (At least in ICS mode.)

Let's not do things just because we can...