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 679342 - Add a gtk-launch utility
Add a gtk-launch utility
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-07-03 18:29 UTC by Matthias Clasen
Modified: 2012-07-16 19:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (5.85 KB, patch)
2012-07-11 16:01 UTC, Tomas Bzatek
accepted-commit_now Details | Review
proposed patch (9.35 KB, patch)
2012-07-16 15:30 UTC, Tomas Bzatek
none Details | Review

Description Matthias Clasen 2012-07-03 18:29:47 UTC
This should be a commandline utility in the style of the gvfs utilities. The reason for putting it in GTK+ is that we want to use GdkAppLaunchContext to get proper startup-notification and display handling for graphical apps.

The intended usage is:

gtk-launch foo[.desktop] [uri...]

ie the app to launch should be specified by a desktop file name (could be generous about allowing .desktop to be omitted), and it should be possible to pass uris.

Owen showed some code for passing the current workspace on to the the newly launched application. Including that would be a nice touch.
Comment 1 Tomas Bzatek 2012-07-11 16:01:04 UTC
Created attachment 218568 [details] [review]
proposed patch

First shot, not having manpage yet. Uses gdk_display_get_default() to get a GdkDisplay object.

(In reply to comment #0)
> Owen showed some code for passing the current workspace on to the the newly
> launched application. Including that would be a nice touch.

Owen's code use several Xlib functions, do we want to have them in backend-independent Gtk?
Comment 2 Matthias Clasen 2012-07-12 01:24:05 UTC
Review of attachment 218568 [details] [review]:

Looks good.

::: gtk/gtk-launch.c
@@ +54,3 @@
+  setlocale (LC_ALL, "");
+
+#ifdef ENABLE_NLS

Are we defining ENABLE_NLS in gtk ? We might, but I'm not sure

@@ +110,3 @@
+    desktop_file_name = g_strdup (app_name);
+  else 
+    desktop_file_name = g_strdup_printf ("%s.desktop", app_name);

Could just use g_strconcat here
Comment 3 Matthias Clasen 2012-07-12 01:26:05 UTC
Looks good so far. If you add a man page too, that would be appreciated.
We should probably deal with the workspace setting in a second round; we look at moving some of it to gdk_x11_ and use it only when running under X11.
Comment 4 Tomas Bzatek 2012-07-16 15:30:27 UTC
Created attachment 218918 [details] [review]
proposed patch

(In reply to comment #2)
> ::: gtk/gtk-launch.c
> @@ +54,3 @@
> +  setlocale (LC_ALL, "");
> +
> +#ifdef ENABLE_NLS
> 
> Are we defining ENABLE_NLS in gtk ? We might, but I'm not sure

We are, this is stolen from updateiconcache.c

> @@ +110,3 @@
> +    desktop_file_name = g_strdup (app_name);
> +  else 
> +    desktop_file_name = g_strdup_printf ("%s.desktop", app_name);
> 
> Could just use g_strconcat here

OK, changed.

I've also added gtk-specific option context entries, though probably not very useful for the moment.

(In reply to comment #3)
> Looks good so far. If you add a man page too, that would be appreciated.
> We should probably deal with the workspace setting in a second round; we look
> at moving some of it to gdk_x11_ and use it only when running under X11.

Added a manpage too, feel free to rephrase my bad English.
Comment 5 Colin Walters 2012-07-16 19:21:25 UTC
One long-standing problem with running applications from the terminal is that we don't have an associated X timestamp.  This means focus stealing prevention can't work correctly, or in other words - when you run programs from the terminal, they have to either always pop under, or always pop over; they can't do the Right Thing of popping under if you switched to doing something else, and popping over otherwise.

It's somewhat unfortunate to add an official gtk-launch command that doesn't address this.

For someone who would want to add this later: I think the least evil fix is:

* Change gnome-terminal to:
  - set an environment variable for each tab (and thus for each shell); GNOME_TERMINAL_TAB_3=1
  - Record the timestamp of the last key press event in each tab
* Change gtk-launch to:
  - Check if the environment variable exists
  - If so, make a dbus call to gnome-terminal to retrieve the timestamp
  - Pass the timestamp to the launch call