Re: Issue in GtkDialog Button Press Handler

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-02-05 at 23:12, Rajkumar Sivasamy wrote:
> Hi,
> 
> Came across a general problem with GtkDialog:
> 
> 
> Test case:
> ---------
> a) Open a large file (Approx. 10K of lines) in Gedit
> b) Open the Find Dialog (Ctrl + f)
> c) Enter a junk string that is not present in in file (so that the
> search engine scans the entire doc)
> d) Click "find" in the search dialog, gedit won't respond until the
> search is finished, also pls. notice that the keyboard is _not_ grabbed
> and can be used when the search is progressing
> 
> Now: Repeat the search by hitting the "Return Key". Our keyboard will be
> grabbed until the search is complete and you will not be able to use it
> in the mean time.
> 
> This is common for GtkDialogs which runs a background operation for a
> key response and its effect is very severe in certain cases when the
> call back for button press pops up an UI like GtkEntry as the user can't
> use the keyboard as its grabbed.
> 
> 
> Analysis:
> --------
> I think the reason being when a button in the dialog is pressed the
> keyboard is grabbed in gtkbutton.c: gtk_real_button_activate() using
> gtk_grab_add() & gdk_keyboard_grab() and is released only in
> gtk_button_finish_activate() using gtk_grab_remove() &
> gdk_display_keyboard_ungrab().

But the ::clicked signal is not emitted until the end of 
gtk_button_finish_activate(), after gdk_display_keyboard_activate().

Perhaps the problem is that the X request queue doesn't get flushed.
Does it fix the problem if you put a call to gdk_display_sync()
after the call to gdk_display_keyboard_ungrab() in
gtk_button_finish_activate()?

> In the time gap (say KBG) between gtk_real_button_activate() and
> gtk_button_finish_activate() the keyboard will be arrested and could not
> interact with other widgets of the application. If the call back for
> button press pops up a new UI which requires keyboard interaction then
> the above keyboard_grab will not allow the user to interact with the new
> GUI as its in the time period KBG. This effect is very severe in the
> cases when the button_pressed call back pops up a new UI as said above
> and the only way to release the keyboard grab is terminating the
> application.

This doesn't sound possible. Do you have an example of this? If you pop
up a new UI, I think queued X requests will get flushed and the grab
will be released.

Regards,
                                             Owen