OSX Xboard 4.7.2 .app

[hgm]

Well, I should thank you! Having an XBoard front-end that was more native to a Mac has always been on our wish list, and although purists might still consider using GTK not truly native, it seems you have been able to erase most of the visible difference. As a non-programmer, you have been able to achieve what no Mac programmer could or wanted to do!

[JoshPettus]

Well there are a growing number of linux ported apps using the Gimp toolkit including Gimp. At least this way you don't have to support a front-end you don't have access too. It's really nice that there is a whole library for making it closer to native.

You once said in linux you have the make install associate png files with xboard. I guess the next thing we should do to improve the app is to do the same for mac. Since it's an app, the os will let us. Getting it to pass through GTK would be the trick. The mac-integration documentation has a little information about the OS signal. But how to incorporate it into the app, I have no idea. Gimp does it with it's own files, so it should be possible. I'll have to create an icon and do some reading up on the Info.plist modification for the mac side of things.

[JoshPettus]

Well I did step 1 and 2 created an icon for PGN files associated with xboard. And I put this in the info.plist

Based on info on CFDocumentTypes


I put this in the info.plist file

Code: Select all

<array>
		<dict>
			<key>CFBundleTypeExtensions</key>
			<array>
				<string>pgn</string>
			</array>
			<key>CFBundleTypeIconFile</key>
			<string>PGN.icns</string>
			<key>CFBundleTypeName</key>
			<string>Portable Game Notation</string>
			<key>CFBundleTypeOSTypes</key>
			<array>
				<string>cpgn</string>
			</array>
			<key>CFBundleTypeRole</key>
			<string>Editor</string>
			<key>LSItemContentTypes</key>
			<array>
				<string>com.dec.xboard.pgn</string>
			</array>
			<key>LSTypeIsPackage</key>
			<false/>
		</dict>
	</array>	

Which apparently isn't enough for the OS to associate PGN files. I'll have to look into it more.

[hgm]

These associations are purely an OS thing, which go on completely outside XBoard. Each OS has its own mechanism for this. E.g. in MS Windows files are recognized purely by extension, and in the registry you can associate a certain extension with a certain command, possibly containing the filename. So *.pgn is accociated with the command 'winboard -viewer -lgf FILENAME', so that clicking the PGN file would start up WinBoard with that file as game file, in Game Viewer mode (so you won't end up in the Startup dialog).

In Linux it is a bit more complex: files have 'mime types', which can be defined in terms of filename as well as contents. You first have to register a mime type, by submitting an xml file containing the definition of the type, the text string (in various languages) that the OS should use to describe it, the icon with which to display it, etc. This is all done in the file xboard.xml of the source tree. The Makefile will run the command xdg-mime on this .xml file during 'make install'. Because it refers to non-standard icons, the install will also have to log the icons with the system, using the command xdg-icon-resource with the icon images that come with XBoard (used to be .xpm, but should be .png files in the future). Finally the defined mime types should be associated with a command. This is done through running the command xdg-desktop-menu on *.desktop files supplied with XBoard. E.g. xboard-pgn-viewer.desktop for the PGN files. These .desktop files tell Linux what command to execute (Exec=...), in which menu group it should belong, if there should be a desktop icon displayed, the name that should be displayed with such an icon, or when you hover over it, if a terminal window should be opened to run it in, etc.

I don't know if OSX uses the same mechanism as Linux, or has an entirely different set of commands that need entirely different input files for describing the file types and actions. If so, we would have to create the latter description files, and distribute them in the XBoard source. Binary packages would have to run the required OSX commands on such files from an install script. (And they'd better clean up all what they did on uninstall...)

[JoshPettus]

Thanks for the info.

In OSX, the info.plist inside every bundle is an xml file with all the registry information for the app that is then installed into the OS. With it, you can specify the executable, icons, app info, associated document types, and a bunch more. In theory... There is a possible option for MIME types but I'm not sure how that works. I'll email a friend of mine who does a lot of mac development see if he has any ideas.

[JoshPettus]

Well I got an email back from him, in it he describes in pretty good detail how Mac handles file associations.

Well, you’re about halfway there with the plist: but you’re using outdated keys that OS X is ignoring. In 10.5 they overhauled the way new filetypes are defined, so nowadays they need to be declared in two places in the plist file.

- The first place is in CFBundleDocumentTypes and you got this mostly right already. This part declares which Uniform Type Identifiers the application can open, what its relationship to those filetypes is (owner, editor etc), and which icon should be used for the file when this app is the default opener of it. The other fields (regarding file extensions and mimetypes etc.) are now ignored.
- The second place is in UTExportedTypeDeclarations. This declares *the Uniform Type Identifier itself* and which file extensions and mimetypes identify a file as belonging to that type.

So, UTExportedTypeDeclarations says “there’s a kind of file I’d like to call com.dec.xboard.pgn, which matches files with the extension .pgn or the mimetype application/x-chess-pgn”, while CFBundleDocumentTypes says “I can open com.dec.xboard.pgn files.”

I’ve attached a sample plist that has the correct definitions. This *should* be enough to get OS X to launch your app when you doubleclick on such a file. (It should also make your icon file show up, as long as the icon file is located in /Contents/Resources/ in your application bundle.) Note that you may need to move or rename the application bundle in order for OS X to re-evaluate the types declared in the plist.


With that out of the way, you’ll still need to contend with the fact that your GTK app probably won’t open the file correctly. When OS X launches an application in order to open a file, it’ll pass the file’s full path as the first launch argument - but unfortunately it won’t add those other launch arguments (“-viewer -lgf”) that your app may need. On top of this, if the appropriate application is already running, then OS X won’t relaunch it - it’ll try to send it Apple Events asking it to open the file, which your GTK app may not be listening for.

That said, I see that you have a “load game” menu option that takes pgn files, so it's possible that everything is already wired up to support opening files from Finder too. If not, then you’ll have to wire things up yourself.

If your app is Cocoafied enough to use NSApplication, which I guess it does if you have a MainMenu.nib, then you should already have your own NSApplication delegate class (called “[MyPrefix]AppDelegate” in new projects) ready to customise. In this class you would implement the application:openFile: method, which is what gets called when OS X wants your app to load a file from Finder (whether OS X launched the app or it’s already running, it’ll get called either way). Do a search for “application:openFile:” in XCode’s documentation and you’ll find the full details - but basically, the method receives the full path to the desired file and you can pass that on to the game’s own load-this-game-file machinery.

I explained to him that the .nibs file (which is a compiled xml file for describing the Menu and UI for cocoa apps) does nothing at this point and it's all handled by GTK and the gtkmacintegration lib. One of the things I noticed was that the lib handled the NSApplicationOpenFile call from the OS. I guess we will have to get the app to launch the load png files from that call.

http://gtk-osx.sourceforge.net/gtk-mac- ... onOpenFile

[hgm]

OK, I think I understand most of that. That you cannot specify arguments in the association has already been solved, because the same is true when you drag and drop a document icon on an application icon in Windows. This also generates the command "application.exe droppedfile" without any extra arguments.

XBoard has always had the property that it would interpret a command "xboard xxx" without any options as "xboard -lgf xxx". I just made it a bit more subtle in this: it now depends on the filename extension of xxx what exatly it will do. "xboard xxx.fen" will be interpreted as "xboard -viewer -lpf xxx.fen", "xboard xxx.trn" as "xboard -mm -tf xxx.trn, "xboard xxx.xop" as "xboard @xxx.xop" and all other names as "xboard -viewer -lgf xxx" (*). So this would work fine.

That OS X would not start up a second XBoard process when one XBoard is already running would be a problem, however. XBoard can handle only only one game file or match at the time. Apparently in stead of starting a new instance of the application, OS X would send some signal to the running one (which the current XBoard version no doubt will ignore). To fix this, XBoard should be set up to catch that signal, and in response to it do what OS X failed to do: start up a new XBoard process with the desired file argument (which must have been passed somehow with the signal). I suppose that executing the code line

system("xboard filename");

in response to the signal would do the trick (unless OS X would be so pigheaded to also recognize this as the startup of an already-running application, and replace it by sending a signal, in which case we would have to bypass OS X even more, by writing our own fork() and exec() calls). So the only problem is how to catch the OS X signal that says a new XBoard instance is required.

*) The option -viewer was added as a 'meta mode' next to the basic modes -ncp, -cp and -ics, and can be defined by the user to mean any of the basic modes dressed up with other options, through the -viewerOptions option. E.g.

-viewerOptions "-cp -fcp fruit -fUCI -initialMode AnalyzeMode"

would configure XBoard to automatically start up with Fruit analyzing the game in the clicked PGN file.

[JoshPettus]

But if I type in a terminal 'xboard file.pgn' it just give me unrecognized argument. Is when it is handled by the OS somehow diffrent? I've tried the drag an drop and Open With and it just opens up xboard without loading the file. I'm not sure if xboard is receiving the 'xboard xxx' in its current state.

[hgm]

OK, after reading the link you gave, I think we need the following:

Somewhere we have to call

Code: Select all

g_signal_connect(theApp, "NSApplicationOpenFile", G_CALLBACK(StartNewXBoard), NULL);

where we would have to define our own function for handling the signal as:

Code: Select all

static gboolean
StartNewXBoard(GtkosxApplication *app, gchar *path, gpointer  user_data)
{
    char buf[MSG_SIZ];
    snprintf(buf, MSG_SIZ, "xboard %s", path);
printf("Open new XBoard\n"); // this line for debugging purposes only; remove later
    system(buf);
    return TRUE;
}

The latter can be defined somewehere near the top of xoptions.c (e.g. just above the "void UnCaret()". It has to prepare the command line by prefixing the path of the clicked file it gets from OSX with the 'xboard' command. This assumes the 'xboard' command can be issued from the current directory, and does not need a full path name. And if the xboard binary is not in a globally known path, but in the current directory, you would have to write './xboard' in stead of 'xboard'. If the full pathname to the xboard binary would be required, we would somehow have to construct that here (perhaps using gtkosx_application_get_bundle_path(), and printing that before 'xboard' in the snprintf()).

To keep things a bit localized, it would probably be best to call the g_signal_connect in the added code at BarEnd (although the logocal place would be in xboard.c, shortly after gtk_init();): change that to

Code: Select all

    if(option[i].target) ((ButtonCallback*)option[i].target)(boxStart); // callback that can make sizing decisions
    {
      GtkosxApplication *theApp = g_object_new(GTKOSX_TYPE_APPLICATION, NULL);
      extern MenuItem helpMenu[];
      g_signal_connect(theApp, "NSApplicationOpenFile", G_CALLBACK(StartNewXBoard), NULL); // ADD
      gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(menuBar));
k;

(This again makes use of the fact that this code will only be executed once, as there will be only a single window with a menu bar.)

[JoshPettus]

I think the code worked since the application is laid out like this:

Contents/
->MacOS/ ->Xboard (gtk launch script) xboard-bin (actual xboard bin)
->Resources/

Resources/
->Bin/ (set as the current working directory in the app by the launch script)

I had the code read:

Code: Select all

static gboolean
StartNewXBoard(GtkosxApplication *app, gchar *path, gpointer  user_data)
{
    char buf[MSG_SIZ];
    snprintf(buf, MSG_SIZ, "../../MacOS/xboard %s", path);
printf("Open new XBoard\n"); // this line for debugging purposes only; remove later
    system(buf);
    return TRUE;
} 

Which probably worked..

Anyway as a result I got this in the Terminal when i tried to open a png file from the Finder:

Code: Select all

Open new XBoard
xboard
../../MacOS
xboard-bin: Unrecognized argument /Applications/Xboard/Josh-Crafty-23.5.pgn

At least we know it got a signal from the OS. But xboard isn't automatically adding the functions to open a pgn file.

[EDIT] Actually It didn't work as xboard didn't open a new window like we wanted.