Open Forms is now 0.4.0 - and the GUI Builder is here

A quick recap for the newcomers

Ever been to a conference where you set up a booth or tried to collect quick feedback and experienced the joy of:

• Captive portal logout
• Timeouts
• Flaky Wi-Fi drivers on Linux devices
• Poor bandwidth or dead zones

This is exactly what happened while setting up a booth at GUADEC. The Wi-Fi on the Linux tablet worked, we logged into the captive portal, the chip failed, Wi-Fi gone. Restart. Repeat.

We eventually worked around it with a phone hotspot, but that locked the phone to the booth. A one-off inconvenience? Maybe. But at any conference, summit, or community event, at least one of these happens reliably.

So I looked for a native, offline form collection tool. Nothing existed without a web dependency. So I built one.

Open Forms is a native GNOME app that collects form inputs locally, stores responses in CSV, works completely offline, and never touches an external service. Your data stays on your device. Full stop.

What's new in 0.4.0 - the GUI Form Builder

The original version shipped with one acknowledged limitation: you had to write JSON configs by hand to define your forms.

Now, I know what you're thinking. "Writing JSON to set up a form? That's totally normal and not at all a terrible first impression for non-technical users." And you'd be completely wrong, to me it was normal and then my sis had this to say "who even thought JSON for such a basic thing is a good idea, who'd even write one" which was true. I knew it and hence it was always on the roadmap to fix, which 0.4.0 finally fixes.

Open Forms now ships a full visual form builder.

Design a form entirely from the UI - add fields, set labels, reorder things, tweak options, and hit Save. That's it. The builder writes a standard JSON config to disk, same schema as always, so nothing downstream changes.

It also works as an editor. Open an existing config, click Edit, and the whole form loads up ready to tweak. Save goes back to the original file. No more JSON editing required.

Libadwaita is genuinely great

The builder needed to work well on both a regular desktop and a Linux phone without me maintaining two separate layouts or sprinkling breakpoints everywhere. Libadwaita just... handles that.

The result is that Open Forms feels native on GNOME and equally at home on a Linux phone, and I genuinely didn't have to think hard about either. That's the kind of toolkit win that's hard to overstate when you're building something solo over weekends.

---

The JSON schema is unchanged

If you already have configs, they work exactly as before. The builder is purely additive, it reads and writes the same format. If you like editing JSON directly, nothing stops you. I'm not going to judge, but my sister might.

Also thanks to Felipe and all others who gave great ideas about increasing maintainability. JSON might become a technical debt in future, and I appreciate the insights about the same. Let's see how it goes.

Install

Snap Store

snap install open-forms

Flatpak / Build from source

See the GitHub repository for build instructions. There is also a Flatpak release available .

What's next

• A11y improvements
• Maybe and just maybe an optional sync feature
• Hosting on Flathub - if you've been through that process and have advice, please reach out

---

Open Forms is still a small, focused project doing one thing. If you've ever dealt with Wi-Fi pain while collecting data at an event, give it a try. Bug reports, feature requests, and feedback are all very welcome.

And if you find it useful - a star on GitHub goes a long way for a solo project. 🙂

Open Forms on GitHub

The GNOME Foundation has selected the first recipients who will receive funding through its new Fellowship program , and is delighted to announce that Peter Eisenmann and Sophie Herold will begin work as our first Fellows in July.

Sophie and Peter are both long-running GNOME contributors, with many significant contributions as members of the GNOME community. Sophie is known as developer of apps, libraries, and websites, including Loupe, Pika Backup, Glycin, and welcome.gnome.org . Peter is a long-standing Nautilus maintainer (officially known as the Files app), as well as an experienced contributor to platform libraries, including GTK and GLib.

Both Fellows will spend time working to enhance the long-term sustainability and health of the GNOME project. Sophie will be working to establish a new RFC process for GNOME, which will enhance our project-level governance. She will also be working on more maintainable and secure libraries through Rust adoption. Peter will work to modernize many aspects of the Files app, including thumbnailing, user directory localization, and the use of modern GNOME platform conventions.

Congratulations to Peter and Sophie – we’re genuinely excited to see what you’ll achieve as our first Fellows, and proud to be supporting your work.

We’d also like to take this opportunity to thank everyone who submitted applications to the first round of the Fellowship. We received some genuinely excellent proposals, and would strongly encourage unsuccessful applicants to apply again in future rounds.

Peter and Sophie’s work is made possible by the generosity of GNOME’s supporters. If you’d like to help fund future rounds and support contributors like them, please consider donating .

Terry Godier wrote a beautiful essay "The Boring Internet" . The internet isn't dying, he argues, just the commercial veneer glued on top of it is. Underneath all the engagement metrics and algorithmic feeds, there's still an older, slower, more federated web. One built on protocols nobody owns. RSS feeds still work (thank you, Aaron), people can set up websites and blogs.

Lets start a webring in 2026

Don't worry, I haven't pushed too many pixels and gone a little cuckoo. But it's a fun exercise to remind what the web once was. We'll silently skip over the fact that I actually started using gopher first, but even web surfing didn't begin on a search engine back in the day. It was web rings , later followed by index sites.

Start

Not long ago I posted about designing app icons for 3rd party GNOME app developers . The post generated quite some buzz and some old and new faces started showing up to help with the backlog. So obviously I'd like to take you on a webring tour of all the designers responsible for making the GNOME app ecosystem a little less awkward to browse on Flathub .

Let me introduce you to Brage. He's been around for a couple of years now, helping to tame the flames of the reddit community , helping with the GNOME Circle project to improve the quality of GNOME apps in the wild, creating illustrations for initial states in apps, authoring some noteworthy apps himself . So thank you, Brage, welcome to the 90s!

Next Up: Brage Fuglseth

Linux App Summit 2026 Social Media Retrospective

This is my personal retrospective post – there will likely be some version of this that will go out to various stakeholders.

I want to start off by giving huge praise to our organizing team that worked really hard this year in putting this event together. Couldn’t ask for a better team to work with. Our organizing team is a mix of KDE and GNOME people.

This post will focus on the outreach, fundraising, and social media campaign since that was the bulk of the work I did for LAS this year.

Linux App Summit (LAS) for those who don’t know is a conference organized around the goal of encouraging developing apps on the Linux platform. With
the advent of technologies like Flatpak, we had the technology to be able to ship apps directly to users instead of through the distros. Opening
an opportunity for a bi-directional relationship between app developers and the users of their apps.

This year marks the 10th year I’ve been involved in organizing LAS and its previous incarnation, LAS GNOME. LAS is organized jointly by GNOME and KDE who help fund and promote the conference jointly. It is a showcase of how we can unite and do impactful things.

I was not able to attend this year due to other commitments. I hope other who did attend will weigh in and let us know how it was in-person.

Let’s get to it!

Challenging Myself

I wanted to challenge myself this year and really bring in the kind of engagement  that I could be proud of. I’ve not really had the kind of time I wanted to work on this and it was time to really focus and see what could be done with a proper plan. The goal I wanted to take myself is driving awareness and growing attendance on what our app ecosystem is doing.

What does that entail?

Improving our social media game

The underlying problem I have identified is that Linux and apps was not getting into the headspace of developers. It still felt that this conference was unknown even in our own spaces. We need to break out of Mastodon and start exploring different platforms and content.

In previous years, we were using Buffer since it was free but it was really difficult and unwieldy. We could only schedule 3 days in advance and at times the posts would just drop. We needed to first change the tools we used to really improve our engagement with the world.

With help from the sysadmins at the GNOME Foundation (thank you, GF and Andrea Veri and Bart!), we were able to install Mixpost a self-host social media platform. The two great things about Mixpost is 1) analytics of the posts and social media platforms we were active on and not so active on 2) have a workspace around all our social media accounts and have a team of people working in it with an editorial flow and content calendar. This allowed us to share the workload of posting among many members. For instance, when I wasn’t around, Aryan Kaushik was able to take it over and post. Mixpost is now also being used for various GNOME’s accounts as well. The software continues to improve and hopefully they’ll get around to single-signon support.

With the ability to actually have metrics, the next step is to actually take goals for each of the social media accounts we had and see if we could meet them. Below is a table of the targets I took and the results from February 2026 – May 2026. Instagram was actually started in the beginning of May.

Social Media	Start Count	Target Count	Result
Mastodon	596	796	926
LinkedIn	534	700	619
BlueSky	0	100	39
YouTube	1420	N/A	1610
Instagram	0	N/A	42

Overall, I think we did ok! The high count for Mastodon was because of the great work of the GNOME and KDE accounts on mastodon boosting our posts and helping promoting them before, during, and after LAS. I noticed doing things like polls on mastodon got a lot of attention without needing boosts from the other accounts.

We had decent engagement on LinkedIn. Certainly better than in the past. The trick though is that LinkedIn requires a different lens when you post. Since it is mostly focus on B2B and B2C type of messaging you need to write them differently. I didn’t do it this time because writing social media posts is hard and takes a lot of time and thought.

I didn’t take any goals for YouTube since we did not conceive that we would create content targeted for YouTube. In a spur of the moment, I did a ‘podcast style’ conversation between Matthias Clasen and myself talking about LAS. That gave us about 354 views. Which was encouraging and gives us some idea how organic content on YouTube would be received.

Bluesky was a new account for us. So we started with zero. We gained 39 followers. That might not seem like a lot given the time frame but BlueSky is an interesting platform when it comes to engagement. You can get quite a bit of engagement even if the follower count is low. I think given more time on the platform we’ll be able to make that 100+ if we keep posting content. I think hashtags matter here and playing with the right kind of hashtag and content matters. Bluesky is also was a great experiment when you didn’t have big accounts like GNOME and KDE boosting you.

The media partners we had 9to5Linux, Tuxdigital, It’s FOSS, and Linux Magazine all helped in this regard by using their accounts boost our posts in these other platforms and give us visibility. Thank you to our media partners for helping out and we hope we can work with them closer next year. I’ll like to engage with them further to see how we can help each other out including contributing content. Another idea is to reach out to the speakers of these talks and get them to write some articles that could be contributed based on their talks.

Finally, Instagram. This is an untapped gold mine. I was skimming through the platform looking for GNOME/KDE/Linux desktop type posts to see how well content did. Saw one young lady, who showed off her GNOME desktop with some caption and it gave her 130k views. It was about 10 seconds long. That was impressive. I posted a short video talking about Linux App Summit, and while I got about 130 views – the analytics said most stopped watching after 9 seconds of the 4 minute video I posted. That hurt my pride. I resolved to do better and get better engagement with a 10-15 second video that packed more information and visually more stimulating. As of now the LAS account is still gaining followers despite not posting for 2 weeks. Once again, the media partners helped by liking my posts while the other accounts lay idle.

Working with YouTube Influencers

One other aspects of my plan on boosting the visibility of LAS was to start working with influencers on various platforms. I made a few attempts with a few I knew but was only able to get on one podcast – Tux Digital . Michael Tunnell was kind enough to invite Aleix Pol and myself on his show. For an hour and half, we answered questions and did some bantering. We even went in some organic directions that was fun! I know I had fun, I hope Aleix did too. The exposure was pretty good with approximately 8k+ views for that episode that was 90 minutes. The feedback to the video was very positive with many resolving to attend the conference. Unfortunately, I didn’t set up utm links so that I know where people came from.

Through social media and influencers, we hoped to break out of our media ecosystem and branch out to platforms that developers and Linux enthusiasts hang out and consume content. Meeting where developers are needs to be something we will need to focus on going forward.

Results

The in-person conference was a success, we had 110 people at the conference, the venue capacity was 100. We had 156 people who registered for the conference, this is about a 71% conversion rate. The industry average for free  in-person events is 50%. For LAS, this is unprecedented because we usually had a much worse turnover rate historically. At one point, a few years ago I had started looking into doing registration fees to give people some reason to go and not ghost the conference.

For online this year, we had about 50 online registrations  but it’s hard to gauge anything about online participation since we freely published the YouTube link on social media.

The results for the conference for online had the following results on YouTube :

	2025	2026
Day 1 Views	922	1.7k
Day 2 Views	485	1.5k

The above numbers show views within the 24 hour period of each day. These are really good numbers where we’ve more than doubled our viewership on one of the two days compared to last year. Ostensibly, it shows that our social media did build awareness.

Here is the (still increasing) numbers as of now on Youtube:

First Day: 2k views
Second day: 2.7k views

The videos are currently being broken up into individual talks. But the individual talks as of now are averaging about 300 views or so with the top one being 900+ views for Lennart’s keynote.

The aggregate views for all the 13 individual talk videos posted so far is 4.9k. If we combined that with the combined 2k and 2.7k views, we can simplistically (mathematically speaking) would be 9.6k. Interestingly enough, that is not a big difference from the 8k views of Tux Digital podcast that Aleix and I were on. 😀

In regards, to the people who attended Linux App Summit, 16 people filled out the surveys and by in-large most of the people who attended heard about LAS through word of mouth and not so much through social media. So, that’s an interesting data point. I expect that is because of people like Lorenz Wildberg (thank you!) who did on the ground outreach.

Interestingly, enough our online views were quite good compared to say SCALE which peaked at 7.1k views for one talk but in general the average views was less than the average views than at LAS. Our subject matter is increasingly important.

Also to be clear, views do not translate to people.

Looking towards 2027, we’ll want to increase our in-person attendance while doubling our online views. Something we will be focusing on when we organize for next year.

Next Steps

Our organizing team will be posting relevant individual talks on social media once all the individual videos have been posted. I hope you all share those with everyone.

Secondly, we would love to add more people to our organizing team. Specifically, in order to really build out our outreach we need a lot more people to help network and reach out to developers from different communities and different platforms. This way we can start building relationships with other desktop projects, app developers, game developers, designers not just from Linux but from other platforms as well. For that we need a small army of advocates.

Gom is a very old object mapper I wrote to bridge GObject to SQLite . It made a lot of assumptions about the world based on when it was prototyped.

The past couple years had me using it again for the documentation search in Manuals . Typically, I would have just built Manuals to parse all the XML files on disk and hold them in memory. That’s how both Devhelp and Builder always did things. Once we started supporting Flatpak SDKs that was no longer realistic. You could have numerous SDKs all with copies of the overlapping data and it just became easier to have a query model.

One of the more performance critical limitations was the locking model. When gom-1.0 was written, it was not common for distributions to compile SQLite with locking support. So you just created a single thread and did your work over there.

Bolting fulltext search and many other missing features onto the old ABI just wasn’t realistic. Especially when I’ve wanted to make the thing properly async for years. One of my other projects, Libdex is just right over there and perfect for this sort of problem.

The landscape changed and so do our horizons.

A new informed ABI

In the years after Gom was prototyped, I worked at a commercial database company and learned a great deal about implementing the internals of both that database and more traditional RDBMS. That left a certain cringe on my mouth whenever looking at my code predating it. Knowing how things get done inside the database allows for building better APIs to interact with it.

This time everything is async. Queries are modeled like you do with a compiler. Lowered into the back-end specific implementation. There can be an entity map and real transactions which allows you to read back the same instance despite which query inflated it.

The Center

Your early stage objects are the GomRepository , GomDriver , and GomRegistry .

The registry describes the entities that can exist within the repository. This is handy because it allows us to pre-compile information into a model that is both immutable and fast at runtime. Compare that to methods like g_object_class_list_properties() which is a performance bottleneck of its own.

The driver is very obvious. It is our abstraction layer for the database engines. Currently we have support for SQLite and PostgreSQL .

The repository is the center of the center. It is how you query, insert, update, delete, transact, and more. It is likely your application instance owns one of these unless of course you use Gom as your file format in which case you’ll have one per “document”.

Two Access Models

This new version of Gom can support either the entity mapping you’re used to or; optionally, raw access to relations/projections via the GomCursor .

As the cursor moves through the resulting rows you will have access to all the projections requested in the query. Though it holds enough information to allow you to gom_cursor_materialize() the row into an GomEntity subclass.

If you want a snapshot of that cursor row without materializing, you can use GomRecord which can also conveniently be used in GListModel for integration into GTK applications.

Most of the time, you’ll use materialization. And even then it is likely to happen through automated collections rather than with a cursor directly. More on that later.

Sessions

As I mentioned, there was no concept of transactions previously.

In this iteration we have GomSession . It is your standard identity-map layer with transaction-scoping. If you perform multiple queries for the same record, the session will ensure you get the same instance back. hat is essential when you do local mutations on an instance and what to see that reflected in followup queries.

Additionally, it makes it nice to have multiple views of an object with an editor or listview and needing them to stay in sync.

Relationship Modeling

Support for relationships was adhoc previously. We had some functions named in ways that made you think you could, but I assure you, they were not well tested.

This time around you can model your GomEntity with 1:1, 1:M, M:M, inverse, self-referencing, all while handling proper delete rules. Combing this with the session support mentioned previously is crucial.

So now you should be able to show related models easily in GtkListView while keeping the paginated-and-lazy model beneath it transactional.

Migrations

In the previous version migrations were dynamic, but largely controlled by Gom itself. Very inflexible.

This time around we have things broken down into Migrator and Migration .

You can use built-in implementations like the EntityMigrator or implement your own. CustomMigrator makes that easy. Especially since you can inject your own migrations at just the right point.

Internally, libgom-2 can snapshot your GomRegistry at specific versions based on the provided metadata. Then it performs a diff between two versions of the registry to determine what migration work must be done.

You can just as easily use a SqlMigration with custom SQL scripts. This stuff is all highly composable now to get exactly what you need.

Live List Models

I’ve written many ways to get live SQLite results into GTK over the past two decades. I think one of the first was a GtkTreeModel implementation for GTK 2 which could do it. With that in mind, it was still rather annoying when making Manuals so I set off to make that convenient.

We have GomRecordListModel , GomEntityListModel , GomRelatedListModel , GomQueryModel all of which have practical uses based on application needs.

But in short, most of those are lazy and support transaction-backed stable identities for entities. Very useful when you have a list of items and an editor loaded in another frame, both of which must reflect the same data.

Expression Trees

This time around I implemented proper expression trees. They model the query, relations, and projections in a manner that allows the driver to lower into a query much more accurately.

You can model things like function-calls cleanly all of which required writing manual SQL before. If you did anything outside of what gom could generate previously, it became madness to maintain.

Vectors

This version of libgom embeds the vec1 extension for SQLite. That means we can store vectors in your records and query them. GomVector makes that easier to manage as a property within your application entity.

I can think of a few things this will be useful for, maybe you can too .

Profiling

This version of libgom has profiling support with another project of mine, Sysprof . The whole library emits profiler marks about what is going on so that it is easy for you to figure out why something might be slow in your application.

Since we’ve already done the integration of Sysprof into GLib/GObject, GTK, Pango, Libdex, and GNOME Shell/Mutter you can very quickly get an idea with details of what is going on in your application. Click record, select the problem area, zoom, and it is often pretty clear. You can have flamegraphs, callgraphs, and timing marks all in one place.

Local First with Sync Coordination

One of my personal motivations for this is around building a native sync protocol for applications I’m building. I wrote numerous SQLite-based sync protocols for the now defuct catch.com before they were acquired by apple. That means I know multiple wrong ways to do it.

This time around, I want to put it right in the data-mapper at the point where you have the most insight. So libgom has the right abstractions in place to build that. The GomSyncCoordinator manages the process and GomSyncTransport is the abstraction-point for service integration.

You work with GomDelta at this layer. The application can provide you with a GomMergePolicy to help make decisions which allow for contextually doing the right thing.

This part is still very new. I’m still building the other side of it but landing the shape early allows me to mock and test things comprehensively before committing to the ABI.

My goal is building a practical, robust, and correct implementation for personal local first features.

A small personal note: as I wrote in my recent update from France , I am no longer employed by Red Hat. Work like this is currently self-funded, out of pocket, while my family and I settle into a new chapter. If you find it useful, a note of encouragement or a contribution means a lot right now. It helps make it possible to keep improving the free software infrastructure many of us rely on.

Many GNOME projects have adopted a policy banning all contributions generated by LLMs . This policy was originally developed by Sophie for Loupe, but is now used in many other notable places:

This project does not allow contributions generated by large languages models (LLMs) and chatbots. This ban includes, but is not limited to, tools like ChatGPT, Claude, Copilot, DeepSeek, and Devin AI. We are taking these steps as precaution due to the potential negative influence of AI generated content on quality, as well as likely copyright violations.

This ban of AI generated content applies to all parts of the projects, including, but not limited to, code, documentation, issues, and artworks. An exception applies for purely translating texts for issues and comments to English.

AI tools can be used to answer questions and find information. However, we encourage contributors to avoid them in favor of using existing documentation and our chats and forums . Since AI generated information is frequently misleading or false, we cannot supply support on anything referencing AI output.

I won’t attempt to argue that you should allow use of AI for writing code. If you wish to ban LLM-generated code, fine. That’s probably inadvisable, but I am not going to object.

But this policy is far stricter than that. Notably, it strictly prohibits AI-generated content in issue reports (except to translate text). Don’t do this! Prohibiting bug reports is stupid and just makes your software worse. Please make sure your project’s AI policy allows for at least AI-generated static analysis results and AI-generated vulnerability reports. Otherwise, you prohibit entirely unobjectionable problem reports.

It’s hard to imagine what could possibly be the value of prohibiting valid bug reports. AI-generated static analysis works well: the AI is able to think about your code, follow execution paths, and automatically discard most false positives to avoid bothering you with them, and the quality of reports is generally pretty high. They are far from perfect, but the same is true of humans.

Here is a typical example of an AI-generated static analysis finding:

2. Resource leak in update_credentials_cb on gnutls_credentials_set failure

  File: tls/gnutls/gtlsconnection-gnutls.c:169-172

  When gnutls_credentials_set() fails, the function returns without calling g_gnutls_certificate_credentials_unref(credentials). The credentials was either freshly allocated or ref-bumped, so it leaks.

Pasting this into an issue report clearly violates the ban on AI-generated content. And yet, why would you not want to receive a clear and concrete bug report for memory leak?

I understand not all maintainers are fond of AI, but is your dislike really so extreme that you would choose to ignore valid problems and intentionally make your software worse? If not, then your AI policy should thoughtfully consider how to handle AI-generated content in issue reports. Certainly do not adopt a policy that outright bans all AI-generated content in issue reports.

As an issue reporter, you could theoretically take the problem found by the AI and rephrase all the words, then claim that it is no longer AI-generated content because it is rewritten it. This is a waste of time and usually results in a lower-quality, less-detailed result, but you could plausibly do that. Or, if you want to go above and beyond, you could just jump ahead to creating a merge request. But realistically, if your project does not allow any use of AI in issue reports, it’s more likely that either (a) you won’t receive the issue report in the first place, or (b) you won’t receive such issue reports from experienced developers who read and respect your policy, while users who do not read your policy will continue to submit them.

What about security vulnerability reports? Since the start of this year, I have reviewed well over 100 vulnerability reports that I strongly suspect were generated by AI. To reach the “over 100” claim, I sadly only considered vulnerability reports submitted during a particularly heavy four week period, so this is an extremely loose lower bound. Suffice to say, I have seen a lot of them. The quality varies dramatically. Vulnerability reports are now often better or worse than before: better because an experienced human working with a good AI is able to find vulnerabilities that would have surely gone unnoticed without A I, and worse because an inexperienced human with a bad AI might create some pretty terrible issue reports, a significant proportion of which are just outright spam. Low-quality reports remain a problem, but nowadays most AI-generated issue reports are quite good.

Maintainers do not need to tolerate spammy vulnerability reports. If an issue report is bad, of course go ahead and close it. If it’s really bad, then I sometimes don’t even bother replying. But banning good vulnerability reports solely because some portion of the report was generated by AI is unacceptable. AI-assisted vulnerability reports are the new industry standard, and this is not likely to change. Prohibiting issue reports reduces the quality and safety of your software, punishing your users. This is too extreme.

Fibers are always a nice way to keep your async C code clean while using Libdex. However, occasionally you may want a lighter option which doesn’t require a stack or saving registers for work doing little more than coordinating futures.

I’ve added Stackless Coroutines for this which still allows writing future-coordinating code. Though this will suspend/resume your coroutine by re-entering the function and jumping to the next position. Your threads stack is reused. State is saved in your closure state.

This isn’t a new concept. It is really old just like fibers. What is useful is that this style of continuation passing may still be represented as a DexFuture and therefore composed like the others.

You can place these stackless coroutines in DexTaskGroup alongside fibers, threadpool work, and others. Cancellation will propagate to a clean exit point of the coroutine just like it would with a fiber.

Overhead is a bit lower than fibers in synthetic benchmarks depending on use. I was actually impressed our fiber implementation performed as well as it did head-to-head.

To make building your coroutine continuation easier, libdex provides a handy macro to create your typedef struct , _new() , and _free() helpers in a single macro expansion using DEX_DEFINE_CLOSURE_TYPE() .

You use it like this:

DEX_DEFINE_CLOSURE_TYPE (MyTaskState, my_task_state,
  DEX_DEFINE_CLOSURE_VALUE (gsize, bytes),
  DEX_DEFINE_CLOSURE_POINTER (GBytes *, bytes_obj, g_bytes_unref),
  DEX_DEFINE_CLOSURE_OBJECT (GSocketConnection, conn))

Coroutines cannot use the exact syntax that fibers do for awaiting, which is a bummer, but a side-effect of trying to make something that works across Linux, Windows, FreeBSD, Solaris, macOS, etc. Particularly because the implementation must use switch / case to stay portable without address-of-label support on MSVC nor clang-cl.exe .

So awaiting is a bit more clear you’re suspending/resuming the stackless coroutine.

DEX_DEFINE_CLOSURE_TYPE (LoadState, load_state,
  DEX_DEFINE_CLOSURE_OBJECT (GFile, file),
  DEX_DEFINE_CLOSURE_OBJECT (GFileInputStream, input),
  DEX_DEFINE_CLOSURE_OBJECT (GFileInfo, info),
  DEX_DEFINE_CLOSURE_VALUE (int, io_priority))

static DexFuture *
do_something (DexCoroutineContext *context,
              gpointer             user_data)
{
  LoadState *state = user_data;
  g_autoptr(GError) error = NULL;

  DEX_COROUTINE_BEGIN (context);

  DEX_COROUTINE_SUSPEND_OBJECT (
    &state->input, &error,
    dex_file_read (state->file, state->io_priority));

  if (error != NULL)
    return dex_future_new_for_error (g_steal_pointer (&error));

  DEX_COROUTINE_SUSPEND_OBJECT (
    &state->info, &error,
    dex_file_input_stream_query_info (
      state->input,
      G_FILE_ATTRIBUTE_STANDARD_SIZE,
      state->io_priority));

  if (error != NULL)
    return dex_future_new_for_error (g_steal_pointer (&error));

  /* maybe do something useful here */

  return dex_future_new_int64 (g_file_info_get_size (state->info));

  DEX_COROUTINE_END;
}

You do need to be careful about placing things on the stack, because they wont be there on the other side of that DEX_COROUTINE_SUSPEND_* macro expansion. That is because when the scheduler jumps back into your stackless coroutine, it will use a switch / case to jump to the next bit of code. Don’t fear though, just add your state to your continuation which we’ve established is easy to do now.

If you don’t like these macros, you can do things the manual way using dex_coroutine_context_suspend() and dex_coroutine_context_resume() who’s APIs are not terrible either. They do require you make up your own program-counter regime though which for the macro case is basically just __COUNTER__ .

You can spawn your coroutine using dex_scheduler_spawn_coroutine() or as part of a work-queue in DexLimiter with dex_limiter_run_coroutine() .

dex_scheduler_spawn_coroutine (
  dex_thread_pool_scheduler_get_default (),
  my_coroutine,
  my_coroutine_new (),
  (GDestroyNotify) my_coroutine_free);

I hope you've enjoyed this attempt to make another 1970s technology useful in a modern world.

One of the many nice language features in Python are keyword arguments. They make some types of APIs  concise and readable. Like so:

Unfortunately C does not have keyword arguments and, by extension, neither does C++. Adding them as a language feature would take 15-20 years of effort, most of which would consist of trying to convince people via email that such a feature is important and should be added.

There have been attempts to implement this via macros and template magic ( link ), but they have not seen widespread usage probably because they are using macros and template magic. However it turns out that with modern language features you can fake keyword arguments fairly convincingly. Like so:

The add_argument method takes a single argument which is a struct. The extra curly braces inside the parentheses boil down to "whatever the underlying argument is, construct it in place with these parameters". The dotted names are designated initializers, so those fields get the specified value whereas other fields get their default values.

And there you go, keyword arguments in C++. You just have to squint a bit and pretend not to see the extra curly braces.

As in previous years, This Week in GNOME and this entire month are dedicated to the joys and struggles of all two-spirit, lesbian, gay, bi, trans, queer, inter, pan, asexual, aromantic, and non-binary people. We celebrate the invaluable work and life of all 2SLGBTQIA+ contributors and users, across all backgrounds and experiences.

Attempts to divide queer communities are not stopping. Fundamental human rights, hard-won over decades of struggle, are still under attack.

But we are here and we are not going anywhere. The GNOME community stands with queer people, now and always.

Together we are stronger.

GNOME Core Apps and Libraries

File Previewer ↗

A previewer companion for GNOME Files.

Peter Eisenmann reports

The last few weeks have been busy for sushi , the previewer companion for nautilus. Not only did Corey Berla’s GTK4 port finally land, but on top of that Tau Gärtli, Nokse and myself have made several modernizations. The major changes are:

• Dark mode support
• GTK4, libadwaita, glycin and (initial) Blueprint usage
• Rework layout of several previewers
• Nicer floating toolbars
• Modernize code to use EcmaScript modules
• Cleaned up deprecated function usages

You can test these changes in GNOME OS or by installing sushi and nautilus from the gnome-nightly Flatpak repository.

Greetings from GPN in Karlsruhe!

GJS ↗

Use the GNOME platform libraries in your JavaScript programs. GJS powers GNOME Shell, Polari, GNOME Documents, and many other apps.

JumpLink announces

I’m currently working on a TypeScript framework for GJS called gjsify , and it has just hit a new milestone: the TypeScript compiler (v6.x) now runs directly inside GJS, so Node.js is no longer needed to run tsc . Just install gjsify and invoke it with gjsify tsc . Beyond tsc , there are other handy commands too, like gjsify install as a drop-in replacement for npm install , all running natively in GJS.

Third Party Projects

Mikhail Kostin says

Vinyl v1.4.0 has been released ! There is a lot of changes since v1.3.2. Over the course of a month, I tried to do as much work as possible on the functionality and accessibility of the player. I also want to say with confidence that Vinyl is the first GNOME music player with the ability to read lyrics directly from an ID3v2 tag.

Here is the list of changes that the app has undergone:

• Added opportunity to synced parse lyrics directly from ID3v2 tag
• Added a lot of shortcuts, for playback and UI
• Added functionality for a more detailed scan of covers (Ability to read covers separately for each track)
• Added a button to open the current directory for the playing track
• Added search by audio extension
• Added tooltips
• Changed track sorting, tracks are now sorted first by folder location rather than by tags
• The player has been localized into many languages ​​including German, Hindi, Czech, Slovak, Kazakh, Uzbek, Polish and Swedish

Today you can see the new version of the Vinyl on Flathub

balooii reports

First release of Contributor Atlas!

Contributor Atlas is a set of interactive visualizations that bring a project’s contributor history to life. It’s aimed at projects with a long legacy of contributors.

I built it for GIMP and its ecosystem, with nearly 30 years of contributors to explore, but the graphs are generic - you might find it useful for your own project too.

Explore the live GIMP dataset at the link below. I hope you find it as interesting as I do! https://contributor-atlas-4dab97.pages.gitlab.gnome.org

You can find the project at https://gitlab.gnome.org/balooii/contributor-atlas

mohfy says

This week i’ve released v2.0.0 of Quizbite, Quizbite is an educational app that let you create quizzes with multiple choice questions, play them and share them with your friends!

You can also export the quiz to PDF, where you can print the quiz if you want to study offline.

In version 2.0.0 we’ve added search for quizzes, added ability to review mistakes after taking the quiz, ability to edit a quiz after creation, and some fixes.

Get Quizbite on Flathub: https://flathub.org/en/apps/dev.mohfy.quizbite

Gitte ↗

A simple Git GUI for GNOME

Christian says

Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.6.0 release! 🎉

The headline feature this time is per-file stash operations: you can now apply, pop or drop individual files from a stash via handy context-menu entries, and stash only the files you’ve selected in the working copy view, instead of always stashing everything.

Commit messages also got a lot more interactive. URLs are turned into clickable links, #<id> and !<id> mentions are linkified for known forges, and authors and committers show up as mailto: links. After pushing to a known forge, Gitte now offers a “New merge / pull request” link button so you can jump straight to creating one.

There are new shortcuts to hide untracked files ( Ctrl+Shift+H ) and to toggle untracked directories without recursing into them, and the staged/unstaged sections in split view are now collapsible, with an option to reverse their order.

Under the hood the working copy view got a performance overhaul: Gitte can now browse the Linux kernel repository with 10k changed files with ease.

Gitte also resolves includeIf blocks when reading the Git configuration now. On top of that come colored pills in the branch info box, a pointer cursor on selectable diff lines, and the usual pile of smaller UI refinements and fixes.

And there’s good news for BSD folks: Gitte is now available in the FreeBSD ports tree, so you can install it via pkg install deskutils/gitte .

Get it on Flathub , for macOS or have a look at the Code .

Miscellaneous

GNOME OS ↗

The GNOME operating system, development and testing platform

Felicitas Pojtinger says

The documentation for contributing to GNOME Build Metadata (the project which builds things such as GNOME OS, the GNOME Flatpak runtimes and GNOME OCI images) got a big overhaul! If you ever wanted to build your own version of GNOME OS, want to make changes to your running GNOME OS system or fix a bug you’ve found somewhere, or if you’re just curious and want to learn more about how BuildStream, systemd-sysupdate/sysext or the Flatpak runtimes work, now is a great time to try it out! The new CONTRIBUTING.md document is a good place to start: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/blob/master/CONTRIBUTING.md

Damned Lies ↗

The internal application to manage localization of GNOME & friends modules

Guillaume Bernard announces

A few changes for Damned Lies arrived this week! Our translation platform has received two external contributions, and we have very cool new features:

• @kristjan.esperanto added a dark theme to Damned Lies. You now have the possibility to switch between dark and light themes, or use the auto-mode that will follow your browser and desktop default theme.

• @balooii implemented a feature to better reward contributors who work on a workflow. The current implementation of the commit action only mentions the author of the translation and the committer. With this change, all volunteers who worked on a translation workflow are mentioned in the commit message with Translated-by , Reviewed-by , and Contributed-by credits.

Then, we have a fix from another contributor, @codeurluce who started contributing with a newcomer feature to fix a glitch in the interface.

I also took the opportunity to work a bit on the Deneb theme that Damned Lies uses to enhance the contrast of the different buttons and elements. The gnome-boostrap-theme received a few updates that are now reflected in Damned Lies. As usual, if you find something odd, please report issues!

Finally, in the diff view (the one you see on vertimus workflows) between a file and a previous version of a PO file, you now see some of the non-printable characters, like newlines, tabs, or non break spaces. If you use some in your language you’d like to have, just ask!

This was a very intense week for Damned Lies, and if you’d like to plant a seed in the i18n ecosystem, please open an issue, contact us on the #i18n:gnome.org channel or ask for new features!

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!