Bug 6545 - (int-150319) HildonAppMenu doesn't show when another top level widget is around
: HildonAppMenu doesn't show when another top level widget is around
Product: Desktop platform
: 5.0/(2.2009.51-1)
: x86 Maemo
: Low normal (vote)
: 5.0/(10.2010.19-1)
Assigned To: Alberto Garcia Gonzalez
: hildon-libs-bugs
: patch
  Show dependency tree
Reported: 2009-12-03 16:28 UTC by Luca Donaggio
Modified: 2010-03-24 14:40 UTC (History)
4 users (show)

See Also:

Sample C code to showcase HildonAppMenu behaviour (2.20 KB, text/x-csrc)
2009-12-03 16:45 UTC, Luca Donaggio
Close the menu only when a modal window appears (2.07 KB, patch)
2009-12-10 18:47 UTC, Alberto Garcia Gonzalez


You need to log in before you can comment on or make changes to this bug.

Description Luca Donaggio (reporter) 2009-12-03 16:28:43 UTC
Maemo 5 SDK Final

1. Create a HildonProgram with a HildonWindow and HildonAppMenu
2. Show an undecorated top level GtkWindow somewhere over the HildonWindow and
make it transient for it
3. Click on the HildonWindow title bar

HildonAppMenu should appear

It indeed begins to appear, but it immediatly disappears



It seems to depend from this function inside hildon-app-menu.c from lines 494

static gboolean
hildon_app_menu_find_intruder                   (gpointer data)

It hides the HildonAppMenu if there's another top level widget around.
This prevents an app to have nice-looking, cairo-based, semi-transparent
widgets floating over the application's main HildonWindow.

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:
Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Comment 1 Luca Donaggio (reporter) 2009-12-03 16:45:29 UTC
Created an attachment (id=1658) [details]
Sample C code to showcase HildonAppMenu behaviour

This code creates an HildonProgram, adds an HildonWindow and an HildonAppMenu,
writes something inside a GtkLabel to add a visible background to the main
HildonWindow, creates a transparent, undecorated, pop-up window on top of the
HildonWindow and writes something in it as well.
By clicking on the holdonWindow title bar you can see for a brief moment the
HildonAppMenu appearing, then it disappers.
Comment 2 Claudio Saavedra 2009-12-07 14:05:42 UTC
I'm not sure if this can be fixed anyhow. The use case you describe is sort of
a hack.
Comment 3 Ed Page 2009-12-07 17:37:01 UTC
Unfortunately I have other priorities right now but previously I had issues
running an AppMenu with Dialcentral/ejpi/Gonvert and I wonder if it is related.
Comment 4 Alberto Garcia Gonzalez 2009-12-09 19:01:32 UTC
(In reply to comment #0)
> It seems to depend from this function inside hildon-app-menu.c from
> lines 494 onwards:
> static gboolean
> hildon_app_menu_find_intruder                   (gpointer data)

Yes, that was introduced to fix a race condition when a dialog and a
menu appared at the same time and the whole UI froze.

Many things changed since then (in particular: HildonAppMenu does no
longer use a grab) and this might not be necessary anymore, so it's
definitely worth having a look again.

Thanks for reporting the problem and uploading the test case.
Comment 5 Alberto Garcia Gonzalez 2009-12-10 18:47:22 UTC
Created an attachment (id=1725) [details]
Close the menu only when a modal window appears

Unfortunately we still need to close the menu when a dialog appears
below it, I've just checked and the original problem is still there.

However, I think that checking for modal windows is enough to avoid
that problem and doesn't interfere with other types of windows (such
as the one in your example).

I'll test this solution a bit more and try to have it published.

Thanks again for reporting the problem.
Comment 6 Alberto Garcia Gonzalez 2009-12-10 18:52:16 UTC
Adding patch keyword and alias for the internal bug
Comment 7 Alberto Garcia Gonzalez 2010-01-11 11:56:59 UTC
This has been fixed in libhildon 2.2.10-2+0m5
Comment 8 Andre Klapper maemo.org 2010-01-11 15:49:54 UTC
This has been fixed in package
libhildon 2.2.10-2+0m5
which is part of the internal build version
(Note: 2009 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
Comment 9 Andre Klapper maemo.org 2010-03-15 20:54:12 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).