GNOME Bugzilla – Bug 592857
More desktop generic way for handling terminal launching in GDesktopAppInfo
Last modified: 2015-09-11 19:32:41 UTC
In Xfce we'd like to the use G(Desktp)AppInfo for launching desktop files and applications, but the applications used for launching in a terminal windows are all hard-coded and not usable for our environment. A more generic implementation for this would be very welcome, so the desktop can define in some way the _first_ terminal application that is used to connect this to their preferred applications framework.
Sure, that would be a good idea.
Maybe we need to discuss this on the xdg list for a generic implementation of this on all desktops, but that might take a while to get implemented. Another option could be extending GDesktopAppInfoLookup with a call that returns the preferred terminal (or the app for a specific mime type?), we already have a GDesktopAppInfoLookup module to use our preferred applications framework for handling GIO uris, the code can then easily fallback to the hard-coded terminals.
Adding a vfunc to GDesktopAppInfoLookup to get the preferred terminal might indeed work ok. Of course, we need to handle that vunc being NULL, but as you said, thats easy.
Created attachment 162867 [details] [review] Improve support for custom terminal emulators Primarily patch to add support for custom terminal emulators. Please shoot at it.
Review of attachment 162867 [details] [review]: ::: gio/gdesktopappinfo.c @@ +862,3 @@ + term_argv = NULL; + } + } I think you can omit the comments in the for loop, they just literally state what the following code does. @@ +2735,3 @@ + * Get the default terminal emulator when launching a GAppInfo with + * the G_APP_INFO_CREATE_NEEDS_TERMINAL for a particular GDesktopAppInfoLookup + * implementation. It should be #G_APP_INFO_CREATE_NEEDS_TERMINAL for gtk-doc to recognize the constant. @@ +2759,3 @@ + return NULL; +} + Shouldn't g_desktop_app_info_lookup_get_default_terminal_emulator always fallback to the default rather than returning NULL? Otherwise applications still have to have their own fallback code.
*** Bug 600035 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 627943 ***