Using libgd in gnome projects

Hi,

Looks like at least few Gnome projects are using libgd own copies statically linked into the binaries.
List of those which I know:

  • bijiben
  • gnome-music
  • gnome-photos

There is probably more such projects. There is few issues with using this library:

  • quite often it has some security issues
  • probably should be used here cairo.

I’m guessing that libgd was used as kind of JFDI solution.

Libgd is a copy-paste library for shared widgets; back before Git and submodules, we used to have libegg. The idea is to use libgd to iterate over UI, API, and functionality; then, move things to GTK if there’s enough of a momentum.

I fail to see what Cairo has to do with libgd; additionally, security is a non-issue, unless you care about the fact that nobody has ever audited glib and GTK either.

I believe the OP is confusing GNOME’s
libgd
with GD Graphics
Library
.

1 Like

So I think that more than only those three applications are operating on clipboard.
Why this library is not used as shared library?

Sorry, but I don’t understand what you mean.

It can be built as a shared library—and typically it is, if the application consumes it through introspection; but it’s yet another dependency, and since there’s no API stability guarantee, it’s easier to bundle it with your own application. Additionally, libgd allows you to build only the bits you need in your application, so the binary size does not balloon out of control.

Complicated things have complicated dependencies :slight_smile:
Nevertheless it is not easy to figure out for what is this library and what that GD in name stands for :slight_smile:

Problems with libgd IMO are that name is confusing and easy to make mistake like I did :stuck_out_tongue: and already more than one project is using it causes that some memory for the code is wasted.

It stands for “gnome-documents”, as it was the first application to implement the design patterns in the Human Interface Guidelines for GNOME 3.

The cost is negligible at best compared to the rest of the application. As I said: applications only build the parts of libgd that they use.

Even the cost of code duplication is minimal, since everyone uses it as a Git submodule, so changes are usually done centrally.

The main cost is that the API is unstable, and that any change will end up impacting everyone using the library; ideally, the most used/stable classes should find their way into GTK, but:

  • GTK 3 is feature frozen, so no new widgets
  • GTK 4 is still in development, so no applications are porting to it
  • the HIG is still evolving, so libgd widgets may or may not change

At some point, when GTK 4 stabilises prior to release, people will start porting libgd to it, and see what can be moved into the toolkit.

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.