I thought I had the gtk2 version of the library. On macports, gtk3 is it's own variant. What I had actually installed was the no python variant on macports as something was screwy with the macports python install. I'll have to start from a clean slate to make sure I'm using the normal gtk2 version. See if that makes a difference.
Somewhere along the way we lost all the dividers in the menu, I'll go through everything again later tonight and see where that was.
OSX Xboard 4.7.2 .app
Moderators: hgm, Rebel, chrisw
-
- Posts: 27825
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
Perhaps the example is just obsolete / crappy. In the detailed description of the available functions they are not mentioned at all. In stead I see
gtkosx_application_insert_app_menu_item()
This is claimed to both remove the mentioned item from the GTK menu, as well as insert it in the OSX App menu. You must specify with a third parameter where.
Perhaps you should try to use that.
gtkosx_application_insert_app_menu_item()
This is claimed to both remove the mentioned item from the GTK menu, as well as insert it in the OSX App menu. You must specify with a third parameter where.
Perhaps you should try to use that.
Code: Select all
} else entry = gtk_separator_menu_item_new();
gtk_menu_append(GTK_MENU (menu), entry);
if(!strcmp(msg, "About XBoard")) // ADD 3 lines
gtkosx_application_insert_app_menu_item(
g_object_new(GTKOSX_TYPE_APPLICATION, NULL), entry, 0);
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
Well it compiled, at least so we are using the right routine, but it didn't move the about Xboard
I also found out where we lost all the menu separators. It was early on when we decided to comment out the line hiding the GTK menubar.
This is what I have:
Can we change that somehow so we can have our cake and eat it?
I also found out where we lost all the menu separators. It was early on when we decided to comment out the line hiding the GTK menubar.
This is what I have:
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);
top--;
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;
-
- Posts: 27825
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
I don't understand that at all. That line should only control whether the menu bar appears in the window, or not. The separators are created in an entire different place, where the PopUps are created, at a time when we have not even gotten to the commented line yet.
I have developed a theory as to why we could not hide the menu bar. Near the end of GenericPopUp() there is a line
Probably this undoes the effect of any earlier hides of sub-elements of the dialog. So hiding the menu bar would only be effective if we do it after that. So I suggest to add a line there:
and uncomment the table_attach line. (The if(menuBar) should make sure this new line is only executed in dialogs that indeed contain a menu bar.)
I have developed a theory as to why we could not hide the menu bar. Near the end of GenericPopUp() there is a line
Code: Select all
gtk_widget_show_all( dialog );
Code: Select all
gtk_widget_show_all( dialog );
if(menuBar) gtk_widget_hide( menuBar ); // ADD
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
That worked! Great job!
Let me know when you come up with a solution for the about xboard.
I've tried quite a few iterations on your code with catastrophic results
Let me know when you come up with a solution for the about xboard.
I've tried quite a few iterations on your code with catastrophic results
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
oh darn, turns out moving the menu up had an unforeseen consequence
too much vertical space.
can we do anything about that?
too much vertical space.
can we do anything about that?
-
- Posts: 27825
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
I think I figured out why the separators disappeared. That gtk_widget_show_all at the end of GenericPopUp() makes everything in the window visible. This is why we could not hide the menu bar; individual hide / show of the components done before is overruled by the show_all. But when we take the menu bar out of the window by commenting that table_atach line, it is no longer subject to this show_all. So it becomes crucial that the indivisual components are shown.
Now for the separators this is not the case. There is an (originally redundant) gtk_widget_show() for text menu items, but if the else-part is executed to create a separator, this is skipped:
It should be changed to
so that it both applies to separators and normal menu items.
Then the tabe_attach line in the BarEnd case can be commented out again (and the extra top--; added), and the if(menuBar) gtk_widget_hide after the gtk_widget_show_all can be deleted again. This should make the problem with the extra space disappear, as the menu bar now would never be put in the window in the first place.
As to the "About" menu item. Did this gtkosx_application_insert_app_menu_item() not work?
Now for the separators this is not the case. There is an (originally redundant) gtk_widget_show() for text menu items, but if the else-part is executed to create a separator, this is skipped:
Code: Select all
if(strcmp(msg, "----")) { //
...
gtk_widget_show(entry);
} else entry = gtk_separator_menu_item_new();
Code: Select all
if(strcmp(msg, "----")) { //
...
} else entry = gtk_separator_menu_item_new();
gtk_widget_show(entry); // MOVED
Then the tabe_attach line in the BarEnd case can be commented out again (and the extra top--; added), and the if(menuBar) gtk_widget_hide after the gtk_widget_show_all can be deleted again. This should make the problem with the extra space disappear, as the menu bar now would never be put in the window in the first place.
As to the "About" menu item. Did this gtkosx_application_insert_app_menu_item() not work?
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
Exellent! That all worked and looks great!
--
Yah gtkosx_application_insert_app_menu_item() didn't move the about item.
--
Yah gtkosx_application_insert_app_menu_item() didn't move the about item.
-
- Posts: 27825
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
Perhaps this routine only works after the entire menu bar has been created, and not while we are still in the process of building the individual menus before assigning them to a button on the main bar (or before elevating that main bar to OSX status. If so, it would haveto be called from the code at BarEnd, just before the gtkosx_application_ready().
The trick is how to still know what 'entry' was, that has to be passed to the insert call.The CreateMenuPopup() routine eventually stores this in helpMenu[8].handle (the About item is the 8th item in the help menu). So we could call
gtkosx_application_insert_app_menu_item(theApp, GTK_MENU_ITEM(helpMenu[8].handle), 0);
there. The problem is that helpMenu might not be known at that point. (Because the helpMenu table is in another file, menus.c.) If you get a compile error complaining about this, you could add
extern MenuItem helpMenu[]; at the beginning of the block of new code enclosed by {}:
This is a bit ugly, because if we would ever change the helpMenu table, the About item might not stay number 8 (and I hope I did not mis-count it to begin with...). But for now it should do.
The trick is how to still know what 'entry' was, that has to be passed to the insert call.The CreateMenuPopup() routine eventually stores this in helpMenu[8].handle (the About item is the 8th item in the help menu). So we could call
gtkosx_application_insert_app_menu_item(theApp, GTK_MENU_ITEM(helpMenu[8].handle), 0);
there. The problem is that helpMenu might not be known at that point. (Because the helpMenu table is in another file, menus.c.) If you get a compile error complaining about this, you could add
extern MenuItem helpMenu[]; at the beginning of the block of new code enclosed by {}:
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);
top--;
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[]; // ADD if needed
gtk_widget_hide (menuBar);
gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(menuBar));
gtkosx_application_insert_app_menu_item(theApp, GTK_MENU_ITEM(helpMenu[8].handle), 0); // ADD
gtkosx_application_ready(theApp);
}
break;
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
That worked, the compiler did complain so I had to add in that line.
I also deleted the old passage for good measure
And another thing rears it's head.
We have to get rid of the extra separator under bug report in the help menu that was once above the About Xboard.
I also deleted the old passage for good measure
And another thing rears it's head.
We have to get rid of the extra separator under bug report in the help menu that was once above the About Xboard.