After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 522514 - gtk_window_present_with_time on KDE does not move window to current desktop
gtk_window_present_with_time on KDE does not move window to current desktop
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
2.12.x
Other All
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on: 482354
Blocks:
 
 
Reported: 2008-03-14 21:41 UTC by Martin von Gagern
Modified: 2014-05-22 01:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin von Gagern 2008-03-14 21:41:03 UTC
The documentation sounds like gtk_window_present_with_time should make the window visible, no matter what. However on KDE 3.5.9 with low focus stealing prevention, if the window to be presented is on another desktop, it is not moved to the current desktop. Without focus stealing prevention, the current desktop is switched to the one containing the window.

I would prefer for gtk_window_present_with_time to move the window to the current desktop, as the window should be displayed in response to an explicit user interaction at the given time.

Other information:
I experienced this issue with Pidgin 2.4.0 list. Clicking on the tray icon usually toggels the visibility of the buddy list. If the buddy list is already open on another desktop, however, it is raised there but still invisible to the user. The official pidgin uses gtk_window_present without a timestamp, so maybe this is still correct behaviour, but even after modifying pidgin_blist_set_visible to pass the result from gtk_get_current_event_time to gtk_window_present_with_time, the issue persists.
Comment 1 Martin von Gagern 2008-04-14 19:56:23 UTC
Bug #482354 sounds like you'd rather have the WM switch visible desktop than the window moved to the current desktop. Seems you agree that's the correct behaviour for most apps, and Pidgin is a corner case, which should better be handled with some "hide/show trick" than gtk_window_present.

If that's the case (and correct me if I'm wrong), then the documentation of gtk_window_present should be changed to reflect this intention, and Pidgin should be changed to implement such a trick. To let the pidgin devs know about all this, I opened http://developer.pidgin.im/ticket/5521 there.

I also tried a patch that seems to do this hide/show cycle, although for some reason I didn't fully comprehend I had to deiconify the window as well. Is http://developer.pidgin.im/attachment/ticket/5521/5521a.patch the kind of solution you would (officially?) suggest for GTK applications that reliably wish to move a window to the current desktop?