Follow-up Comment #4, bug #36586 (project gnustep):
Well, I finally found the problem here. There are two problems.
First, GSThemeMenu only update the menu if the NSMenu has changed, but not if
the position or size of the menu has changed (-setMenu:forWindow:). In fact
this method is executed only once time. Further calls returns.
Second, the GSWindowDecorationVIew can't remove any previous menu view.
Currently this is not a problem, because the menu is updated only once time
(first problem described above). The method -removeMenuView:, can't remove the
menu view because it does the search in the wrong NSView.
You can test this easily, in GSThemeMenu declare a variable "num":
static int num = 0;
Then, instead the check:
if ([window menu] == menu)
return;
Write:
if (num == 3)
return;
num++;
We will allow two updates. Compile and run an aplication (menu in-window of
course). For example Ink. You will see two menus, the previous menu has not
been removed.
If I write:
NSLog(NSStringFromRect([v frame]));
in while loop of -removeMenuView, I don't see any NSMenuView object. Where was
added this? In the case that it has been added in the wrong view. I guess that
NSToolBar objects are added also in the wrong view.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?36586>
_______________________________________________
Mensaje enviado vía/por Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
