GitLab

We don't really need to classify how people contribute to
Builder. We just want your contributions.

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.

We need to do a bit more work to try to prime the proper
symbol directories for Sysprof.

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

This provides an easy way to access a debug terminal inside the
namespace of the Builder application. "debug-terminal" from the
command bar will place you in the mount/pid namespace for
troubleshooting Builder issues.

We want to improve the chances that Sysprof will locate the debug directory
before it locates the regular ELF directory.

The self->sdk value will be something like "org.gnome.Sdk/x86_64/master"
and this expected "org.gnome.Sdk". We already have a way to get just the
identifier without arch/branch, so we should use that.

This fixes some path translations into debug data paths.

We want to try to use fullname when possible, but we need to possibly
translate it from the runtime into a path that we can access outside
of the runtime.

This tries to handle both the relative-to-builddir cases as well as the
case of files found in the SDK headers.

Ensure we reload the change monitor immediately after the
buffer is loaded so that we can see initial changes.

This looks jarring when transitioning from normal to bold
weight. It also isn't really necessary with the background
already drawing the selection.

to resume:

IDE_WORKBENCH_OPEN_FLAGS_NO_VIEW:
  load the buffer but don't create a view

IDE_WORKBENCH_OPEN_FLAGS_BACKGROUND:
  load the buffer, create the view, don't present it to the user

of course the buffer/view are only created if it's not already done.

The html-preview plugin was creating lambda's which held
references to the various widgetry. These are apparently causing
leaks. Probably something to be worked out in PyGObject but
easier for us to just stop using lambda's when possible.

We should not have different spaces between the number and the change line
based on visibility of breakpoints. This was too compressed. The point of
the breakpoint background was to use the proper spacing, not allow us to
shrink it past what looks pleasent.

If the file is not debuggable, then we do not need to change the highlight
color for the prelight background.

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

This reverts commit 421699ec.

If we've somehow already gotten a loaded buffer, we need to add
the items here when creating the perspective.

(cherry picked from commit 94a56e15)

This plugin has been broken in a couple different ways, and the
paste server API has completely changed. Instead of trying to
fix this (which requires a bunch), I'd rather just remove this.

If someone wants to make a new version that is well supported,
they can build it however the see fit.

This doesn't need to be a package because we only have a single file.

This moves the template files for the meson-templates plugin
into a .gresources which can be loaded by the plugin layer.

(cherry picked from commit 8e3aae62)

Instead of relying on SVG rendering (and rsvg pixbuf loader), we can ship
pre-generated symbolic icons. They are faster to initially render and help
avoid some memory fragmentation caused by rsvg parsing a bunch of XML at
startup.

This also moves some of the designer files off into src/. The render
scripts never really worked well for me, but I anticipate they'll need
some fixups the next time we edit iconography.

We want to set this directly to ensure that it is correct and remind us
to change it to release when doing stable branch builds.