gplugin/gplugin
Clone
Summary
Browse
Changes
Graph
Remove the convey directory since we don't want docker hub to rebuild our images for every commit including ones that don't touch the images
feature/convey
2017-06-15, Gary Kramlich
3cb7d182f07d
Remove the convey directory since we don't want docker hub to rebuild our images for every commit including ones that don't touch the images
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
!