gplugin/gplugin

Rename README to HISTORY.md
bugfix/docs-cleanup
2019-08-12, Gary Kramlich
25f45174de5b
Parents 9db55eb0b79d
Children c9527b45485a
Rename README to HISTORY.md
2 files changed, 41 insertions(+), 41 deletions(-)
  • +41 -0
    HISTORY.md
  • +0 -41
    README
    • --- /dev/null Thu Jan 01 00:00:00 1970 +0000
    +++ b/HISTORY.md Mon Aug 12 22:21:01 2019 -0500
    @@ -0,0 +1,41 @@
    +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, by now working on a
    +plugin for rhythmbox, and just found the API to be clunky and poorly
    +documented. Now maybe I just wasn't finding the write documentation, but this
    +was STRIKE THREE!
    +
    +Libpeas had struck out for me, and as such I started GPlugin the very next day!
    +
    --- a/README Mon Aug 12 22:20:36 2019 -0500
    +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
    @@ -1,41 +0,0 @@
    -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, by now working on a
    -plugin for rhythmbox, and just found the API to be clunky and poorly
    -documented. Now maybe I just wasn't finding the write documentation, but this
    -was STRIKE THREE!
    -
    -Libpeas had struck out for me, and as such I started GPlugin the very next day!
    -