OSX Xboard 4.7.2 .app

[JoshPettus]

Well thats good, less bugs the better. have a nice trip!

[JoshPettus]

Hey, thanks to Alun Bestor's help, we got everything working well on the OSX side of things. File types are associated with xboard, xboard is treated as a recommend application, it displays icons for each file, and labels them appropriately.
Here is the info.plist for the app, as of now, if it's any use to you.

https://dl.dropboxusercontent.com/u/50486448/Info.plist

[hgm]

How about the 'dock'? Sould we also provide an icon there, and a 'dock menu'?

[hgm]

OK, the promised patch for the BrowseGTK in xoptions.c:

The declaration of fileext has to be changed to:

Code: Select all

    char fileext[MSG_SIZ];

(so no more initialization to "*"). Then the part that constructed the filter (from the 'if' after the comment to the following 'else') has to be changed to:

Code: Select all

    /* filter for specific filetypes e.g. pgn or fen */
    if (currentOption[opt_i].textValue != NULL)
      {
        char *q, *p = currentOption[opt_i].textValue;
        gtk_file_filter_set_name (gtkfilter, p);
        while(*p) {
          snprintf(fileext, MSG_SIZ, "*%s", p);
          while(*p) if(*p++ == ' ')  break;
          for(q=fileext; *q; q++) if(*q == ' ') { *q = NULLCHAR; break; }
          gtk_file_filter_add_pattern(gtkfilter, fileext);
        }
        gtk_file_chooser_add_filter (GTK_FILE_CHOOSER(dialog),gtkfilter);
        /* activate filter */
        gtk_file_chooser_set_filter (GTK_FILE_CHOOSER(dialog),gtkfilter);
      }
    else

[JoshPettus]

The dock is just place where you can drag applications for easy access, it also puts open applications there. It uses the icon of the application bundle, so no worries there. I have seen some applications use a different icon for "opening" then the main for default. They use it for a two frame animation for affect. But this is very rare and not even apple software uses it. I don't think there is a way we can make it switch icons to whoever's turn it is. I personally have the dock hide when my mouse cursor isn't over there, so it wouldn't be of much use to me anyway.

The dock menu isn't really used frequently and most won't notice. When the application is open you can right click on it's icon and it will put up a little menu of commonly used functions. The OS already puts up some basic ones, it has a little options menu where you can set, keep in dock, Open at Login, Show in Finder. In the root menu we have
Show all Windows, Hide, and Quit. An app like Firefox just adds "Open New Window" and Text Edit has Open New, and a list of recently opened files. To be honest I can't think of a function I'd like to add for quick access. If we really wanted. It's not something a user can define later. I suppose we could put up the list of recently opened engines. if it added recently opened PGN files and recently opened ICSs as well that would be even better. But it's a function only in OSX, and not really important one at that. Not all apps even have their own functions they add to the dock menu. I'll give your patch a try!

[JoshPettus]

I should add the only reason a dockmenu would be useful for an app is that most of them don't actually close when their main window is closed and you can open up a new window there. And some apps forgo such a dock menu option and just open a new window when you click on it in the menubar, providing one isn't already open which it would just switch too.. XBoard isn't like this and it quits right a way when the main window is closed. Which I see nothing wrong with. Many games are like this.

[JoshPettus]

Yay the patch worked, now the browse menus don't crash anymore in both menus. Do you want to add a error popup for files that are the wrong filetype?

[JoshPettus]

I think a more useful project would be to try to implement OS10.7-9's fullscreen, but we don't have to tackle it now. I'm sure you have a lot of work with 4.8 and I'm not even sure if it's feasible.

You may remember a while ago I claimed the fullscreen feature had worked with gtk-quartz version of xboard. But what it was instead is a SIMBL plugin , I had put in, called maximizer, which injects code into a running program to implement the full screen feature. At the time I had completely forgotten about it. This hack is system wide, and I'm not really a fan of it.

I had sent an email on to the gtk-osk email list asking about fullscreen implementation. John Ralls answered and said that gtk quartz's fullscreen function is already implemented. and we would need to put in an action for gtk_window_fullscreen(). It's a little different from the cocoa stuff, I have seen it in action in GIMP. My concern is that, A) its different from cocoa apps, B) with it, xboard won't probably won't be able to scale itself properly in manner that looks good, and C) xboard won't be able to take it's supporting windows with it. (Eval graph, moves history, ect..) But we can always try that method to see how it is.

What i'd prefer is the cocoa method which puts this in the top right corner of the window



And pressing would give us this (providing extra windows aren't top level)



John said that to get that button, gtk did not support the call call [NSWindow setCollectionBehavior:] which was also a level below which the OSX integration library operated. Instead, we would have to put it into the xboard code ourselves.
To do this, he said, we would need to add -xobjective-c or -XObjC to CFLAGS in the Makefile.am and we could get an NSWindow* with with gdk_quartz_window_get_nswindow()

I think it would be a nice touch. I like it as it clears the screen of distractions, but it is certainly not crucial. The Hide function does the same, providing my desktop isn't filled with junk

If it helps, here is apples documentation on the NSWindow Stuff
https://developer.apple.com/library/mac ... enApp.html

[hgm]

Wel, for now I would prefer to stay away of Objective C.

I am now integrating the OS X patches into the master branch; I suppose I could cherry-pick them into v4.7.x once I am ready. I removed the use of strndup, changing it back to the normal strdup we use everywhere else. So I guess the 10.6 patch simplifies to just the 10.6 option in the linker flags.

For now I put all the new code between #ifdef OSX, #endif pairs. This assumes the symbol OSX would be defined during an OSX compile, perhaps through a -DOSX amongst the gcc flags, which the configure would put there when the user request an OSX build through "./configure --with-OSX". I don't know how to do that, however; Arun does the configure stuff, and I will ask him. He should also take care of the extra LDFLAGS being added only during OSX builds.

I wondered about the

#include "gtkmacintegration/gtkosxapplication.h"

You use double quotes there, meaning that the file will be sought from the current directory, and not in a standard place (as it would when using <> as delimiters). Is this really necessary? I noticed that you do use -lgtkmacintegration as linker flag, which would seek the library in a standard place. Wouldn't that mean that it should also be able to find the corresponding .h file in the standard place?

I am still thinking on how we could best solve the xterm patch in InfoProc; this is now inside menu.c, where I would prefer not to have any platform-dependent stuff. (So I guess it is in the wrong place...)

[JoshPettus]

Well, for now I would prefer to stay away of Objective C.

I understand. I wonder why he thought we need it though.

...So I guess the 10.6 patch simplifies to just the 10.6 option in the linker flags.

fine by me. the simpler the better. At the time I had tried replacing it with strdup but i guess there was something else I had to do, or rewrite it

I wondered about the

#include "gtkmacintegration/gtkosxapplication.h"

I guess I meant to use <>. I have no idea why it works as I certainly didn't put it in the current directory. Perhaps GCC is just taking pity on me.

the LDFLAG -headerpad_max_install_names was only needed to relink the dylibs to xboard app places. You don't really need it.

I am still thinking on how we could best solve the xterm patch in InfoProc;

How about move it in next to manProc in xboard.c?