GNOME Bugzilla – Bug 86339
mini-commander doesnot have a cursor
Last modified: 2009-08-15 18:40:50 UTC
I tested with 19th June build on Sparc Solaris 5.9 64 bit. I am not able to get the cursor on mini-commander. steps to reproduce: 1. Add minicommander to panel by selecting add to panel ->utility -> Command line. 2. mini-commander comes up on the panel. 3. type any excutable command, say 'xterm', but u never find a cursor on mini-commander.
This works fine here and has been reported repeatedly in the past and marked fixed. [See bug 74511 and duplicates.] What are the build details on this bug?
I'm seeing this problem and i think the problem is in gtk+. I had a build of the GNOME sources on Jun 5th and Jun 7th. Both the builds had gtk+ from CVS HEAD. On the Jun 5th build, this problem is NOT seen and on Jun 7th this problem is seen. So, I tested the Jun 7th build with only gtk+ checked out with Jun 5th tag and observed that the problem disappears. Hence the conclusion that the problem is actually in gtk+. The Jun 5th build used a date tag of "Jun 05 18:00:00 GMT" for gtk+ The Jun 7th build used a date tag of "Jun 07 18:00:00 GMT" for gtk+
This is with gtk HEAD?
Louie: Yes, gtk+ is from HEAD.
*** Bug 86980 has been marked as a duplicate of this bug. ***
A standalone test case not involving the panel would be useful; perhaps someone could try and make a patch to modify tests/testsocket to exhibit this bug. (I don't run GTK+ HEAD currently for my GNOME desktop, which, among other things makes debugging something like this in the panel hard.)
I have added the keyword keynav as bug 86980 which has been marked as a duplicate of this bug reports that focus indication is not drawn for out-of-process applet.
I do not have a standalone test case yet but I will describe what I have discovered while investigating the problem I described in bug 86890. The reason that the focus indicator is not drawn around an out-of-process PanelApplet is the GTK_WIDGET_HAS_FOCUS(Widget) is FALSE after gtk_widget_grab_widget(widget) is called for the PanelApplet. The reason for this is that window->has_focus is not set for the plug in gtk_window_real_set_focus(). It looks like window->has_focus should be set in window_update_has_focus() but when this function is called window->is_active is FALSE. In testsocket window->is_active is set for the plug when socket_update_active() is called for the socket. When socket_update_active() is called from gtk_socket_add_window() is_active is set for the socket's toplevel window so an XEMBED_WINDOW_ACTIVATE message is sent to the plug. In the panel when socket_update_active() is called for the socket the socket's toplevel window does not have is_active set. A quick look at the code suggests that the signal handlers defined in gtk_socket_hierarchy_changed() should be called when the toplevel window becomes active but it does not seem that the signal handler is called.
Created attachment 9585 [details] [review] Patch which cuases notify handlers to be called
The patch I have attached fixes the symptoms of bug 86980.
The patch above seems to fix the problem reported in this bug too.
Yep, this is a bad "gotcha" in GObject. '-' and '_' can be used interchangeably in signals and property names, but for the notify::PROPERTY signal + detail, the detail needs the canonical '-'. Please commit, thanks.
Change committed
I verified with cvs build dated 6th sept, I am not finding this bug. hence I am closing this.