GNOME Bugzilla – Bug 627139
gtkfilechooserentry shows completion progress tooltip on first show
Last modified: 2011-01-24 17:52:48 UTC
I have a tabbed UI. One tab contains a GtkFileChooser widget. when I tab to that page the first time after launching the app, I get a tooltip on the top-left saying "Completing ..."). Its comming from ./gtk/gtkfilechooserentry.c:1153: pop_up_completion_feedback (chooser_entry,_("Completing...")); This leads to show_completion_feedback_window() in the same file. I added some printf and they tell me widget: parent 0x9449dc8, visible 1 feedback_x = entry_x + cursor_x + entry_width / 2: 6 = 2 + 4 + 1 / 2 feedback_y = entry_y + (entry_height - req_height) / 2: 35 = 43 + ( 1 - 17 ) / 2 entry_width and entry_height are the allocation and it seems to be 1,1. I have a small patch already for the bogus use of "height" instead of "width" to calculate feedback_x. I'll see if I can figure the actual problem too.
How can it be that a widget is visible 1, mapped 1, realized 1 but its GtkAllocation is { x = -1, y = -1, width = 1, height = 1 } should show_completion_feedback_window() just check for allocation.x==-1 and return?
Created attachment 168084 [details] [review] fix position of tooltip This only fixes the height<->width mismatch for sure. Checking the allocation.x gets rid of the misplaced tooltip, but I am not sure that is the solution. On the other hand, selecting the input field, typing stuff and pressing tab, works and shows a completion status tool tip at the right place.
Review of attachment 168084 [details] [review]: ::: gtk/gtkfilechooserentry.c @@ +1033,2 @@ /* FIXME: fit to the screen if we bump on the screen's edge */ + feedback_x = entry_x + cursor_x + entry_allocation->width / 2; /* cheap "half M-width" */ This *has* to be entry_allocation->height. The comment (cryptically) explains that this size is being used as an inaccurate measurement of the font's em-size. What this line tries to do is feedback_x = left_of_entry + cursor_offset + a_bit_of_space_proportional_to_the_font_size That bit of space is calculated with respect to the height of the entry, which is pretty close to the font size. I'll comment about the rest of the bug in a separate comment. If you want to clarify that comment, feel free :)
The file chooser entry uses the ::focus() method to capture the Tab key, but this seems to be done only for historical reasons. I don't know why this is not done from within a key-press handler. Can you please try implementing a key_press_event handler, somewhat like this: gtk_file_chooser_entry_key_press_event (entry, event) { if (event->keyval == GDK_Tab && !control_pressed) { /* the stuff inside the big if() statement from gtk_f_c_entry_focus() */ return TRUE; } return parent_class->key_press_event (entry, event); } And then just delete gtk_file_chooser_entry_focus().
Created attachment 168135 [details] [review] don't show misplaced tooltip Federico, that works perfect. Is it okay to have the comment fixup in the same patch. Also if this is acceptable, can this go to 2.22 and HEAD?
Review of attachment 168135 [details] [review]: Excellent; I'm glad this solves the problem. It is fine to fix the comment in the same commit. I'd prefer it if instead of connecting to "key-press-event" as a signal, you simply overrode the key_press_event method in class_init(). Could you please make that change? You'll need to call parent_class->key_press_event() in the function instead of returning FALSE, of course.
Created attachment 168175 [details] [review] don't show misplaced tooltip Override class method instead of using a signal handler. Works equally well.
Review of attachment 168175 [details] [review]: Beautiful. Please go ahead and push this :) Thanks for fixing it!
Can you please push to both master and 2.22?
pushed to both branches. Thanks for help!
*** Bug 639842 has been marked as a duplicate of this bug. ***