GNOME Bugzilla – Bug 303333
[patch] gtk_window_present() is not strong enough in AddWindow.cs
Last modified: 2006-06-02 17:02:37 UTC
There is currently a fair amount of discussion going on in Bug 166379 about problems with gtk_window_present(). I believe that a patch in that bug has caused a regression in Muine (in order to fix a bug in gedit). Specifically, if you say 'muine-shell -a' to pop open the album window, the Present() call made in AddWindow.cs is no longer sufficient to bring the window to the front (and instead it pops under). This makes 'muine-shell -a' not very useful as a keybinding. The talk in Bug 166379 appears to be that there will be a new API in future versions of GTK to allow more precise control over what behaviour of gtk_window_present() that you want (by manually passing the timestamp) and until that time you have to do it yourself. Here's a patch that does just that. It uses the gtk current_event_time for the focusing of the window instead of the user_time (the old GTK behaviour). As far as I can tell, this means that the window will always come to the front, regardless of the last time the user interacted with the actual Muine window itself (since it uses the current time as the timestamp... not the time of the last event). It works for me and seems like an appropriate addition until the new API is added to GTK. This might also be considered for the presentation of the main window (ie: so that 'muine-shell -w' works). The reason that I didn't do this is that if Muine takes a while to load and the user starts working with another application, the entire point of this new focus stuff is that Muine _doesn't_ pop up on top (and I didn't want to break that). Cheers
Created attachment 46115 [details] [review] patchity patch patch the window.Present() call is preseved here since it does some other things (like gtk_show_all()).
Any word on this?
2005-06-13 Jorn Baayen <jorn@openedhand.com> * DBusLib/Player.cs: * PluginLib/IPlayer.cs: * plugins/TrayIcon.cs: * src/Actions.cs: * src/AddWindow.cs: * src/Global.cs: * src/PlaylistWindow.cs: Provide timestamps to functions raising windows, and use Gdk.Window.Focus instead of Gtk.Window.Present. Fixes #303333.
The patch, as applied breaks muine-shell (superficially and in more substantial ways). Superficially, of course, the calling convention for the PlaySong and PlayAlbum methods has changed. More substantially, though, the code does this: public void Run (uint time) { bool was_visible = Visible; [... snip ...] window.Show (); if (was_visible) window.GdkWindow.Focus (time); } Which means that unless the window was previously visible, the timestamp passed from muine-shell is completely ignored and the current gtk 'last event' timestamp is implicitly used. This breaks the most common use case (specifically, opening the window when it is not yet open). Instead, window.GdkWindow.Focus should just always be called with the timestamp (and it will show the window if required). Also, muine-shell is a straight-up D-BUS application. It does not talk to X so there is no way for it to get X event timestamps. As a work-around for this, it would be nice if a value of '0' received for the timestamp was replaced with the current GDK event time.
Created attachment 47962 [details] [review] the changes as mentioned above
Created attachment 63039 [details] [review] updated patch turns out the same bug exists in the playlist window code too. also note: the gdk current event time is simply '0' so muine-shell is able to send this value directly to mean 'show now'. patch updated to reflect both of these discoveries.
Committed patch by the direction of latexer. Bug is now closed.