GitLab

Instead of controlling the transfer manager at the IdeContext
level, this uses IdeApplication as the owning instance. This is
useful because it allows us to use it from preferences without
having a context accessible.

This isn't exactly safe to do because we have no control over
the threading of the parent process. We need to instead rely
on the process group for killing the process.

The beautifier plugin does not currently know how to access embedded
resources, and when embedding it, we get a different data_dir back from
libpeas.

So for now, lets just not embed the plugin and once that is all fixed,
we can change it to use embedded plugins.

This reverts commit 9fed9f2a.

Now that this is statically linked into libgnome-builer-plugins.so, we need
to embed our resources too.

Not all runtimes that we install should be displayed to the user, so filter
the ones like .Docs or .Locale.

We want this so that we can locate .Docs runtimes later on. We will ignore
the runtimes from other places.

If we build the gdbwire amalgamation as a separate static library then we
can alter the CFLAGS that are used to compile it. Given that it is an
amalgamation and is C89-based rather than C11, this allows us to squash
some warnings that are unhelpful.

We link the library with libgnome-builder-plugins.so so the end effect
should be identical to what we had before.

This fixes the warnings from the header, but not the C90 warnings from
the gdbwire.c.

Request that gtk-doc ignore these fields.

Introduced by 96cce33a

This moves the preferences to an external window instead of
using a perspective within the parent window. This useful for
couple of reasons:

 * It allows us to use the preferences outside of the workbench
   such as during the greeter phase.
 * It allows us to destroy widgets when they aren't visible.
   There are lots created in preferences, so this is a sort of
   nice thing from a memory usage standpoint.
 * Reduce the time it takes to open a project since it would
   add the preferences as part of that phase.

These were getting leaked apparently.

We only show GNOME versions >= this min version. We can reduce
this to current version + master, since we don't want to
encourage people to write new applications against older
runtimes.

There might be a better way to check for this in the metadata,
but that takes more effort right now.

This changes most of the code base to using #pragma once instead
of the old style #ifndef FOO_H header guards. I hear that the
old style is still slightly faster, but I don't care much about
that. I'm sure GCC will continue to optimize for this going
forward.

Also, we're already using a bunch of other C11 features, so
might as well use this too.

Now that we're linking all the plugins that were using internal
API, we can drop this and avoid using _ide_* in the ABI linker
script.

We need access to the uninstalled gsettings schemas when running tests.

https://bugzilla.gnome.org/show_bug.cgi?id=788089

We need access to the plugins contained in the .so for the tests to
complete properly.

None of our plugins are using packages, so we might as well
keep things compact and just use modules instead of packages.

This also cleans up the rustup plugin to use gresources.

This creates a new library that contains many plugins inside of it.  The idea
here is that the gnome-builder executable will link against this library
allowing us to drastically reduce the number of files that are checked/loaded
when starting a gnome-builder process.

This appears to be racey, and after statically linking things in, it was
more likely to appear.

Translate /run/build-runtime paths into source paths from .Debug

https://bugzilla.gnome.org/show_bug.cgi?id=787809

This keeps things that are related to the editor itself in the editor
plugin rather than in the top-level gtk/menus.ui.

This is only needed by DOAP parsing, even though lots of things were
linking against it (which wouldn't have worked anyway statically, since
it registers a GObject).

These projects are all now standalone, so bundling them is no
longer necessary for Builder.

https://bugzilla.gnome.org/show_bug.cgi?id=788009

We don't want to allow the focus to steal these keybindings, such as the
terminal widgets.

As the project has grown, we've let things get a bit out of their
logical place. This does a bit of cleanup and tries to bring some
of the embedded resources closer to where they are used.

But more importantly, this allows us to clean some things up to
the point that we can move forward statically linking a bunch of
the plugins into libide. The plan here is to speed up the initial
loading by avoiding lots of disk I/O stats which are currently
hurting us.

Having these programs split out was not very useful as we move to a
flatpak'd world. If we keep everything accessable via --type= then
we can allow things to work even through 'flatpak run ...'

Since we previously used a "hidden" parameter --type for the plugin
name, that has been renamed to --plugin= which is arguably a much
better choice.

Use --type=cli for the cli version and --type=worker for the plugin
worker version of gnome-builder.

For our old format, you can do something like this in your .bashrc:

Either:

  alias ide="gnome-builder --type=cli"
  alias ide="flatpak run org.gnome.Builder --type=cli"

And then:

  ide --list-commands