On Thu, 02 Jan 2020 at 22:07:04 +0100, Jeff wrote:
> On 01/01/2020 21:34, Simon McVittie wrote:
> > If you're using GLib, check that g_get_prgname() (which defaults to the
> > basename of the executable) is what you want it to be. When using a
> > reversed-domain-name app ID but not using GApplication, passing the
> > D-Bus-style reversed-domain-name to g_set_prgname() might be necessary.
>
> This is probably the real solution, but unfortunately, my application is
> Perl, not pure C, and g_set_prgname() is not in the Perl bindings for
> glib (yet).
It isn't in the more curated Glib module, but if you're
using a GObject-Introspection-based auto-generated binding via
GLib::Object::Introspection, all the functions should be available
*somehow*. I've never used GLib from Perl before, so there's probably
a better way, but this lower-level code seems to work:
use strict;
use warnings;
use Glib::Object::Introspection;
use Gtk3;
Glib::Object::Introspection->invoke("GLib", undef, "set_prgname",
"com.example.Test");
print Glib::Object::Introspection->invoke("GLib", undef, "get_prgname");
Or, if there's an equivalent of Python's ctypes in Perl, g_set_prgname
is hopefully not too hard to call through that? It takes one UTF-8 string
argument and doesn't return anything.
Or, can you use GtkApplication or GApplication from Perl? (Gtk3::Application
and Glib::IO::Application, I suspect.)
Either way I'd recommend reporting the absence of g_set_prgname() as a bug
(or at least a feature request), since it's sometimes necessary to control
what GLib thinks the program's basename is.
smcv
