RFC: in-process embedding for the settings manager

[Brian Tarricone]

Hi all,

As we know, settings dialogs for various components and apps can be displayed in the Xfce Settings Manager, and they can use XEMBED (via GtkPlug) to allow the settings manager to embed the dialog's contents directly in the setting manager's window.

Unfortunately, Wayland does not support this mechanism.  I worked up a demo of what an in-process embedding model could look like, and I'd appreciate some feedback.  With this new model, the settings dialogs are shipped instead as shared libraries that the settings manager can dlopen() at runtime, with a well-known symbol exported that the settings manager can call to get the GtkWidget of the dialog contents, which it can then embed in the settings manager window.  See [0] for a draft MR for the implementation in the settings manager, [1] for some documentation I've written about it, and [2] for a sample conversion of the xfdesktop settings dialog.

In order to allow users to load individual settings dialogs as they can today, the old binary (e.g. 'xfdesktop-settings') can be replaced with a shell script that calls out to xfce4-settings-manager, with command-line options passed to display a standalone, specific dialog.

Note that I do not plan to remove the out-of-process support from the settings manager, so dialogs that choose to continue to use it (or just don't get updated in a timely manner) will continue to work.  In the above MR, I've added code to the settings manager so that it doesn't even try the out-of-process model on Wayland, and will either use the new in-process model, or fall back to loading/running the dialog externally.

There are a few downsides/gotchas that I can see to my in-process approach:

1. Any memory or resource leaks in settings dialogs will "live on" in the settings manager if it's kept open for a while and used to view many different settings panels.  Memory and resource cleanup code is often omitted in short-lived dialog apps where they rely on the OS to free memory and resources when the dialog app quits.  (I had to clean this up when I converted xfdesktop's settings dialog.)

2. A crash in an in-process dialog means the entire settings manager crashes.

3. It's more complex for the case of running a single settings dialog, and there's more that can go wrong.  Instead of just running a binary (which should, in theory, always work), now it has to search for a .desktop file installed in the right place (that describes the dialog), and then find a shared library that's installed in the right place, and load and use it.

4. Related to the above, the shared libraries for the settings dialogs need to be installed to the same prefix/libdir as the settings manager.  The settings manager now ships a pkgconfig file that allows build systems to discover this directory, at least.

5. Settings dialogs written using toolkits other than GTK3 won't be able to use the in-process model.  While I don't think there are any such dialogs, it's maybe worth considering.  XEMBED (the protocol GtkPlug & GtkSocket use under the hood) is toolkit-agnostic, so someone could have a Qt app where they want the settings dialog included in Xfce's settings manager, and it should work fine using the out-of-process model (albeit with inconsistent UI styling and behavior).

Some of these issues have some possible mitigations:

3. A component could (instead of calling xfce4-settings-manager) build and install a standalone app, in addition to the shared library, that puts a toplevel dialog and buttons around the dialog contents, but this feels like a lot of copy-paste and duplication of code.  (That code could also be put in a library, but that also feels like overkill for something like this.)

4. We could support an (optional) .desktop file key that points to the absolute path of the shared library.  (And .desktop files in non-standard prefixes can be included via XDG_DATA_DIRS, but there is no similar mechanism for a library module/plugin search path.)  I think I'll go ahead and implement this, since it's just a few lines of code.

Thoughts?

Cheers,
Brian

[0] https://gitlab.xfce.org/xfce/xfce4-settings/-/merge_requests/102
[1] https://gitlab.xfce.org/kelnos/xfce4-settings/-/blob/in-process-embedded-dialogs/xfce4-settings-manager/README.md
[2] https://gitlab.xfce.org/xfce/xfdesktop/-/merge_requests/105