How can I set the application name that appears in the top bar etc for a gjs application? It seems to be hardwired to “gjs”. According to the GLib docs, when using GApplication, g_application_run() reads the executable name from argv and calls g_set_prgname(). But gjs’ ARGV strips off argv, so that can’t work. I’ve tried putting in a fake argv, but that makes no difference. I’ve tried calling g_set_application_name() manually, but that doesn’t work either. I’ve tried it before calling app.run(), in vfunc_startup() and in vfunc_command_line(), none of them work.
This is for GTK3. I’ve noticed different behaviour in another app for GTK4; that uses the application_id, but that’s also not really the right thing to do because the id is supposed to look like a backwards URL, not a human-readable name. I haven’t tested that app to see whether calling g_set_prgname/application_name manually work.
GTK seems to be able to override the guess somehow though, because a GTK4 GtkApplication uses the app id.
The app I’m currently working on doesn’t have a desktop entry because it’s launched from an extension’s panel widget. I could add a desktop file and use gtk-launch, but I think that would require the desktop file to be installed separately in /usr/share/applications or ~/.local/share/applications. Maybe I can make gtk-launch use a path inside the extension folder by setting XDG_DATA_DIRS?
I think the problem I’m facing at the moment is that with the desktop file in a non-standard location, it’s no good setting XDG_DATA_DIRS just before launching it, because that has no effect on gnome-shell. Would using Gio.DesktopAppInfo.new_from_filename() and then appinfo.launch() from the extension fix that, or would the info from the desktop file still be “lost” by the time the app opens?
Anyway, even if it did work, I’d still have a problem with the desktop file needing an absolute path or one relative to PATH. I could work around that by generating a GKeyFile in memory and using Gio.DesktopAppInfo.new_from_keyfile(), but from what you’re saying it still won’t work.
I think there are some other mechanisms it can fall back on, eg something to do with WM_CLASS, but that would probably only work in xorg, not in Wayland.
Not sure what your thinking here, but yes that would be X only
You’d probably be better of with Gio.AppInfo.create_from_commandline but as you infered this wouldn’t help you much - Shell needs to be able to find the entry via Gio.DesktopAppInfo.new, which means having a file in XDG_DATA_DIRS/applications (as shell sees it)
I’m not quite following why you can’t drop a NoDisplay=true in ~/.local/share/applications?
I just don’t want to have to install a desktop file, because it will make my extension harder to install. At the moment I can just git clone it (with the right name) in ~/.local/share/gnome-shell/extensions then enable it with the Extensions app (formerly gnome-tweaks) or gnome-extensions. If it has to install a desktop file it will either need to be installed as root, or via a script to set the $HOME component of the Exec field. Does the browser integration support additional actions to be performed during installation?
Indeed, when Gnome Shell cannot read the information from .desktop file (Gio.DesktopAppInfo.get_name), it sets name from wm_class (Meta.Window.get_wm_class).
Manually renaming wm_class should work on Xorg: Gdk.set_program_class in Gtk.Application startup handler, or Gtk.Window.set_wmclass before window is realized in activate handler.
Simple naming the program is more universal solution: GLib.set_prgname before Gtk.Application.run (Gdk using GLib.get_prgname to automatically set wm_class) - that should work also in Wayland.
However, wm_class method has a noticeable limitation: the name cannot be localized.