Mmmm... what I need is a place to put some informations about the image which is currently being displayed by a GtkImage in the main HildonWindow. With the version of mrawviewer currently in extras-testing I did that by painting directly over the image itself, as it is always resized to fit the screen. With the next version I've introduced the possibility to zoom in / out, and I wanted the image informations to remain visible all the time while zooming and scrolling around the image, that's why I thought about a see-through-GtkWindow positioned over the underlying image. Of course that window must stay around until the user explicitly closes it by toggling a filter in the HildonAppMenu. It can't be moved nor resized nor it gets any focus, it's only purpose is displaying some informations.
I'll investigate on how can I make the transparent window a child of the main HildonAppWindow upon its creation as you suggested. Thanks, -- Luca Donaggio 2009/11/13 Kimmo Hämäläinen <kimmo.hamalai...@nokia.com> > On Fri, 2009-11-13 at 10:44 +0100, Hamalainen Kimmo (Nokia-D/Helsinki) > wrote: > > On Thu, 2009-11-12 at 17:21 +0100, ext Luca Donaggio wrote: > > > Thanks a lot Kimmo! > > > > > > At least, now I know what's happening! > > > Now, what to do to solve the problem? If HildonAppMenu behaves like > > > this by design (and if the bug regards only the fact that it is first > > > mapped and then unmapped while it shouldn't be mapped at all), is > > > there a way to create a floating top level widget on top of a > > > HildonWindow or it is somewhat forbidden by the actual implementation? > > > I don't want to continue the development in the wrong direction, maybe > > > it's better if I stop here and redisign my app to not include the > > > "offending" widget and find another way to present the same > > > informations to the user - but let me say that I grew somewhat fond of > > > my transparent-overlayed-unobtrusive-image-details-window! > > > > I think the cleanest (and most risk-free) solution is that you create > > the transparent window as a child window of the main window right from > > the beginning. But I'm not sure how Gtk allows that. Better solution > > would be fixing the WM so that it allows rgba in dialogs, but that can > > be more work... > > I checked the WM support: it seems to be just a matter of commenting out > the offending code in mb-wm-client.c. But if you use a dialog, your > dialog is closed before you can access the application menu, which is > probably what you are trying to do. > > -Kimmo > > > > > -Kimmo > > > > > > > > What do you think? > > > > > > -- > > > Luca Donaggio > > > > > > 2009/11/11 Kimmo Hämäläinen <kimmo.hamalai...@nokia.com> > > > On Wed, 2009-11-11 at 08:28 +0100, Hamalainen Kimmo (Nokia- > > > D/Helsinki) > > > wrote: > > > > On Tue, 2009-11-10 at 16:15 +0100, ext Luca Donaggio wrote: > > > > > I thought it was somewhat related to transparency because > > > doing this: > > > > > > > > > > gdk_window_reparent(win->window,gtk_widget_get_window > > > (GTK_WIDGET > > > > > (mainwin)),300,200); > > > > > > > > > > makes the HildonAppMenu work again at the price of loosing > > > the > > > > > transparency effect (modified code attached). > > > > > > > > Reparenting 'win->window' makes it a child of 'mainwin'. > > > That is > > > > completely different ballgame than the original code, which > > > keeps 'win- > > > > >window' a top-level window (child of the root). When the > > > window is not > > > > top-level, it's not managed by the window manager anymore, > > > but it could > > > > also cause something in Gtk/Hildon (at least I have checked > > > all places > > > > deleting windows in hildon-desktop to no avail). > > > > > > > > > Finally I found the reason for hiding the menu! It's in > > > libhildon > > > function hildon_app_menu_find_intruder. It thinks that the > > > window with > > > the "This is an RGBA window" label is an "intruder" (such as > > > dialog > > > etc.) and closes the menu as soon as it is mapped. This seems > > > like a > > > bug since the menu should not be mapped in the first place if > > > this > > > "intruder" is already there at mapping time. > > > > > > To summarize: this is libhildon bug and hildon-desktop is > > > completely > > > innocent (at last...)! ;) > > > > > > -Kimmo > > > > > > > > > > > > > > -Kimmo > > > > > > > > > -- > > > > > Luca Donaggio > > > > > > > > > > 2009/11/10 Kimmo Hämäläinen <kimmo.hamalai...@nokia.com> > > > > > On Tue, 2009-11-10 at 14:12 +0100, ext Luca > > > Donaggio wrote: > > > > > > Hi Kimmo, > > > > > > > > > > > > I'm sorry to bother you again, but the problem > > > I'm facing is > > > > > not how > > > > > > to get a transparent window, but that if I > > > create such a > > > > > window the > > > > > > HildonAppMenu of its parent HildonWindow doesn't > > > show > > > > > anymore. > > > > > > I (slightly) modified your code to exemplify my > > > situation. > > > > > > > > > > > > > > > Ah, yes, I can see it. Looks like the menu is > > > unmapped > > > > > immediately when > > > > > it is shown. It's weird, I'm not yet sure what > > > unmaps it... > > > > > Now it > > > > > looks like hildon-desktop is not unmapping it, so > > > it could be > > > > > widget > > > > > side problem also. I'll try to find out. > > > > > > > > > > BTW. this problem is not related to the > > > transparency: opaque > > > > > window does > > > > > the same. > > > > > > > > > > -Kimmo > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your time, > > > > > > > > > > > > Luca Donaggio > > > > > > > > > > > > 2009/11/10 Kimmo Hämäläinen > > > <kimmo.hamalai...@nokia.com> > > > > > > Hi, > > > > > > > > > > > > Sorry, took some time, I was busy with > > > some bug > > > > > fixing... I > > > > > > started > > > > > > with the Home applet example and managed > > > to whip up > > > > > a small > > > > > > example > > > > > > (attached) that shows a transparent pop- > > > up window. > > > > > > > > > > > > -Kimmo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > maemo-developers mailing list > > > > maemo-developers@maemo.org > > > > https://lists.maemo.org/mailman/listinfo/maemo-developers > > > > > > > > > > > > > _______________________________________________ > > maemo-developers mailing list > > maemo-developers@maemo.org > > https://lists.maemo.org/mailman/listinfo/maemo-developers > >
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
