OSX Xboard 4.7.2 .app

[JoshPettus]

I think it works. I put it before ready in main and after the g singal connect, When I open it immediatly the board renders.

once i install it into the app the board stops rendering so I think it may be my dylib bundler program.

Code: Select all

install_name_tool: changing install names or rpaths can't be redone for: /Users/joshua/desktop/xboard.app/Contents/MacOS/xboard-bin (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)

Not sure why, it has always worked before. I'll need to figure out what's wrong.

[edit]
Yah it's not that it

this is

Code: Select all

2013-12-21 15:26:59.415 Xboard-bin[22358:d07] _createMenuRef called with existing principal MenuRef already associated with menu
2013-12-21 15:26:59.417 Xboard-bin[22358:d07] (
	0   CoreFoundation                      0x00007fff9353c41c __exceptionPreprocess + 172
	1   libobjc.A.dylib                     0x00007fff9189ce75 objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff9353c2cc +[NSException raise:format:] + 204
	3   AppKit                              0x00007fff96452d24 -[NSCarbonMenuImpl _createMenuRef] + 62
	4   AppKit                              0x00007fff964526fa -[NSCarbonMenuImpl _instantiateCarbonMenu] + 143
	5   AppKit                              0x00007fff96450ec2 -[NSApplication finishLaunching] + 876
	6   Xboard-bin                          0x000000010007bff8 GenericPopUp + 10454
	7   Xboard-bin                          0x0000000100066014 BoardPopUp + 680
	8   Xboard-bin                          0x0000000100074bf0 main + 2899
	9   Xboard-bin                          0x0000000100000fd4 start + 52

[JoshPettus]

Ok It does get rid of the second apple menu. That error pops up because of the whole problem and the fake menu doesn't hide it.

It crashes because dylibbunder or rather the install_tool that links libraries doesn't seem to like the binary at one point. I need to figure at what point that is.

[JoshPettus]

Gah, this is really weird. Something in the new code in xboard.c is causing it. Thing is xboard would still run, despite the "failier" up until the point where I added that menu line, which is where everything fell apart. There is nothing in the terminal about missing libraries and xboard "launches". So I really don't get it. Either way even with the dummy menubar we still get that _createMenuRef stuff in the terminal. So that isn't ideal. Man this is like pulling teeth... The closer we get, the more nothing works the way it should. I'm not sure what we can do.

[JoshPettus]

Well this is really weird, I may have found the culprit as far as install name tool is concerned. Its the suppression line in main ()

Code: Select all

//    suppress = (argc == 1 || argc > 1 && argv[1][00] != '-'); 

and the new

Code: Select all

  gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(gtk_menu_bar_new())); 

that really breaks the camel's back. I think it stops the linking between libraries further up

Why lib install tool cares is beyond me and xboard doesn't throw up any errors regarding this. Eg Lib A cant find Lib B. Else I could do it manually trying thoes suggested arguments, (god forbid as that would take all day) It's just a mess.

[hgm]

Well, from the error message it seems that the trick with the dummy menu is not allowed. Apparently it is not possible to replace one menu (the dummy) by another ("_createMenuRef called with existing principal MenuRef already associated with menu").

This is strange, because there seems to be no function to remove an existing menu bar. So how would they want to allow an application to change menu bar? Should it change all menu buttons on it?

Perhaps it would work to first assign an empty menu bar in a very early stage (i.e. the dummy), but in stead of creating a new menuBar in BarBegin, filling it with buttons, and then try to use it to replace the dummy at BarEnd, just fill the dummy with the buttons. For that we would have to let BarBegine not create the new menu bar, but take the dummy one, which we have to communicate from xboard.c to xoptions.c. For that purpose, define a variable

GtkWidget *dummyBar;

just above "int suppress;" in xboard.c. Then change the following line in main() a bit to give it a value:

Code: Select all

gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(dummyBar = gtk_menu_bar_new()));

Then in xoptions,c, above "int GenericPopUp(...)", put

Code: Select all

extern GtkWidget *dummyBar;

so that it is know there. In the BarBegin case of GenericPopUp() then comment out abd add:

Code: Select all

// menuBar = gtk_new_menubar_new();
menuBar = dummyBar; // ADD

(This uses the dummy bar in stead of creating a new one.) Finally, comment out the gtkosx_application_set_menu_bar(theApp); in the BarEnd case. (Because this was already done in main() for the dummy bar.)

No idea if this will work, or if OSX will throw up new objections when we add menu buttons to a bar afterwards. But I think it is worth a try.

[JoshPettus]

oh how do we declare "theApp" in xboard.c?

[hgm]

It was already declared there. Only "dummyBar = " was inserted in the existing line, in the code block near the top of main().

[JoshPettus]

dang still throws that error.

Code: Select all

2013-12-21 17:25:17.647 Xboard-bin[31053:d07] _createMenuRef called with existing principal MenuRef already associated with menu
2013-12-21 17:25:17.649 Xboard-bin[31053:d07] (
	0   CoreFoundation                      0x00007fff9353c41c __exceptionPreprocess + 172
	1   libobjc.A.dylib                     0x00007fff9189ce75 objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff9353c2cc +[NSException raise:format:] + 204
	3   AppKit                              0x00007fff96452d24 -[NSCarbonMenuImpl _createMenuRef] + 62
	4   AppKit                              0x00007fff964526fa -[NSCarbonMenuImpl _instantiateCarbonMenu] + 143
	5   AppKit                              0x00007fff96450ec2 -[NSApplication finishLaunching] + 876
	6   Xboard-bin                          0x000000010007bff9 GenericPopUp + 10415
	7   Xboard-bin                          0x0000000100066028 BoardPopUp + 680
	8   Xboard-bin                          0x0000000100074c18 main + 2919
	9   Xboard-bin                          0x0000000100000fe8 start + 52
)

[Edit]
I think I'm going to call it a night for now, I bet it's getting late. Dang we are so close and more shenanigans rear their head.
If it would just take the app ready from both places we wouldn't be in this mess. It's like pick which one you want to work, but you can't have both.

[hgm]

OK, good night!

[hgm]

I was looking at the GIMP code a while ago when we were messing with the signal connect. They had a similar problem where they couldn't have ready near it so they had some kind o hack with their event handler.
...
could that be useful to us?

I overlooked this post before, and I think it could be useful to have a closer look at this. The part you posted, however, only shows the g_signal_connect, and the routine that is connected to handle the signal. Wile the 100-dollar question is not how the signal is handled, but what trick they use to make that this routine to handle the is invoked in the first place, without doing the early gtkosx_application_ready that spoils te menu bar. And I guess this is done in the code that you represented by "...".

So could you either post that code, or post a link to the place were I can get it, if it is too big? I tried looking in the Debian source package for GIMP, but the word "NSApplicationOpenFile" does not seem to occur in it.