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

[Germán Arias]

URL:
<http://savannah.gnu.org/bugs/?36586>

Summary: Submenu displayed in a wrong position with menu
in-window
Project: GNUstep
Submitted by: espectador
Submitted on: dom 03 jun 2012 19:12:09 CST
Category: Gui/AppKit
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

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.



_______________________________________________________

File Attachments:


-------------------------------------------------------
Date: dom 03 jun 2012 19:12:09 CST Name: menu.jpg Size: 10kB By:
espectador

<http://savannah.gnu.org/bugs/download.php?file_id=25974>

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36586>

_______________________________________________
Mensaje enviado vía/por Savannah
http://savannah.gnu.org/

[Germán Arias]

Follow-up Comment #1, bug #36586 (project gnustep):

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]

Follow-up Comment #2, bug #36586 (project gnustep):

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)
_______________________________________________________

Additional Item Attachment:

File name: standalone1.jpg Size:55 KB
File name: system1.jpg Size:79 KB
File name: standalone2.jpg Size:11 KB

[Germán Arias]

Follow-up Comment #3, bug #36586 (project gnustep):

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]

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.

[Germán Arias]

Follow-up Comment #7, bug #36586 (project gnustep):

Here:

http://doc.qt.digia.com/4.7-snapshot/mainwindows-application.html

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":

http://doc.qt.digia.com/4.7-snapshot/application-windows.html#window-geometry

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)
_______________________________________________________

Additional Item Attachment:

File name: changes.patch Size:2 KB

[Germán Arias]

Follow-up Comment #8, bug #36586 (project gnustep):

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

[Riccardo Mottola]

Update of bug #36586 (project gnustep):

Status: None => Fixed
Open/Closed: Open => Closed

_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?36586>

_______________________________________________

Message sent via/by Savannah
http://savannah.gnu.org/