gplugin/gplugin

Split plugin details into a separate page

19 months ago, Elliott Sales de Andrade
fcd52dc4273e
Split plugin details into a separate page

This modifies the `GPluginGtkView` into a stack, showing the list of plugins by default (called the 'overview'), or a page for a specific plugin. Going back and forth is automated, but an application can request the page for a plugin directly if needed.

The plugin row no longer expands to show details or shows a config button, but its activation goes to its own page now. This also makes each row a bit more balanced vertically, since there's no `GtkRevealer` taking up invisible space underneath.

The new plugin page is _mostly_ a copy of the previous plugin row, except:

* It's always expanded (or rather, it cannot be collapsed.)
* The main details are re-arranged a bit to fit nicely on a page.
* All information is found via `GtkExpression`s.
* Instead of separate labels for each author/dependency, these are now a single newline-separated label, which is easier to generate.
* Booleans display a check mark instead of text, like in the inspector.
* Information labels are selectable and have a `labelled-by` relation.
* The error message is allowed to wrap.

Settings, once implemented, can go at the end of this page.

I debated splitting the plugin info into a stack with 'important' vs 'developer-oriented' entries (somewhat how `GtkAboutDialog` splits its information), but that can go in a separate review if it's done.

NOTE: This deletes the `expanded` property from `GPluginGtkPluginRow`; that's probably an ABI break, though /r/1834 means it was never registered in a released version.

Testing Done:
Opened the separate page of a few plugins, and saw that details were available. Also, the switch was in sync with the switch in the overview.

Reviewed at https://reviews.imfreedom.org/r/1840/
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!