On Sun, 2010-02-14 at 04:09 +0100, ext Evan JIANG wrote: > Thank you for your reply. > Since I'm on travel now, I may could only try it some days later. > > I guess it's cause by the browser and hildon-desktop called some > matchbox API directly, that > maybe some MB APIs could hide the window and the window can not be > shown again with GTK APIs.
No, there are no Matchbox(2) APIs used by applications. (The API is not even available at all because the libmatchbox2 library is statically linked to hildon-desktop, so no application is able to dynamically link to it.) My guess about your "ghost window" is that the X window stacking does not match what the compositor shows on the screen. So it could be a bug in hildon-desktop, or it could be some unsupported window type (that's why I asked for xprop and xwininfo outputs). > I found everything works well with FireFox borwser for Maemo. That is interesting... Have you tried the N900 browser in fullscreen mode, does it work then? > Here I could give more details about the window lifecycle. > There's a scim-gtk-panel daemon which will auto start when system startup. > When the daemon starts, it will create a winodw, and hide it immediately. > Everytime when the input method need to show the input window, it will send > command to the daemon to show the input window and move it to the front. > When the inputing is done and edit field loses the focus, the input window > will > be hidden by calling "gtk_widget_hide" This should work if the window is supported by the window manager (to see that I need the xprop & xwininfo outputs or a test program from you). > This design works all right on most of PC Desktop Linux. As I said, > it also works > well for most applications on Maemo, except browser. In the Browser > application, > when the input window is showing, and I click on other places to close > the window, > the window won't show again with "gtk_widget_show_all". > > My current workaround is, when the input window need to be hidden, I > will destroy > the window, and next time when it need to be shown, I will create the > window again. > With this workaround, it works just OK now. But, the performance is > much worse than > before, since creating and destroying the window take longer time. This workaround should not be necessary. We have many such windows, for example the "Select Connection" dialog that you use to select connection to the Internet. It sounds like the window type is confusing to the window manager and it does not behave right in this case. -Kimmo > > Best regards, > Evan JIANG > 2010/2/12 Kimmo Hämäläinen <kimmo.hamalai...@nokia.com>: > > On Sat, 2010-02-06 at 16:53 +0100, ext Evan JIANG wrote: > >> Hi all, > >> I'm developing an input method for N900. > >> The main window is not full screen, and looks like this: > >> http://www.evan129.com/wp-content/uploads/2009/12/20091225_d151774f028f00e741aecdywcKr7OnKn.png > >> It works well in most of times. But in browser application, it's a > >> bit strange. > >> > >> As you can see, there are some buttons in the panel, users can > >> press the buttons to choose the words. In browser application, > >> when users pressed the button, the event will go through my window to > >> the browser. Then because of the press location is not in the same > >> edit field, the edit field will lose the focus. > >> > >> I may not explained it clearly. Let me give an easier understanding > >> example. If the window is in the top of screen, covered the title bar, > >> then when I press the button on the left-top > >> corner, it will show the application switch window. That means, the > >> press event go through my window, and handled by the app swithcer > >> button. > > > > What's the output of these commands for your window: > > > > xprop -id <your window> > > xwininfo -id <your window> > > > > These command line tools can be found from x11-utils package. > > > > -Kimmo > > > >> > >> These are the only 2 places I found that could receive my press event. > >> But in all other places, I didn't find this happening. > >> > >> My panel is created with gtk_window_new (GTK_WINDOW_POPUP); > >> And the buttons are created by gtk_button_new();. I use > >> g_signal_connect to receive the "clicked" event or > >> "button-press-event" event. > >> > >> Does anyone have any idea about that? > >> > >> Best regards, > >> Evan JIANG > >> _______________________________________________ > >> 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
