Disable calls in phrog

[Vedingrot]

Hi! I discovered that phrog activates gnome-calls via dbus. Gnome-calls
loads system on start and I'd like to prevent any calls in the greeter. Is there
way to disable this behavior?

[samcday]

Hi!

Hullo! 👋

Is there way to disable this behavior?

This isn't something 🐸 itself has direct control over. Instead, we'd need to raise an upstream issue for Phosh to ensure libphosh provides something we can use to control this behaviour.

Gnome-calls loads system on start and I'd like to prevent any calls in the greeter.

Could you please expand on this? Why do you want to prevent any calls in the greeter?

I'm curious about the why because I think we'd need a pretty good reason to make it possible for people to disable emergency calling support from the greeter.

I think it's best we have a solid and legitimate use-case in mind when we go upstream and ask for API changes.

That said, maybe a simple "fix" here is to raise an upstream issue asking to make the emergency calls path more "lazy". That is, we ask that libphosh doesn't try to get a list of emergency contacts until you actually request to make an emergency call. That might actually be enough to prevent any org.gnome.Calls DBus activity during a "normal" (i.e no emergency calls to make, just a boring old login) greeter flow..

[samcday]

That said, maybe a simple "fix" here is to ...

@agx do you think it's appropriate to raise such an upstream issue?

I asked a 🤖 and it assures me that:

• calls manager uses DO_NOT_AUTO_START (src/calls-manager.c:386),
• emergency-calls manager uses G_DBUS_PROXY_FLAGS_NONE and immediately queries contacts (src/emergency-calls-manager.c:324, src/emergency-calls-manager.c:313).
• gsettings set sm.puri.phosh.emergency-calls enabled false only gates whether emergency-call UI/action is enabled (src/emergency-calls-manager.c:73), not whether the manager talks to org.gnome.Calls (see also src/emergency-calls-manager.c:323); the setting is defined at data/mobi.phosh.shell.gschema.xml:132.

So the specific proposal I would take upstream is: ensure that sm.puri.phosh.emergency-calls.enabled more thoroughly neuters emergency calling behaviour (i.e entirely prevent DBus bus activity from going out when emergency calling is disabled).

While we're in the area, it might also make sense to push the emergency contact enumeration to happen later? That is, only try to load it once the emergency call panel is visible. This would (maybe?) ensure that gnome-calls doesn't get pulled into phrog's session unless/until it needs to.

[agx]

Not calling into calls early is not an option due to https://gitlab.gnome.org/GNOME/calls/-/merge_requests/704 and related information we will need in the future.

What I could imagine a mode in calls that only allows emergency calling. It would then also expose these call restrictions as 2 (emergency-calls-possible) and all other parts in the stack would continue to function as expected.

Whether that fits calls view of things idk

/cc @fortysixandtwo

[Vedingrot]

Hi Sam!

Gnome-calls loads system on start and I'd like to prevent any calls in the greeter.

Could you please expand on this? Why do you want to prevent any calls in the greeter?

I'm curious about the why because I think we'd need a pretty good reason to make it possible for people to disable emergency calling support from the greeter.

I think it's best we have a solid and legitimate use-case in mind when we go upstream and ask for API changes.

That said, maybe a simple "fix" here is to raise an upstream issue asking to make the emergency calls path more "lazy". That is, we ask that libphosh doesn't try to get a list of emergency contacts until you actually request to make an emergency call. That might actually be enough to prevent any org.gnome.Calls DBus activity during a "normal" (i.e no emergency calls to make, just a boring old login) greeter flow..

I think the calls feature in the first-run is unneeded. The startup
of the Gnome-Calls is not free that's main reason. I don't wanna pay
for something I don't use. Your idea of the "lazy" starting is great,
I think it should be done initially. An app in the first-run can decide
when the calls feature is required.