OSX Xboard 4.7.2 .app

[JoshPettus]

This is an easy to install package for Mac users so they don't have install macports, gtk libraries, all amounting to hundreds of megabites, all under gtk running in native quartz.

it has to be crosscompiled for earlier systems if you are compiling on a later one, or it won't work on those earlier systems. This includes the GTK2, librsvg, cairo, etc libraries

Besides there is a lot of good from porting a unix app over to a native OSX app. Usability if nothing else.

[JoshPettus]

Gah, just as I thought, macports wasn't setup properly, If the 10.6 beta package works, great, but I doubt it will. I have to re-setup macports. I'm pretty darn certain I'm on the right track though.

[JoshPettus]

Another attempt at an xboard.app with 10.6 support. This time I'm sure the libraries bundled with it are 10.6.

Again, anyone please let me know if it works on any system 10.6-10.8 and see if polyglot,fairymax,fruit,timeseal,timestamp all work as well. these are located inside the bundle under /Contents/Resources/bin

https://www.dropbox.com/s/r1l90js66i38y ... .6beta.dmg

[JoshPettus]

I am told it works!

[JoshPettus]

It would be nice to get OSX's native menu bar working. That way the board would take up a little less screenspace, and make it look like the native mac app it is. Unfortunately if this entire thread has been any indication, I am no coder.

I'm hoping that someone with experience with gtk could make a patch to patch in gtk's osx integration with the GtkOSXApplication library. Currently the native menu bar is basically just a place holder (even quit doesn't function!) Of course we need to take in to account the normal place where the quit and "About Xboard" should go in the "Application" Menu and not in the File/Help menus respectively

[JoshPettus]

This will be essential to anyone who wants to give it a try

http://gtk-osx.sourceforge.net/gtk-mac- ... ation.html

[hgm]

Perhaps I can contribute some explanation on how it works in XBoard now. The GTK-OSX examples in the link you give assume that the UI is described in some .xml file. This is not how XBoard works. There the UI is described by tables of initialized data, in a widget-set-independent format, so that it can be shared by the Xaw and GTK version. For each widget set there is separate code (in xaw/xoptions.c or gtk/xoptions.c) to interpret these tables, and do the necessary calls to the widget-set library to create the UI according to the table description.

In XBoard only the main window has a menu bar. The main window is described in the table mainOptions[] in dialogs.c, and in particular the menu bar is described by a line in this table with a "BarBegin" Option, then one line for each menu with a "DropDown" Option, and finally a line with a "BarEnd" Option. These BarBegin / DropDown / BarEnd are then cases in the routine GenericPopUp (in gtk/xoptions.c) that interprets the table.

The BarBegin case just calls gtk_menu_bar_new() to create the menu bar, and then specifies it as visible with gtk_widget_show(). The DropDown case is more elaborate: it not only has to create a menu button, make it visible, append it to the menu bar, but also has to prepare the menu that should become visible when the button is pressed (which is described in a table in menus.c, which is referred to in the DropDown line of the mainOptions table), for which it calls the subroutine CreateMenuPopup (also in gtk/xoptions.c). BarEnd finishes this proces by finally placing the completed menu bar in the window with gtk_table_attach(). (The window is a table of widgets.)

At the end of all this, and processing of all other Options in the mainOptions table by GenericPopUp(), a complete GTK window has been created. Similar to what would be the case after invoking gtk_ui_manager_add_ui_from_file() in the GTK-OSX example. That example then continues with:

Code: Select all

  menubar = gtk_ui_manager_get_widget(mgr, "/menubar");
  gtk_widget_hide (menubar);
  gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(menubar));

I.e. it request the ID of the menu bar (which in XBoard's GenericPopUp() would already be available under the name 'menuBar'), and then uses gtk_widget_hide() on it to make it invisible. I suppose this is a kludge to get rid of it inside the main window, without actually removing it alltogether from the GTK UI construction. Then it would call gtkosx_application_set_menu_bar() to pass the menu bar that was created in the pure GTK way to the OSX App, which presumably would transform it into a native OSX menu bar. Snag is that 'theApp' should be known first, before you can do that. But the second line of the example shows how to do that.

So perhaps all that is needed is to add a few lines at the end of the BarEnd case in GenericPopUp(), to make it:

Code: Select all

  case BarEnd:
    top--;
    gtk_table_attach(GTK_TABLE(table), menuBar, left, left+r, top, top+1, GTK_FILL | GTK_EXPAND, GTK_FILL, 2, 1);

    if(option[i].target) ((ButtonCallback*)option[i].target)(boxStart); // callback that can make sizing decisions
    {
      GtkosxApplication *theApp = g_object_new(GTKOSX_TYPE_APPLICATION, NULL);
      gtk_widget_hide (menuBar);
      gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(menuBar));
    }
    break;

to likewise transplant the GTK menu bar to OSX. Probably you would have to #include an extra, GTK-OSX-specific .h file at the beginning of gtk/xoptions.c to make the gtkosx_... routines known to the compiler.

Not sure if enabling / disabling of the menu items would still work after that, however. But if it works, it would be a start. You can always start to re-organize the menu tables in menu.c afterwards.

[Edit] Oh, and you might also have to add a

Code: Select all

      gtkosx_application_ready(theApp);

at the end of the extra code.

[JoshPettus]

Thank-you very much for your help! I was studying the gimp code in comparison, and that makes a lot of sense. At least lets me know all the work that would need to be done. But I fear when it comes to code, I don't even know the basics. I'll keep poking at it though in hopes that I'll learn something, but I doubt I'll get far to make something functioning. :\

[JoshPettus]

Boy I should really take the time to read your posts more carefully. You were giving me the answer right there

So I added in the extra code in gtk/xoptions
on the top

Code: Select all

#include "gtkmacintegration/gtkosxapplication.h"

and

Code: Select all

  case BarEnd:
    top--;
    gtk_table_attach(GTK_TABLE(table), menuBar, left, left+r, top, top+1, GTK_FILL | GTK_EXPAND, GTK_FILL, 2, 1);

    if(option[i].target) ((ButtonCallback*)option[i].target)(boxStart); // callback that can make sizing decisions
    {
      GtkosxApplication *theApp = g_object_new(GTKOSX_TYPE_APPLICATION, NULL);
      gtk_widget_hide (menuBar);
      gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(menuBar));
      gtkosx_application_ready(theApp);
    } 
    break; 

It almost compiles save for a minor issue with undefined symbols

Code: Select all

Undefined symbols for architecture x86_64:
  "_gtkosx_application_get_type", referenced from:
      _GenericPopUp in xoptions.o
  "_gtkosx_application_ready", referenced from:
      _GenericPopUp in xoptions.o
  "_gtkosx_application_set_menu_bar", referenced from:
      _GenericPopUp in xoptions.o

I guess I'm missing something basic

[hgm]

Well, these are the names of routines that are supposed to be in this GTK-OSX library. Probably a linker flag is needed to instruct the linker to search that library.

I guess this should be done in Makefile.am (from which automake will then create the Makefile), on the line starting with xboard_LDADD . You would have to add the name of the library, most likely between the -lm and the @FRONTEND_LIBS@. (The latter symbolizing the GTK library, which ./configure will figure out where to find it on your system.) You will have to figure out where that library is, and how it is called. Probably a .a file; just mention its path name including the .a suffix.