GitLab

This isn't the ideal version we want where we can limit the number of
inflated rows based on the viewport, but it does help us in situations
where we have to recreate rows a lot (like when updating search results).

The goal here is to replace the search results with something like this so
we get less flicker on wayland when repopulating search results.

If we don't add any more complexity to our search results (unlikely), we
could of course just switch it to TreeView with minimal effort.

This fixes keyboard activation of global search using the new headerbar
design.

There are a couple of places we need this, so it would be nice to have the
notification source in a single place rather than require consumers to
bring their own polling.

But also handle non-native (remote) file-systems and absolute paths when
necessary.

If the display-name of the IdeConfigurationManager:display property changes
then we need to notify our listeners that current-display-name has changed.

This will need to get a bunch more smarts as we go forward and have more
generic messaging API. But this is a simple way to loop through the stack
children when necessary.

Not exactly like the design, but step 1 towards getting there.

We might want to pull this out of a plugin at somepoint, but for now we
can just propagate the build result to the omni bar.

The omnibar will allow us to see build status and cancel an active build.
We could certainly use a cleaner abstraction here, but this at least gets
things wired up.

The OmniBar is pretty much what it says, the joining of a bunch of things
into a single widget. Getting the density of information we want definitely
can result in non-clean abstractions.

However, if we can come up with a good way to have extension points in the
omnibar, we might just be able to clean this up.

This is less than ideal, because it's the result of 2 bugs in gtk+ size
requests that we are working around.

The first, is the lack of hexpand support in left/right of the headerbar.
The second, is that the center widget + sizing of neighbors is not
respected when a GtkBox is packed as the custom title.

Where this will be apparent, is when the content is compressed and there
are uneven buttons on the left/right. You'll see spacing enforced for the
size group contained widgetry, which will be rather annoying im presume.

Either way, this works for now and allows us to move forward.

Not sure how we missed this previously, but obviously an oversight.

If you want to watch for changes, connect to ::changed and then call this
function again.

This is the combination of a get_workbench() + get_context().

Sort of a layer violation, but I'd like to see this working before we go
and determine all of the proper layering we'd like to see for plugins.

To implement our designs propertly would require GtkHeaderBar to support
hexpand for start/end children. Instead, we can work around it for now
using a center child and opposite packing.

It's not perfect, since it will require even allocation on left/right, but
it allows us to move forward for now.

The box is not expanding, so need to track that down.

This will eventually track the important bits of state for the IDE. Still
requires some plumbing.

EggEntryBox looks like an entry but allows packing children like a box.
You can set max-width-chars property to set the natural size of the box.