gplugin/gplugin

Implement widgets for settings that use basic types

15 months ago, Elliott Sales de Andrade
7e519d51af72
Implement widgets for settings that use basic types

This implements enums, integral types, double, and string. I have not yet implemented flags, and I'm not sure if we need those. The numeric types use spin buttons, though I suppose they could be sliders. The rates/digits/increments are somewhat arbitrary and could probably be adjusted, but seem good enough for now.

I _think_ this should be sufficient for all libpurple plugins. The GTK plugins may or may not be possible. For example, `spellchk` has a full table of replacements. This may work as a `dict[str, str]` in a table widget, but this is so far not implemented here. We should probably think about whether that makes sense to handle `dict` semi-generically or whether to expose some kind of GTK extension point as in the old API.

Also note that there are no `GSettings` types for things like directories or files, so those don't get any special treatment other than a string input. If we do want special handling, we may have to come up with some setting conventions (e.g., a setting name ending in `-dir` gets a directory chooser widget instead of an entry automatically, or similar).

Testing Done:
Ran `gplugin-gtk4-viewer -p gplugin/native-settings-plugin` and checked that all the settings had widgets with expected limits, and that setting them then going to another plugin and back preserved the settings. (Note that it does warn once for the unimplemented `flags` type.)

Also checked that plugins set up in /r/2131 had some settings.

Reviewed at https://reviews.imfreedom.org/r/2150/
GPlugin is a GObject based library that implements a reusable plugin system
that supports loading plugins in other languages via loaders. GPlugin also
implements dependencies among the plugins.
It was started due to the infamous "Plugin Problem" for Guifications 3, which
was that I needed plugins that could depend on each other, be able to be
written in other languages, have plugins that are loaded before the main load
phase, and allow plugins to register types into the GObject type system.
After trying to fix this numerous times in the Guifications 3 tree, I decided
I should really do this the UNIX way and write it as a stand alone library.
During this time, I also got the idea that there was a good chance that someone
probably beat me to this... So I started searching and came across libpeas.
Libpeas looked promising, but there was a few things about it that I really
didn't care for. First of all, the plugin information (id, name, author, etc)
are in a separate data file that gets stored in a separate location on disk.
Getting people to write good plugins is difficult enough as it is, why bother
throwing more obstacles in their way? This data file is a essentially a
GKeyFile, which means you can store the translations of all the fields right in
it. Now this is great if your plugin doesn't have any strings to display at
runtime, but if it does, you still need to install the translation file itself.
So as long as your plugin has to display strings at runtime, all that data file
gave you was more work. So there was STRIKE ONE!
So I continued to look at libpeas and noticed something odd in the earlier
mentioned data file. One of the fields you have to set is the Loader!? Yes,
the libpeas authors explicitly expect you to call out which loader you need. I
personally find this to be very lazy. I realize it makes it easier to code,
but come on, that should be a one time cost to the library author, instead of
an additional startup cost to the plugin author. STRIKE TWO!
So with two strikes down, I continued researching libpeas, and discovered that
you can only use one language other than the native loader. We, the Pidgin,
developers have always aimed to support as many languages as possible, and this
just wasn't going to cut it. So there was STRIKE THREE!
Libpeas had struck out for me, and as such I started GPlugin the very next day!