speech: Check if speech schema is present

[tchx84]

The schema is provided by the sugar shell package and in scenarios where that package is not present trying to reference ends up in segfaults, e.g. flatpak apps.

[quozl]

Thanks. On Ubuntu 19.04 I get a warning that list_schemas is deprecated. I also tested that gschemas.compiled is cached; strace shows only one open syscalls for N calls to list_schemas.

[tchx84]

Ouch, I didn't notice that. Will see what is the new API.

[quozl]

Thanks. Reviewed.

I note there are two searches for the schema by name on every call to save and restore. I looked for but did not find a way to do a value lookup from a SettingsSchema.

I reproduce that a Gio.Settings call with an uninstalled schema does cause a trace and breakpoint trap. It cannot be detected with an exception handler. The response seems excessive; is upstream aware of this and do they plan to fix it?

Merging this will break sharing of speech settings across flatpak apps. Is there another way? Browse creates a local Gio.Settings from a schema, if that's something you'd like the flatpak apps to do. See the call to Gio.SettingsSchemaSource.new_from_directory in browser.py.

[tchx84]

Thanks. Reviewed.

I note there are two searches for the schema by name on every call to save and restore. I looked for but did not find a way to do a value lookup from a SettingsSchema.

Me neither, I assumed that save and (specially) restore are not called that often.

I reproduce that a Gio.Settings call with an uninstalled schema does cause a trace and breakpoint trap. It cannot be detected with an exception handler The response seems excessive; is upstream aware of this and do they plan to fix it?

https://gitlab.gnome.org/GNOME/gjs/issues/205 https://stackoverflow.com/questions/26742567/how-to-handle-errors-while-using-glib-settings-in-vala

They are. I assume they might have reason for keeping this way.

Merging this will break sharing of speech settings across flatpak apps. Is there another way? Browse creates a local Gio.Settings from a schema, if that's something you'd like the flatpak apps to do. See the call to Gio.SettingsSchemaSource.new_from_directory in browser.py.

There can't be sharing of these settings between flatpak apps. One issue is that there is no "one owner" of the scheme (e.g. like sugar shell), and the second is that we preferably want to keep these apps as isolated as possible (e.g. so they don't have to access any file from the host).

I wonder if I could use that Gio.SettingsSchemaSource.new_from_directory to at least preserve these values for each app individually... ill double check.

[quozl]

Why can't the settings be shared between flatpak apps? This sounds like a feature of flatpak that makes it problematic to implement Sugar's design. :grin:

[tchx84]

Why can't the settings be shared between flatpak apps? This sounds like a feature of flatpak that makes it problematic to implement Sugar's design.

I wouldn't call it a "feature of flatpak", but is more of a conceptual thing of GSettings... Who owns and provides the shema? The first app to be installed? It is worth it to make these apps less secure just for this?

[quozl]

Security is always a negative-feature. How is blocking the saving of settings to be shared across apps an improvement in security? If this is a non-feature of GSettings, should we use something else?

[quozl]

According to the gjs issue, GLib calls abort(3). According to abort(3) it can be caught by arranging a SIGABRT signal handler. That seems excessive compared to your patch.

[tchx84]

Thanks, ill ask around anyway about how this "distributed scheme" scenario can be handled ideally.

[quozl]

We have some other interesting things in the schemas, if you want ideas.