Week 32 Status

Foundry

This week was largely around getting the new template engine landed so it can be part of the 1.0 ABI. Basically just racing to get everything landed in time to commit to the API/ABI contract.

  • FoundryTextBuffer gained some new type prerequisites to make it easier for writing applications against them. Since Foundry is a command line tool as well as a library, we don’t just use GtkTextBuffer since the CLI doesn’t even link against GTK. But it is abstracted in such a way that the GTK application would implement the FoundryTextBuffer interface with a derived GtkSourceBuffer.

  • FoundryTextSettings has landed which provides a layered approach to text editor settings similar (but better) than we have currently in GNOME Builder. There is a new modeline implementation, editorconfig, and gsettings backed settings provider which apply in that order (with per-file overrides allowed at the tip).

    Where the settings-backed implementation surpasses Builder is that it allows for layering there too. You can have user-overrides by project, project defaults, as well as Foundry defaults.

    I still need to get the default settings per-language that we have already (and are mostly shared with Text Editor too) as reasonable defaults.

  • To allow changing the GSettings-based text settings above, the foundry settings set ... command gained support for specific paths using the same :/ suffix that the gsettings command uses.

  • Spent some time on the upcoming chat API for models so I can experiment with what is possible when you control the entire tools stack.

  • Dropped some features so they wouldn’t be part of the 1.0. We can implement them later on as time permits. Specifically I don’t want to commit to a MCP or DAP implementation yet since I’m not fond of either of them as an API.

  • The FoundryInput subsystem gained support for license and language inputs. This makes it much simpler to write templates in the new internal template format.

  • Allow running foundry template create ./FILE.template to create a set of files or project from a template file. That allows you to interate on your own templates for your project without having to have them installed at the right location.

  • Wrote new project templates for empty project, shared library project, and gtk4 projects. Still need to finish the gtk4 project a bit to match feature parity with the version from Builder.

    I very much am happy with how the library project turned out because this time around it supports Gir, Pkgconfig, Vapi generation, gi-doc, and more. I still need to get library potfile support though.

    I also wrote new templates for creating gobjects and gtkwidgets in C (but we can port to other languages if necessary). This is a new type of “code template” as opposed to “project template”. It still allows for multiple files to be created in the target project.

    What is particularly useful about it though is that we can allow projects to expose templates specific to that project in the UI. In Foundry, that means you have template access to create new plugins, LSPs, and services quite easily.

  • Projects can specify their default license now to make more things just happen automatically for contributors when creating new files.

  • Templates can include the default project license header simply now by doing `{{include “license.c”}} where the suffix gets the properly commented license block.

  • The API for expand templates has changed to return a GListModel of FoundryTemplateOutput. The primary motivator here is that I want to be able to have UI in Builder that lets you preview template before actually saving the templates to disk.

  • A new API landed that we had in Builder for listing build targets. Currently, only the meson plugin implements the FoundryBuildTargetProvider. This is mostly plumbing for upcoming features.

  • The new template format is a bit of amalgamation from a few formats that is just based on my experience trying to find a way to maintain these templates.

    It starts with a GKeyFile block that describes the template and inputs to the template.

    Then you have a series of what looks like markdown code blocks. You can have conditionals around them which allows for optionally including files based on input.

    The filename for the blocks can also be expanded based on template inputs. The expansions are just TmplExpr expressions from template-glib.

    An example can be found at:

    https://gitlab.gnome.org/GNOME/foundry/-/blob/main/plugins/meson-templates/library.project

Template-GLib

  • Found some oopsies in how TmplExpr evaluated branches so fixed those up. Last year I wrote most of a C compiler and taking a look at this code really makes me want to rewrite it all. The intermixing of Yacc and GObject Introspection is ripe for improvement.

  • Added support for == and != of GStrv expressions.

Other

  • Play CI whack-a-mole for ICU changes in nightly SDKs

  • Propagate foundry changes to projects depending on it so that we have useful flatpak manifests with minimal feature flags enabled.

  • Took a look at some performance issues in GNOME OS and passed along some debugging techniques. Especially useful for when all you got is an array of registers and need to know something.

  • Libpeas release for GNOME 49 beta

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.