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 136278 - Timestamps needed for launching functions
Timestamps needed for launching functions
Status: RESOLVED FIXED
Product: gnome-desktop
Classification: Core
Component: libgnome-desktop
2.5.x
Other other
: Normal normal
: ---
Assigned To: Desktop Maintainers
Desktop Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-03-05 13:07 UTC by Gregory Merchan
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The *wrong way* to handle this (2.79 KB, patch)
2004-06-24 01:56 UTC, Elijah Newren
needs-work Details | Review
Patch to add the gnome_desktop_item_set_launch_time function (5.69 KB, patch)
2004-07-18 21:57 UTC, Elijah Newren
none Details | Review

Description Gregory Merchan 2004-03-05 13:07:47 UTC
For startup notification to work properly, an X server timestamp is needed
when starting applications. Currently, the value CurrentTime is passed
to sn_launcher_context_initiate(), and there's no way to pass in a valid
timestamp. Calling gtk_get_current_event_time() may suffice. If it does
not, then an API change is needed.
Comment 1 Elijah Newren 2004-03-05 15:11:16 UTC
I'm adding myself to the cc list.  Note that bug 115650 and bug 118372
are gtk and metacity bugs related to this issue.
Comment 2 Elijah Newren 2004-04-17 15:55:35 UTC
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...
Comment 3 Elijah Newren 2004-06-24 01:56:56 UTC
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 4 Mark McLoughlin 2004-06-24 16:10:38 UTC
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
Comment 5 Mark McLoughlin 2004-07-06 08:24:28 UTC
Elijah: does gtk_get_current_event_time() not do a good enough job for now?
Comment 6 Mark McLoughlin 2004-07-06 11:35:55 UTC
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.
Comment 7 Elijah Newren 2004-07-06 21:30:24 UTC
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.
Comment 8 Elijah Newren 2004-07-18 21:57:24 UTC
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?
Comment 9 Mark McLoughlin 2004-07-19 08:02:35 UTC
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().

Comment 10 Elijah Newren 2004-07-20 23:20:55 UTC
Hehe.  Providing a crappy patch pushed Mark into action quite nicely, didn't it?
 :-)