GitLab

Some changes occurred recently, which make supporting this rather pesky.
However, this gets stuff building again. We have to rely on 3.28 instead
of 3.30 because of the freedesktop SDK extension. That has too old of
meson, so we need to install our own meson of 0.48.1.

Fixes #683

We want the button insensitive until there are results to display.

This plugin provides a grep backend that can optionally use git-grep when
the current project is using Git.

You can search for files from the project-tree by selecting "Find in Files".
That will limit the search results to the directory that has been selected.

If the selected node is a File (instead of a directory), then only results
from that file will be shown.

You can search using regular expressions supported by the particular grep
implementation. We don't currently guarantee options here (or validate them
for correctness). Some effort could be done here using GRegex in the future.

As we already have support for performing edits across a number of files in
the background, the grep plugin allows you to select matches and replace them
with new text. In the future we could extend this to try to preserve casing
of the replacement.

To avoid lots of small strings and numerous copies of them, a custom
GtkTreeModel was used. Instead we have a single large buffer of results that
were obtained from grep, and keep an index to the start of each line in the
buffer. A \0 replaces the \n that we received from grep.

I expect additional work will be needed here, but this seems like a reasonable
first attempt at the feature. Larger projects may need additional performance
tweaks.

This allows adding a command that will get the path of the selected item.

The project tree easily supports multiple builders. We can use this to
allow other plugins to extend the project tree by registering new builders.

Longer term, we may change the root of the tree to be the context, so that
we can have "virtual folders".

The return value is not used for now
but at least this will shut up the warning.

This fixes an issue when the file to be edited is not currently open.

Related to #673

If we match 'E' with 'e', that should have a higher cost than 'e' with 'e'.

This ensures that we match 'E' before 'e' in 'Endianness' if the input
character is 'e'. Otherwise, 'end' won't match and that is not the
expected behavior.

This just takes the earliest of 'E' or 'e' as the match for any character
that has a toupper() variant, at the cost of running additional matches.

This code does need to stay fast, but it seemed fast enough in testing.

Fixes #673

Fixes #685

This can be non-widgets too, like a GtkSizeGroup.

This tries to locate some information about the catalogs from the build
runtime and installation prefix. It's somewhat problematic in that
accessing libraries and what not is not necessarily possible. But we can
start here and see how things work out.

It is fine to open an empty .ui file, since we will write the proper
<interface/> element and such when saving it back to disk.

Fixes #682

These are set automatically, according to

  https://github.com/flathub/org.gnome.Builder/pull/6/files

When guessing the language from GtkSourceView, we can remove the trailing
.in so that we are more likely to get the proper language type. This is
useful because rarely are people simply caring about the template expansion
and more interested in the underlying language syntax.

Fixes #681

I wanted to avoid this originally, since .ui files can also be used with
other systems such as Qt, but we are a GNOME focused IDE and there is very
little we could ever do to support Qt, so just mark the .ui glob as being
a gtk-builder file.

This simplifies our signal tracking, and allows us a convenient place to
start doing tracking of more GladeProject signal editing.

When saving the designer view, we want to reload the editor source for the
user so that they don't need to get a "modified on disk" warning. This
requires a bit more manual state tracking, but it's worth it.

This allows us to reload a glade project in what seems like "in-place".
Supporting this will allow us to track changes from the editor immediately.