Re: Issue in GtkDialog Button Press Handler

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-02-07 at 01:37, Rajkumar Sivasamy wrote:
> 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 ?

Please do file a bug report; although it isn't a very common problem
is certainly one that people will run into occasionally, and it
would be nice to work around it.

Note that gdk_display_sync() is overkill, we don't actually need
to do a round trip to the server and make sure all our requests
have been handled. All we need to do is flush our outstanding
requests to the server. (See the man page for XFlush(), as
compared to XSync())

So, I might prefer to add gdk_display_flush() and fix it right
for GTK+ HEAD rather than putting in approximate fix now.

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

Note that as a workaround, you can easily call gdk_display_sync() as
the first thing in the ::clicked signal handler.

Regards,
                                         Owen