On Wednesday 27 of July 2005 20:12, Billy Biggs wrote: > If the app asks for focus to be given to a button, and we don't think > the window with the button has focus, we call gdk_window_focus(). This > is what happens when a new dialog is opened: we haven't yet got the > event from GTK+ to tell us that the dialog has focus.
Qt has actually two independent focuses - it has QWidget::setFocus() and QWidget::activateWindow(), first one just setting the internal focus inside one toplevel window, the other one causing window activation and changing the X focus. If you want to focus something in a dialog, just setFocus() does the job, assuming the window also has or will get the X focus. QWidget::activateWindow() is rarely used, as it means fighting the window manager policy. No idea how Gtk handles this, but I'd expect something similar. > > To fix it, I'd have to store in the toolkit something that says "I > just opened this dialog, focus will be going over there, so optimize > this case". This code is tricky. When is the flag cleared? Consider > an app that opens two dialogs, one a main wizard, and one a context > sensitive help window, and it wants focus to be in the main wizard. > It's clearly easier and safer from my point of view to always call > gdk_window_focus() whenever the app is asking focus to go to a widget > and I haven't yet got the events to tell me that it's likely already > there. -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
