Re: Issue in GtkDialog Button Press Handler

[Rajkumar Sivasamy <rajkumar siva wipro com>]

Hi Owen,

Thanks a lot for the pointers.

> > 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()?

Yes, adding a gdk_display_sync() after gdk_display_keyboard_ungrab()
flushes the requests queued up and releases the grab on the keyboard.

In cases when the time interval say 'TP' between
gtk_real_button_activate() and popping up a new UI is large for an app.
then with the current setup (without gdk_display_sync()) users cannot
access any of the desktop component with the keyboard in the time period
'TP'. 

Owen, will it help if I log a bugzilla entry and put up a patch
(+gdk_display_sync()) for gtkbutton.c as suggested ?



> > 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.

Yes, on further analysis I found that if a new UI is popped up by the
app. in KBG then the queued X requests are flushed and the grab is
released. 


But: I have a network-passwd-daemon and gedit running as two _separate_
process, when gedit tries to open a file from URI ("Gedit->File->OPen
Location->(GtkDialog)Open from URI->(GnomeEntry)Key in an internet
site->Hite return Key") the network-passwd-daemon will prompt a UI for
the user to enter the username/passwd and it falls in the time period
'TP' stated above. Since the new UI popped up is from a separate process
the grab on the keyboard by the (GtkDialog)Open from URI is not released
and the user can't access the UI popped up by the daemon through his
keyboard.

Adding gdk_display_sync()in gtk_button_finish_activate() fixes the
issue.


Thanks,
Raj.