call_end
    • Pl chevron_right

      Philip Withnall: Parental controls screen time limits backend

      news.movim.eu / PlanetGnome • 3 days ago - 23:39 • 4 minutes

    Ignacy blogged recently about all the parts of the user interface for screen time limits in parental controls in GNOME. He’s been doing great work pulling that all together, while I have been working on the backend side of things. We’re aiming for this screen time limits feature to appear in GNOME 50.

    There’s a design document which is the canonical reference for the design of the backend, but to summarise it at a high level: there’s a stateless daemon, malcontent-timerd , which receives logs of the child user’s time usage of the computer from gnome-shell in the child’s session. For example, when the child stops using the computer, gnome-shell will send the start and end times of the most recent period of usage. The daemon deduplicates/merges and stores them. The parent has set a screen time policy for the child, which says how much time they’re allowed on the computer per day (for example, 4h at most; or only allowed to use the computer between 15:00 and 17:00). The policy is stored against the child user in accounts-service .

    malcontent-timerd applies this policy to the child’s usage information to calculate an ‘estimated end time’ for the child’s current session, assuming that they continue to use the computer without taking a break. If they stop or take a break, their usage – and hence the estimated end time – is updated.

    The child’s gnome-shell is notified of changes to the estimated end time and, once it’s reached, locks the child’s session (with appropriate advance warning).

    Meanwhile, the parent can query the child’s computer usage via a separate API to malcontent-timerd . This returns the child’s total screen time usage per day, which allows the usage chart to be shown to the parent in the parental controls user interface ( malcontent-control ). The daemon imposes access controls on which users can query for usage information. Because the daemon can be accessed by the child and by the parent, and needs to be write-only for the child and read-only for the parent, it has to be a system daemon.

    There’s a third API flow which allows the child to request an extension to their screen time for the day, but that’s perhaps a topic for a separate post.

    IPC diagram of screen time limits support in malcontent. Screen time limit extensions are shown in dashed arrows.

    So, at its core, malcontent-timerd is a time range store with some policy and a couple of D-Bus interfaces built on top.

    Currently it only supports time limits for login sessions, but it is built in such a way that adding support for time limits for specific apps would be straightforward to add to malcontent-timerd in future. The main work required for that would be in gnome-shell — recording usage on a per-app basis (for apps which have limits applied), and enforcing those limits by freezing or blocking access to apps once the time runs out. There are some interesting user experience questions to think about there before anyone can implement it — how do you prevent a user from continuing to use an app without risking data loss (for example, by killing it)? How do you unambiguously remind the user they’re running out of time for a specific app? Can we reliably find all the windows associated with a certain app? Can we reliably instruct apps to save their state when they run out of time, to reduce the risk of data loss? There are a number of bits of architecture we’d need to get in place before per-app limits could happen.

    As it stands though, the grant funding for parental controls is coming to an end. Ignacy will be continuing to work on the UI for some more weeks, but my time on it is basically up. With the funding, we’ve managed to implement digital wellbeing (screen time limits and break reminders for adults) including a whole UI for it in gnome-control-center and a fairly complex state machine for tracking your usage in gnome-shell; a refreshed UI for parental controls; parental controls screen time limits as described above; the backend for web filtering (but more on that in a future post); and everything is structured so that the extra features we want in future should bolt on nicely.

    While the features may be simple to describe, the implementation spans four projects, two buses, contains three new system daemons, two new system data stores, and three fairly unique new widgets. It’s tackled all sorts of interesting user design questions (and continues to do so). It’s fully documented, has some unit tests (but not as many as I’d like), and can be integration tested using sysexts . The new widgets are localisable, accessible, and work in dark and light mode. There are even man pages. I’m quite pleased with how it’s all come together.

    It’s been a team effort from a lot of people! Code, design, input and review (in no particular order): Ignacy , Allan , Sam , Florian , Sebastian , Matthijs , Felipe , Rob . Thank you Endless for the grant and the original work on parental controls. Administratively, thank you to everyone at the GNOME Foundation for handling the grant and paperwork; and thank you to the freedesktop.org admins for providing project hosting for malcontent!

    • Pl chevron_right

      Michael Meeks: 2025-11-19 Wednesday

      news.movim.eu / PlanetGnome • 3 days ago - 15:55

    • Sync with Dave, catch up with Thorsten, slides, lunch.
    • Published the next strip: The joy of elections:
    • Monthly all-hands call, admin.
    • Pl chevron_right

      Michael Meeks: 2025-11-18 Tuesday

      news.movim.eu / PlanetGnome • 4 days ago - 21:00

    • Up early, planning call, sync with Laser, slideware with Fabrice, monthly mgmt meeting, sync with Andras, admin.
    • Dinner, more E-mail and contract review in the evening.
    • Pl chevron_right

      Lennart Poettering: Mastodon Stories for systemd v258

      news.movim.eu / PlanetGnome • 4 days ago - 00:00 • 2 minutes

    Already on Sep 17 we released systemd v258 into the wild .

    In the weeks leading up to that release I have posted a series of serieses of posts to Mastodon about key new features in this release, under the #systemd258 hash tag. It was my intention to post a link list here on this blog right after completing that series, but I simply forgot! Hence, in case you aren't using Mastodon, but would like to read up, here's a list of all 37 posts:

    I intend to do a similar series of serieses of posts for the next systemd release (v259), hence if you haven't left tech Twitter for Mastodon yet, now is the opportunity.

    We intend to shorten the release cycle a bit for the future, and in fact managed to tag v259-rc1 already yesterday, just 2 months after v258. Hence, my series for v259 will begin soon, under the #systemd259 hash tag.

    In case you are interested, here is the corresponding blog story for systemd v257 , and here for v256 .

    • Pl chevron_right

      Christian Hergert: Status Week 46

      news.movim.eu / PlanetGnome • 5 days ago - 20:24 • 5 minutes

    Ptyxis

    • More back and forth on people who have issues with diacritics and ibus interaction. It’s extremely frustrating at times because the two places where stuff like this gets reported first is the text editor and terminal, when rarely those two applications have anything to do with the issue.

      In this case we might have a workaround by being a bit more explicit about focus grabs.

    • Merge support for changing profile on existing tab.

    VTE

    • Back-and-forth on updating MR for PTY errno, merge to master, vte-0-82, possibly backport further for RHEL/CentOS.

    • Research some us dead key issues with diacritics and see if we can find where in VTE a problem could be. Text Editor apparently doesn’t replicate the same issue, so it’s possible we should fix something in VTE directly or in GTK IM abstractions. As mentioned in Ptyxis we can probably work around this for now.

    Foundry

    • Now that foundry has support for API keys we need to have a mechanism to rotate those keys (and query for expiration). FoundryKeyRotator provides this abstraction to FoundrySecretService .

      This comes with foundry secret rotate HOST SERVICE which makes it easy to keep things up-to-date. It would be nice to do this automatically at some point though it’s rather annoying because you’ll get an email about it, at least from gitlab.

      To check the expiration, foundry secret check-expires-at is provided check again, takes a HOST SERVICE pair.

      Defaults to what the server wants for minimum key lifetime, or you can provide --expire-at=YYYY-MM-DD to specify expiration.

    • Implement symbol APIs for FoundryTextDocument which will power things like the symbol tree, what symbol is underneath my cursor, symbol path bars, and the like. Also added some command line tools for this so that it is easy to test the infrastructure when issues are inevitably filed.

      foundry symbol-tree FILE and foundry find-symbol-at FILE LN COL will quickly test the machinery for filing bug reports.

    • Updated the CTags parser (which is our usually “first implementation” symbol provider) out of simplicity. Allow it to generate data to GBytes instead of files on disk for usage on modified buffers. Also allow it to load an index from memory w/o touching disk for the other side of this index structure.

    • GCC changed the SARIF environment variable to EXPERIMENTAL_SARIF_SOCKET so track that for GCC 16 release.

    • Handy foundry_read_all_bytes(int fd) to exhaust a FD into a GBytes using the libdex AIO subsystem ( io_uring , etc).

    • Prototype a tree-sitter based plugin for symbol providers so we can have some faster extractors at least for some very common languages.

    • Add FoundrySymbolLocator for locating symbols by a number of strategies that can be different based on the provider. Combine this with a new FoundrySymbolIntent to integrate into the intent system.

    • Implement FoundryPathNavigator for use in future pathbar work. Add subclasses for FoundrySymbolNavigator and FoundryDocumentationNavigator to make pathbars of those common hierarchies super easy from applications. A FoundryFileNavigator to be able to navigate the file-system. This ties in well with the intent system so activating path elements routes through intents like open-file intent, symbol intent, etc.

    • Implement FoundryPathBar and associated infrastructure for it to be abstracted in libfoundry-adw.

    • Implement LSP progress operations ( $/progress and creation operations) so we can bridge them to FoundryOperation . Had to implement some missing bits of FoundryJsonrpcDriver while at it.

    • Improve support for LSP symbol APIs, particularly around support for hierarchical symbol trees. Newer revisions allow for symbols to contain other symbols rather than trying to recreate it from the containerName .

    • Discovered that there is an upper-limit to the number of GWeakRef that can be created and that number is surprisingly lower than I would expect. Sure there is extra overhead with weak refs, but having limits so low is surely a mistake.

    • Lots of work on LSP implementation to bridge things like diagnostics and symbols. It is amazing now much easier it is to do this time around now that I have fibers instead of callback noodles.

    • We have a much saner way of implementing buffer tracking this time around (especially after pushing commit notify into GTK) so the LSP integration around buffer synchronization has a cleaner implementation now.

    • Add tooltips support to the diagnostics gutter renderer.

    • A new “retained” listmodel which allows you to hold/release items in a list model and they’ll stay pinned until the hold count reaches zero. This is helpful for situations where you don’t want to affect an item while there is a mouse over something, or a popover is shown, that sort of deal. I didn’t opt for the scalable RBTree implementation yet, but someone could certainly improve it to do so.

    Buider

    • Work on the new auxiliary panel design which will work a bit like it does in Text Editor but allow for panel groupings.

    • Symbols panel implementation work using the new symbol providers. Implement symbol intent handling as well to tie it all together.

    • Implement pathbar integration into text editor and documentation browser using new navigator integration.

    • Diagnostics panel for monitoring diagnostics across the active page without having to resort to scanning around either the global diagnostics or within the gutter.

    • Add annotation provider so we can show diagnostics/git-blame like we do now but in a much more optimized manner. Having diagnostics inline is new though.

    • Lots of styling work for the auxiliary panel to try to make it work well in the presence of a grid of documents. A bit harder to get right than in Text Editor.

    • Ergonomics for the messages panel (clipboard support, clearing history, etc).

    • Work on operation bay for long running operations similar to what Nautilus does. This will handle things like progress from LSPs, deployment to remote devices, etc.

    CentOS

    • libadwaita backports. This one is rather frustrating because I’ve been told we can’t do sassc on the build infrastructure and since 1.6.3 libadwaita no longer generates the CSS on CI to be bundled with the tarball.

      So continue with the madness of about 60 patches layered on top of 1.6.2 to keep things progressing there. One patch won’t get in because of the CSS change which is unfortunate as it is somewhat a11y related.

      At the moment the options are (given the uncompromising no-sassc restriction), to keep back-porting and not get CSS changes, to pull in newer tarballs and generate the CSS on my machine and patch that in, or just keep doing this until we can *gestures* do something more compromising on the CentOS build infrastructure.

    • VTE backports for 0.78.6

    GtkSourceView

    • Branched for 5.20 development so we can start adding new features.

    • Fix a gir annotation on GtkSourceAnnotation that had wrong transfer.

    • Make GtkSourceAnnotation right justified when it fits in the available space.

    • Add some nice styling to annotations so they are bit more pleasing to look at.

    • Pl chevron_right

      Code of Conduct Committee: Transparency report for May 2025 to October 2025

      news.movim.eu / PlanetGnome • 7 days ago - 18:19 • 2 minutes

    GNOME’s Code of Conduct is our community’s shared standard of behavior for participants in GNOME. This is the Code of Conduct Committee’s periodic summary report of its activities from May 2025 to October 2025.

    The current members of the CoC Committee are:

    • Anisa Kuci
    • Carlos Garnacho
    • Christopher Davis
    • Federico Mena Quintero
    • Michael Downey
    • Rosanna Yuen

    All the members of the CoC Committee have completed Code of Conduct Incident Response training provided by Otter Tech, and are professionally trained to handle incident reports in GNOME community events.

    The committee has an email address that can be used to send reports: conduct@gnome.org as well as a website for report submission: https://conduct.gnome.org/

    Reports

    Since May 2025, the committee has received reports on a total of 25 possible incidents. Many of these were not actionable; all the incidents listed here were resolved during the reporting period.

    • Report on a conspiracy theory, closed as not actionable.
    • Report that was not actionable.
    • Report about a blog post; not a CoC violation and not actionable.
    • Report about interactions in GitLab; not a CoC violation and not actionable.
    • Report about a blog post; not a CoC violation and not actionable.
    • Question about an Export Control Classification Number (ECCN) for GDM; redirected to discourse.gnome.org.
    • Report about a reply in GitLab; not a CoC violation; pointed out resources about unpaid/volunteer work in open source.
    • Report about a reply in GitLab; not a CoC violation but using language against the community guidelines; sent a reminder to the reported person to use non-violent communication.
    • Two reports about a GNOME Shell extension; recommended actions to take to the extension reviewers.
    • Report about another GNOME Shell extension; recommended actions to take to the extension reviewers.
    • Multiple reports about a post on planet.gnome.org; removed the post from the feed and its site.
    • Report with a fake attribution; closed as not actionable.
    • Report with threats; closed as not actionable.
    • Report with a fake attribution; closed as not actionable.
    • Report that was not actionable.
    • Support request; advised reporter to direct their question to the infrastructure team.
    • Report closed due to not being actionable; gave the reporter advice on how to deal with their issue.
    • Report about a reply in GitLab; reminded both the reporter and reported person how to communicate appropriately.
    • Report during GUADEC about an incident during the conference; in-person reminder to the reported individual to mind their behavior.
    • Report about a long-standing GitLab interaction; sent a request for a behavior change to the reported person.
    • Report on a conspiracy theory, closed as not actionable.
    • Report about a Mastodon post, closed as it is not a CoC violation.
    • Report closed due to not being actionable, and not a CoC violation.
    • Report closed due to not being actionable, and not a CoC violation.
    • Report closed due to not being actionable, and not a CoC violation.

    Meetings of the CoC committee

    The CoC committee has two meetings each month for general updates, and weekly ad-hoc meetings when they receive reports. There are also in-person meetings during GNOME events.

    Ways to contact the CoC committee

    • https://conduct.gnome.org – contains the GNOME Code of Conduct and a reporting form.
    • conduct@gnome.org – incident reports, questions, etc.
    • Pl chevron_right

      Andy Wingo: the last couple years in v8's garbage collector

      news.movim.eu / PlanetGnome • 13 November • 9 minutes

    Let’s talk about memory management! Following up on my article about 5 years of developments in V8’s garbage collector , today I’d like to bring that up to date with what went down in V8’s GC over the last couple years.

    methodololology

    I selected all of the commits to src/heap since my previous roundup. There were 1600 of them, including reverts and relands. I read all of the commit logs, some of the changes, some of the linked bugs, and any design document I could get my hands on. From what I can tell, there have been about 4 FTE from Google over this period, and the commit rate is fairly constant. There are very occasional patches from Igalia, Cloudflare, Intel, and Red Hat, but it’s mostly a Google affair.

    Then, by the very rigorous process of, um, just writing things down and thinking about it, I see three big stories for V8’s GC over this time, and I’m going to give them to you with some made-up numbers for how much of the effort was spent on them. Firstly, the effort to improve memory safety via the sandbox: this is around 20% of the time. Secondly, the Oilpan odyssey: maybe 40%. Third, preparation for multiple JavaScript and WebAssembly mutator threads: 20%. Then there are a number of lesser side quests: heuristics wrangling (10%!!!!), and a long list of miscellanea. Let’s take a deeper look at each of these in turn.

    the sandbox

    There was a nice blog post in June last year summarizing the sandbox effort : basically, the goal is to prevent user-controlled writes from corrupting memory outside the JavaScript heap. We start from the assumption that the user is somehow able to obtain a write-anywhere primitive, and we work to mitigate the effect of such writes. The most fundamental way is to reduce the range of addressable memory, notably by encoding pointers as 32-bit offsets and then ensuring that no host memory is within the addressable virtual memory that an attacker can write. The sandbox also uses some 40-bit offsets for references to larger objects, with similar guarantees. (Yes, a sandbox really does reserve a terabyte of virtual memory).

    But there are many, many details. Access to external objects is intermediated via type-checked external pointer tables . Some objects that should never be directly referenced by user code go in a separate “trusted space”, which is outside the sandbox. Then you have read-only spaces, used to allocate data that might be shared between different isolates, you might want multiple cages , there are “shared” variants of the other spaces, for use in shared-memory multi-threading, executable code spaces with embedded object references, and so on and so on. Tweaking, elaborating, and maintaining all of these details has taken a lot of V8 GC developer time.

    I think it has paid off, though, because the new development is that V8 has managed to turn on hardware memory protection for the sandbox : sandboxed code is prevented by the hardware from writing memory outside the sandbox.

    Leaning into the “attacker can write anything in their address space” threat model has led to some funny patches. For example, sometimes code needs to check flags about the page that an object is on, as part of a write barrier. So some GC-managed metadata needs to be in the sandbox. However, the garbage collector itself, which is outside the sandbox, can’t trust that the metadata is valid. We end up having two copies of state in some cases: in the sandbox, for use by sandboxed code, and outside, for use by the collector.

    The best and most amusing instance of this phenomenon is related to integers. Google’s style guide recommends signed integers by default , so you end up with on-heap data structures with int32_t len and such. But if an attacker overwrites a length with a negative number, there are a couple funny things that can happen. The first is a sign-extending conversion to size_t by run-time code , which can lead to sandbox escapes. The other is mistakenly concluding that an object is small, because its length is less than a limit, because it is unexpectedly negative . Good times!

    oilpan

    It took 10 years for Odysseus to get back from Troy, which is about as long as it has taken for conservative stack scanning to make it from Oilpan into V8 proper. Basically, Oilpan is garbage collection for C++ as used in Blink and Chromium. Sometimes it runs when the stack is empty; then it can be precise. But sometimes it runs when there might be references to GC-managed objects on the stack; in that case it runs conservatively.

    Last time I described how V8 would like to add support for generational garbage collection to Oilpan , but that for that, you’d need a way to promote objects to the old generation that is compatible with the ambiguous references visited by conservative stack scanning. I thought V8 had a chance at success with their new mark-sweep nursery , but that seems to have turned out to be a lose relative to the copying nursery. They even tried sticky mark-bit generational collection , but it didn’t work out . Oh well; one good thing about Google is that they seem willing to try projects that have uncertain payoff, though I hope that the hackers involved came through their OKR reviews with their mental health intact.

    Instead, V8 added support for pinning to the Scavenger copying nursery implementation . If a page has incoming ambiguous edges, it will be placed in a kind of quarantine area for a while. I am not sure what the difference is between a quarantined page, which logically belongs to the nursery, and a pinned page from the mark-compact old-space; they seem to require similar treatment. In any case, we seem to have settled into a design that was mostly the same as before, but in which any given page can opt out of evacuation-based collection.

    What do we get out of all of this? Well, not only can we get generational collection for Oilpan, but also we unlock cheaper, less bug-prone “direct handles” in V8 itself.

    The funny thing is that I don’t think any of this is shipping yet; or, if it is, it’s only in a Finch trial to a minority of users or something. I am looking forward in interest to seeing a post from upstream V8 folks; whole doctoral theses have been written on this topic , and it would be a delight to see some actual numbers.

    shared-memory multi-threading

    JavaScript implementations have had the luxury of a single-threadedness: with just one mutator, garbage collection is a lot simpler. But this is ending. I don’t know what the state of shared-memory multi-threading is in JS , but in WebAssembly it seems to be moving apace , and Wasm uses the JS GC. Maybe I am overstating the effort here—probably it doesn’t come to 20%—but wiring this up has been a whole thing .

    I will mention just one patch here that I found to be funny. So with pointer compression, an object’s fields are mostly 32-bit words, with the exception of 64-bit doubles, so we can reduce the alignment on most objects to 4 bytes. V8 has had a bug open forever about alignment of double-holding objects that it mostly ignores via unaligned loads.

    Thing is, if you have an object visible to multiple threads, and that object might have a 64-bit field, then the field should be 64-bit aligned to prevent tearing during atomic access, which usually means the object should be 64-bit aligned. That is now the case for Wasm structs and arrays in the shared space.

    side quests

    Right, we’ve covered what to me are the main stories of V8’s GC over the past couple years. But let me mention a few funny side quests that I saw.

    the heuristics two-step

    This one I find to be hilariousad. Tragicomical. Anyway I am amused. So any real GC has a bunch of heuristics: when to promote an object or a page, when to kick off incremental marking, how to use background threads, when to grow the heap, how to choose whether to make a minor or major collection, when to aggressively reduce memory, how much virtual address space can you reasonably reserve, what to do on hard out-of-memory situations, how to account for off-heap mallocated memory, how to compute whether concurrent marking is going to finish in time or if you need to pause... and V8 needs to do this all in all its many configurations, with pointer compression off or on, on desktop, high-end Android, low-end Android, iOS where everything is weird, something called Starboard which is apparently part of Cobalt which is apparently a whole new platform that Youtube uses to show videos on set-top boxes, on machines with different memory models and operating systems with different interfaces, and on and on and on. Simply tuning the system appears to involve a dose of science, a dose of flailing around and trying things, and a whole cauldron of witchcraft. There appears to be one person whose full-time job it is to implement and monitor metrics on V8 memory performance and implement appropriate tweaks. Good grief!

    mutex mayhem

    Toon Verwaest noticed that V8 was exhibiting many more context switches on MacOS than Safari, and identified V8’s use of platform mutexes as the problem. So he rewrote them to use os_unfair_lock on MacOS. Then implemented adaptive locking on all platforms . Then... removed it all and switched to abseil .

    Personally, I am delighted to see this patch series, I wouldn’t have thought that there was juice to squeeze in V8’s use of locking. It gives me hope that I will find a place to do the same in one of my projects :)

    ta-ta, third-party heap

    It used to be that MMTk was trying to get a number of production language virtual machines to support abstract APIs so that MMTk could slot in a garbage collector implementation. Though this seems to work with OpenJDK, with V8 I think the churn rate and laser-like focus on the browser use-case makes an interstitial API abstraction a lose. V8 removed it a little more than a year ago .

    fin

    So what’s next? I don’t know; it’s been a while since I have been to Munich to drink from the source. That said, shared-memory multithreading and wasm effect handlers will extend the memory management hacker’s full employment act indefinitely, not to mention actually landing and shipping conservative stack scanning. There is a lot to be done in non-browser V8 environments, whether in Node or on the edge, but it is admittedly harder to read the future than the past.

    In any case, it was fun taking this look back, and perhaps I will have the opportunity to do this again in a few years. Until then, happy hacking!

    • Pl chevron_right

      Jussi Pakkanen: Creating valid PDF/A-4 with CapyPDF

      news.movim.eu / PlanetGnome • 13 November

    PDF/A is a specific version of PDF designed for long term archival of electronic data. The idea being that PDF/A files are both self contained and fully specified, so they can be opened in the future without any loss of fidelity.

    Implementing PDF/A export is complicated by the fact that the specification is an ISO standard, which is not publicly available. Fortunately, there are PDF/A validators that will tell you if (and sometimes how) your generated PDF/A is invalid. So, given sufficient patience, you can keep throwing PDF files at the validator, fixing the issues reported and repeating this loop over and over until validation passes. Like this:

    pdfa-valid.png

    This will be available in the next release of CapyPDF.

    • Pl chevron_right

      Christian Hergert: Status Week 45

      news.movim.eu / PlanetGnome • 10 November • 5 minutes

    Ptyxis

    • Handle some incoming issue reports which basically amounts to copying their question into google, searching, and copying the first result back. A reminder that we really need dedicated support channels that are not the issue tracker.

      But more importantly, how you move people there is still problematic. I could of course just tell them to go over “there”, but when the questions are so simple you end up taking the gentler approach and just answering it begrudgingly rather than coming off abrupt.

    • Issue reported about an async spin loop from GMainLoop after closing a window which has a really long paste actively feeding it. Looks like it needs to be addressed in VTE (more on that below), but also decided to raise priority of our fallback SIGKILL handler if SIGHUP failed.

    • Code review for incoming community feature to swap profiles on an active tab.

    VTE

    • MR sent upstream to hopefully address the corner case of disposing a terminal widget while paste is ongoing.

    • Noticed that ibus-daemon is taking considerable CPU when running the ucs-decode test tool on Ptyxis/VTE. Probably something related to tracking input cursor positions w/ the text protocol or similar. Reached out to @garncho for any tricks we might be able to pull off from the VTE side of things.

    Libdex

    • Looking into some strange behaviors with dex_thread_wait_for() when implementing the cross-thread semantics for libgit2 wrapping. As a result I changed where we control life-cycle for the waited upon future so that it is guaranteed longer than the DexWaiter.

    • Spend some time thinking about how we might approach a more generalized wrapper for existing GIO-like async functions. I was never satisfied with DexAsyncPair and perhaps now that we will gain a gdbus-codegen for Libdex we could gain a *.gir future wrapping codegen too.

    • Add a new DexFutureListModel which is a GListModel which is populated by a DexFuture resolving to a GListModel . Very handy when you have a future and want a GListModel immediately.

    Foundry

    • Add FoundryFileRow so we have easy mechanics for the whole typing a file/directory path and browsing to it. Re-use the existing path collapse/expand stuff in Foundry to allow for niceties like ~/Directory . Fix a bunch of obnoxiousness that was in the Builder implementation of this previously.

    • Add foundry_operation_is_cancelled() to simplify integrating with external blocking/threaded code such as libgit2. This allows breaking out of a clone operation by checking for cancellation in the progress callbacks from the server but works for any sort of blocking API that itself has callback functions in its state machine.

    • Add new CLI formatter for GFlags to use value_nick instead of the whole enumeration value in UP_CASE .

    • Add FoundryBuildPipeline:build-system with discover from the FoundryBuildAddin before full addin loading occurs. This replicates the IdeBuildSystemDiscovery from Builder without having to use a secondary addin object.

    • Add priorities to FoundryBuildAddin so that we can pre-sort by priority before build-system discovery. That fixes loading the WebKit project out of the box so that CMakeLists.txt will be matched before Makefile if you configured in tree.

    • Implement write-back for FoundrySdkManager:sdk to the active configuration after checking of the config supports the SDK.

    • Implement write-back for buildconfig files.

    • Implement mechanics for write-back PluginFlatpakConfig . Also start on implementation for all the FlatpakSerializable types. This is made much more complicated by needing to keep track of the different subtle ways lists can be deserialized as well as referenced files which can be included. It will mean write-back may have a bucket of files to update. Though right now we only will do this for a few select fields so we can probably punt a bit.

    • Meson cleanup to all our tools that test various aspects of Foundry outside the confines of an entire IDE.

    • Non-destructive editing of flatpak manifests works for the core feature-set we need. It requires storing a lot of state while parsing manifests (and recursively their includes) but it seems to work well enough.

    • Setup needs-attention tracking for panels and pages.

    • Write a new foundry.1 manpage for inclusion in distributions that really want that provided.

    • Add :author property to FoundryForgeIssue and FoundryForgeMergeRequest so we can start presenting peer information in the Builder UI. Implement this for gitlab plugin.

    • Improve handling to changes in implicit-trailing-newline from file settings getting loaded/applied. That way we don’t run into weird behavior with file-change monitoring with ligbit2 getting something different than we’d expect.

    • Support for keyword search when listing issues/merge-requests through the forge interfaces.

    • Add FoundryDocumentationIntent for intent to read documentation.

    • Very basic support for Justfile using just to build. Currently it is sort of a cop-out because it uses build and clean instead of trying to track down [default] and what not. Contributions welcome.

    Builder

    • Iteration on the new clone dialog based on Foundry including wiring up all the PTY usage, page navigation, etc.

    • Update builder-dark GtkSourceView style to fit in better with updated Adwaita palette. Even though it’s not using Tango palette for all the colors, we still want it to fit in.

    • Iteration on forge listings

    • Wire up needs attention for panels/pages

    • Setup forge splitbutton so we can jump to gitlab (or other forge) quickly or alternatively list issues/etc in app as we gain more forge support.

    • Implement manuals panel and page on top of the Foundry service FoundryDocumentationManager .

    • Implement browser page and port over old urlbar implementation. Still slogging through all the intricacies of navigation policy which I didn’t handle so well in Builder originally.

    • Work on bringing over path bar from Manuals so we can use it more generically for things like symbol paths and what not.

    • A lot of little things here and there that just need plumbing now that we’re in a world of futures and listmodels.

    • Lots of work on the updated greeter using Foundry. It looks mostly the same, just less madness in implementation.

    Flathub

    • Investigate why older Builder is what is shown as published.

    • Merge PR to update Ptyxis to 49.2

    • Update Manuals to 49.1 since I missed the .0. Had a lot of libfoundry things to bring over as well. Needs an exceptions update to flathub linter.

    Text Editor

    • Update builder style scheme

    Libpanel

    • Update needs-attention style for the panel switcher buttons

    Manuals

    • Make ctrl+k select all the existing text in the search entry as part of the focus-search action.