I'm adding myself to the cc list.  Note that bug 115650 and bug 118372
are gtk and metacity bugs related to this issue.

Note that the patch in bug 115650 introduces a display_x11->user_time value
which is tracked for each application.  If gtk_get_current_event_time() doesn't
suffice, perhaps a new gtk function could be added which returns the value of
user_time.  Of course, that couldn't be done in time for Gnome 2.8...

Created attachment 28971 [details] [review]
The *wrong way* to handle this

I forgot about this bug for a while.  The patches in bug 118372 will be
committed shortly.  Because of this bug (i.e. because windows are launched with
a timestamp of 0), new windows will not gain focus and will appear behind the
focused window.  While this patch is the wrong way to do fix this bug, it gives
those who run from CVS a fully functional workaround while they wait for the
real fix.

Comment on attachment 28971 [details] [review]
The *wrong way* to handle this

Marking as needs-work since this isn't actually a patch that's proposed for
commiting

Elijah: does gtk_get_current_event_time() not do a good enough job for now?

Hmm, perhaps calling gtk_get_current_event_time() isn't the best idea since it
gnome-desktop-item shouldn't really depend on gtk+ and there's nothing really
that says the launch has been activated by a gtk+ event.

Adding a gnome_desktop_item_set_launch_time() API sounds like a reasonable thing
to do, though.

This sucks, but I'm swamped with preparing for a conference (school stuff) until
a week or so after API/feature/module freeze, so I won't be much help.  And I
don't know enough to really answer the question; I never tried
gtk_get_current_event_time or other solutions--I just posted what I had as a
temporary workaround for people that wanted it, knowing full well that Gregory
had told me it was the wrong way to do it in comments in bug 118372.  I meant to
help out with this (and bug 144897, the equivalent nautilus bug...).  Sorry
about this.

Created attachment 29633 [details] [review]
Patch to add the gnome_desktop_item_set_launch_time function

Ok, nevermind.	I'm addicted to Gnome and found some time.  :-)

As Mark pointed out, the launch might not be activated by a gtk+ event.  In
fact, gtk+ has a gdk_x11_window_set_user_time function because of the
possibility of external events and because of the fact that it needs to track
the most recent user interaction time for the _NET_WM_USER_TIME timestamp.  But
there's no gtk+ api to access this _NET_WM_USER_TIME timestamp (stored in the
struct's GdkDisplayX11 user_time field) set by that function.  So, this patch
adds a gnome_desktop_item_set_launch_time() API as Mark suggested.

Note that I have two ifdef'd out sections in the patch.  These sections provide
a backup timestamp for faulty applications that don't call
gnome_desktop_item_set_launch_time as they should.  That might be a nice backup
to have, but then again it'd also promote apps remaining broken.  So, I'm
unsure whether to include that or not.	I figured including it but ifdef'ing it
out would be good enough for now.

Does the patch look sane?  Anything I need to fix/improve about it?

Okay, I think gtk_get_current_event_time() is going to do the job just fine. In
the panel, for example, we should have a current event for every launch. Its too
complicated to figure out in Nautilus whether we do or not :-)

I think we should go with gtk_get_current_event_time() for now (one reason for
that is that if I went to use gnome_desktop_item_set_launch_time() in the panel
I'd just pass it the value of gtk_get_current_event_time) and add
set_launch_time() only as needed.

2004-07-19  Mark McLoughlin  <mark@skynet.ie>

        Hopefully a good enough fix for bug #136278.

        * gnome-desktop-item.c:
        (ditem_execute): pass the value of gtk_get_current_event_time()
        to sn_launcher_context_initiate().

Hehe.  Providing a crappy patch pushed Mark into action quite nicely, didn't it?
 :-)