bugGNUstep - Bugs: bug #36586, Submenu displayed in a wrong...


You are not allowed to post comments on this tracker with your current authentication level.

bug #36586: Submenu displayed in a wrong position with menu in-window

Submitted by:  Germán Arias <espectador>
Submitted on:  Mon 04 Jun 2012 01:12:09 AM UTC  
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

( Jump to the original submission)

Sat 29 Jun 2013 06:39:39 PM UTC, comment #8:

This was a problem in Back. Fixed at revision #36765.

Germán Arias <espectador>
Tue 09 Oct 2012 01:22:10 AM UTC, comment #7:



you can read:

"When restoring the position and size of a window, it's important to call QWidget::resize() before QWidget::move(). The reason why is given in the Window Geometry overview."

In the last section at "Window Geometry overview":


you can read:

"X11 provides no standard or easy way to get the frame geometry once the window is decorated. Qt solves this problem with nifty heuristics and clever code that works on a wide range of window managers that exist today. Don't be surprised if you find one where QWidget::frameGeometry() returns wrong results though."

So have an aggressive solution for this problem, does not seems (at least to me) a bad idea. The attached patch is that I did to the fisicalab-0.3.0 binary package. I tested it with other apps, and a value of 2 for GSRedisplayMenu, was enough to solve this problem in all apps where I notice this. Of course this cause an ugly flickering when the main window is launched.

So, what you think about implement something like this? Of course this will be experimental. But is an step to solve this problem. And keep in mind that Qt (with all resources they have) admit that their solutions may not work in some window managers.

(file #26724)

Germán Arias <espectador>
Thu 20 Sep 2012 06:41:00 AM UTC, comment #6:

Also see this Qt documentation:


Germán Arias <espectador>
Thu 20 Sep 2012 12:54:13 AM UTC, comment #5:

The second problem (unable to remove previous menu view), can be solved moving the line:

[wv removeMenuView];

immediately before the line [wv addMenuView: menuView]. I don't know why, but in this way works (maybe runtime stuff).

The first problem (update the menu when the window has been moved or resized by the window manager) is more complicated. First of all, I don't know if we can be informed when the window manager does this. According with this GTK documentation (lasts paragraphs):


the window manager can interfere in our request to move/resize a window. So we should be careful with this. And I think this problem is present when we do very close requests in the time. For example when set the menu, move the window to a new position (in cascade), or set a new size according with the user preferences. Seems like the window manager don't likes that the window changes their frame frequently. And therefore stop these requests.

Germán Arias <espectador>
Sun 16 Sep 2012 11:10:08 PM UTC, comment #4:

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)


if (num == 3)


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.

Germán Arias <espectador>
Sat 30 Jun 2012 05:03:04 AM UTC, comment #3:

Well, I think I found the problem here. All the calls to method -setFrame:display: (or related) don't seems to be executed immediately. All these are postponed until the window manager have ready the window. The only explanation I found to the problem in the image "system1.jpg" in my previous report, is that the window frame is modified while GSWindowDecorationView get the frame, change its size and set the menu. So, when the GSWindowDecorationView finish the resize of the subviews and set the new frame, the window have new dimensions. I think the solution is ensure that, while GSWindowDecorationView set the menu, any other call to -setFrame:Display:, -setFrameOrigin: or -setFrameSize: should be postponed.

Germán Arias <espectador>
Fri 22 Jun 2012 01:49:28 AM UTC, comment #2:

Well, to investigate more this problem, I installed an standalone gnustep system. Ink show the same problem in this system (the problem is random). So I test with fisicalab (current svn). FisicaLab works perfectly with my gnustep installation. But with the standalone installation, the menu show the same problem that Ink (see image standalone1.jpg). Here the problem is present always. If I resize the window, the menu works as expected. If I launch fisicalab again (fisicalab save the window frame), the result is the image standalone2.jpg. With the same problem in menu.

In fisicalab, the saved window frame, is set up in -applicationWillFinishLaunching: with something like:

[window setFrameUsingName: @"Pizarra"];

Moving this line to -applicationDidFinishLaunching: the problem is solved, at least when there is a saved frame. This is with the standalone installation. So, the same application that works perfectly with my gnustep installation, don't work with the standalone system. Now if I use FisicaLab with the change described above, and with my normal gnustep installation, the result is the system1.jpg image. This is weird, I only move one line from -applicationWillFinishLaunching: to -applicationDidFinishLaunching:. If I close the app and then launch again, the window is placed at its default location (no window frame saved). So, could be the problem that at some point the app code call some method to redraw the window while _autoresizes_subviews is set to NO (in GSWindowDecorationView.m)? And maybe this cause a conflict?

(file #26081, file #26082, file #26083)

Germán Arias <espectador>
Wed 06 Jun 2012 05:00:04 AM UTC, comment #1:

Well, I confirm that the submenu isn't using the view of the menu in previous window. And I don't know what is the problem. However I noticed that call -setFrame:display: ensure the correct behaviour of the menu in-window. With a different frame, because if not don't have effect of course. And only if -setFrame:display: is called after -layout in -changeWindowHeight: (GSWindowDecorationView.m). However -layout need know the height of the window to do its work. So one solution is set an intermediate frame before call -layout: (with the correct height) and then set the correct frame with -setFrame:display:.

Germán Arias <espectador>
Mon 04 Jun 2012 01:12:09 AM UTC, original submission:

Using menu in-window run Ink and open new documents as many as possible. At some point you will notice that the menu don't work (don't move or resize the window). Move the mouse cursor above the title bar, and you will see the submenu displayed in a wrong position. See attached image. I think that the problem here is that the submenu is taking as reference the view of the menu of the previous window. But this problem is randomly. Not always occurs at same number of new documents opened.

Germán Arias <espectador>


Attached Files
file #26724:  changes.patch added by espectador (3KiB - text/x-patch)
file #26081:  standalone1.jpg added by espectador (55KiB - image/jpeg)
file #26082:  system1.jpg added by espectador (79KiB - image/jpeg)
file #26083:  standalone2.jpg added by espectador (11KiB - image/jpeg)
file #25974:  menu.jpg added by espectador (10KiB - image/jpeg)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rmottola (Updated the item)
  • -email is unavailable- added by espectador (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-10-23 rmottola StatusNone => Fixed
        Open/ClosedOpen => Closed
    2012-10-09 espectador Attached File- => Added changes.patch, #26724
    2012-06-22 espectador Attached File- => Added standalone1.jpg, #26081
        Attached File- => Added system1.jpg, #26082
        Attached File- => Added standalone2.jpg, #26083
    2012-06-04 espectador Attached File- => Added menu.jpg, #25974

    Back to the top

    Powered by Savane 3.3