The terminal library extracted from Ghostty has reached 1.0 with a binary compatibility guarantee. JetBrains adopted it early in its 2026.3 IDEs, improving keyboard input and display behavior, and standalone releases make the engine available to other development tools.

Key points

• Release highlights: libghostty-vt 1.0 ships with a C ABI compatibility guarantee and standalone distribution.
• IDE changes: JetBrains adopted libghostty early in its 2026.3 release series, improving Shift+Enter handling and support for nearly 50 control sequences.

Read the full article on Joho no Todai · Japanese original

Windows Latest found a native WinUI 3 version of Registry Editor in Microsoft’s open-source Microsoft.UI.Reactor repository, and I compiled it and ran it on my Windows 11 PC. It actually reads the real Windows Registry and makes regedit.exe look like a relic.

Microsoft has only mentioned “a registry editor” in passing, in an October developer blog post that promised a tour of its sample apps “next month.” The tour hasn’t happened yet, which makes this the first look at the app running on a PC. It’s a developer sample, though, and Microsoft hasn’t announced plans to replace Registry Editor in Windows 11.

Microsoft’s new WinUI Registry Editor looks nothing like the Windows 95-era original

Registry Editor still uses the two-pane layout it got in Windows 95, with keys on the left and values on the right. Apart from the address bar added in the Windows 10 Creators Update, its yellow folders, cramped menus, and tiny text have barely changed in three decades.

The WinUI version keeps the same layout, and it’s a good idea; power users would not stop criticizing Microsoft for making them relearn regedit, which hasn’t changed for so long.

But what I like is that Menus have more breathing room. The tree drops the yellow folders, but I hope there would be some newer-looking folder icon when or if this WinUI regedit comes to fruition. The address bar is a WinUI text box, and a status bar at the bottom shows the current path, which may be unnecessary. Like I said, this is a developer sample, and things may change a lot.

On my PC running Build 26340.9882, the app opened quickly and felt as fast as regedit. However, expanding HKEY_CLASSES_ROOT showed a brief “Loading…” placeholder before listing keys like .386, .3gp and .7z, and HKEY_LOCAL_MACHINE\SOFTWARE showed the keys and values regedit showed. Menus open with WinUI’s fluid animations, and resizing the window is smooth.

Help > About confirms it’s not a mock-up, as the dialog shows “Registry Editor Reactor WinUI 3 Edition.”

Microsoft uses WinUI 3 and a React-like C# framework to rebuild Registry Editor

Microsoft calls Reactor “an experimental C# framework that brings the MVU (Model-View-Update) pattern to WinUI desktop apps.” In a developer blog post, Principal Software Developer Engineer Alexandre Zollinger Chohfi says the goal is “to find out how far MVU can go on WinUI.”

Reactor is “not a new UI platform,” as Microsoft puts it. Every menu, tree and dialog in the app is a real WinUI control, with no HTML, Electron, or WebView2 involved. The only change is the way developers write the app.

• The UI is written in C#, without XAML pages, code-behind or ViewModels.
• Apps are built from components, with React-style hooks like UseState and UseEffect. It’s still C#, not JavaScript React.
• When state changes, Reactor updates only the controls that changed.

I appreciate that Microsoft didn’t just wrap regedit.exe in a modern window. In the sample’s source code, a separate RegistryService class reads and writes the Registry using .NET’s Microsoft.Win32 APIs and catches permission errors so a protected key doesn’t crash the app. The window also uses Windows 11’s Mica backdrop, which “only samples the desktop wallpaper once” to keep apps fast.

XAML isn’t going anywhere, as Microsoft says “WinUI is the foundation,” and ideas that prove themselves in Reactor could make it into WinUI too. When we covered Reactor, Microsoft pitched it as an easier way to build native apps, including with AI coding tools.

The Registry Editor sample works, but several features are still unfinished

I didn’t write or change any of Microsoft’s code. I only changed the build settings to bundle .NET and the Windows App SDK, which turned the sample into a portable folder that runs without me having to instal anything.

Microsoft’s code can create, rename and delete keys, add String, Binary, DWORD, QWORD, Multi-String and Expandable String values, and search with Find (Ctrl+F). Since one wrong edit can break Windows, if you’re going to try this, do it in a virtual machine, like I did.

A comment in the code says Permissions is “out of scope for initial implementation.”

Microsoft’s WinUI modernization is reaching even the oldest Windows tools

Again, the sample doesn’t mean regedit.exe is getting replaced, but Microsoft is thinking about it. On a podcast in August, Marcus Ash, Microsoft’s CVP of Design and Research for Windows, said “even things like Regedit and some of the tooling, we’ve already started to look at.”

Registry Editor would join a growing list.

• File Explorer’s Properties dialog is getting a WinUI 3 version with dark mode.

  

• Print Management has a WinUI 3 app in place of the old MMC console, and AutoPlay is next.
• The modern Run dialog opens faster than the old one, according to Microsoft and in our detailed testing.

  

• Even the defrag tool is “on our list,” says Microsoft.

Microsoft’s design team says more ancient dialogs are next, though Control Panel isn’t going away yet. It’s also cutting WinUI’s RAM usage, so new apps don’t end up heavier than the ones they replace.

The WinUI version is the first time Registry Editor has felt like a Windows 11 app. It still needs Permissions, proper .reg files, and plenty of testing, but if Microsoft ever ships a new Registry Editor, I’d be happy if it looked like this. Would you switch?

The post Microsoft built a native WinUI Registry Editor that makes Windows 11’s regedit look like Windows 95, and I tried it appeared first on Windows Latest

null

Continue reading Prompt Management in TypeScript: LangSmith vs Git vs 3 Open-Source Registries on SitePoint.

Flutter has long enabled developers to build Android and iOS applications from a shared codebase while supporting platform-specific interfaces through Material and Cupertino widgets. However, because these design libraries were bundled with the Flutter SDK, even minor framework-provided UI improvements could require a complete SDK upgrade, potentially introducing unrelated changes and additional regression testing.

In August 2026, Flutter 3.47 addressed this limitation by introducing independently versioned material_ui and cupertino_ui packages. Officially announced in September 2026, this architectural change allows Flutter’s design libraries to evolve separately from the core framework, with implications for platform-specific UI updates, custom design systems, and long-term application maintenance.

How Decoupling Changes Cross-Platform UI Development

For developers, the change affects more than package updates. It also influences how platform-specific interfaces evolve, how custom design systems are built, and how UI dependencies are managed across applications.

1. Faster Adoption of Platform-Specific UI Changes

Google’s Material 3 Expressive and Apple’s Liquid Glass introduce new visual treatments and interaction patterns. Flutter’s standalone design libraries let teams implement these evolving design systems without waiting for the next Flutter SDK update.

Applications maintaining separate Android and iOS interfaces can incorporate supported design updates through the relevant package, subject to SDK and dependency compatibility. This gives teams greater control over when to adopt new platform conventions without requiring coordinated changes to both UI libraries.

However, decoupling does not automatically deliver native UI behavior. Material and Cupertino remain Flutter-rendered widget libraries, and developers must still implement appropriate platform conventions and validate accessibility, animations, and interactions.

2. Better Foundations for Custom Design Systems

Flutter’s lower-level widgets library historically lacked certain reusable UI capabilities, forcing custom design system developers to recreate components or rely on design-specific implementations.

Alongside decoupling, the Flutter team is addressing gaps in its style-neutral widgets library to provide more reusable building blocks. As more foundational functionality becomes available, developers may be able to reuse common UI behavior without depending on either design library.

Note: These improvements remain ongoing and are not automatically available through the standalone packages.

3. More Explicit UI Dependency Boundaries

Independent design libraries make it more important to identify where reusable components depend on Material or Cupertino APIs. Shared widget packages that expose design-specific classes through public interfaces can become difficult to maintain when applications and third-party dependencies use incompatible library implementations.

As Material and Cupertino evolve independently, these dependencies become more visible, reinforcing the importance of clear boundaries between shared UI components and platform-specific implementations. This separation can help contain the impact of future design-library changes on the wider application architecture.

What Should Developers Consider Before Migrating to Standalone Packages?

Before migrating to standalone Material and Cupertino packages, Flutter app development teams should evaluate their application’s dependencies, UI architecture, and compatibility requirements. The following checks can help reduce migration risks:

1. Audit Third-Party UI Dependencies

Identify packages that expose Material or Cupertino types through public APIs. Dart treats identically named classes from the bundled and standalone libraries as distinct types because they have different library identities. This can cause compilation errors when third-party APIs expect legacy types. Check whether critical dependencies support the standalone packages, and consider deferring migration where compatible versions are unavailable.

2. Assess Shared Widgets and Design-system Dependencies

Review reusable components, theme configurations, and internal UI packages for direct references to legacy Material or Cupertino types. Coordinate updates across shared libraries to prevent incompatible interfaces.

3. Plan for Mixed-library Compatibility

Where legacy and standalone widgets must coexist, evaluate Flutter’s compatibility bridges for inherited theme and localization context. These bridges cannot resolve Dart type mismatches in public APIs, which require compatible package implementations.

4. Update Localization and Validate UI Behavior

Review localization delegates and test navigation, theming, accessibility, animations, and platform-specific interactions after migration. Include widget, integration, and visual regression tests where applicable.

For applications with compatible dependencies, developers can use Flutter’s automated migration command, dart fix — apply — code=migrate_design_widgets, and ensure the standalone packages are added to the project’s dependencies.

For larger applications, developers should first migrate compatible internal packages and verify whether third-party dependencies expose legacy design-library types. Where mixed-library usage is unavoidable, proceed with migration only across tested compatibility boundaries. Applications dependent on incompatible public APIs may need to defer adoption until those packages are updated.

Refer to the official Flutter migration guide for implementation instructions.

Ending Note: A More Modular Future for Flutter UI Development

Flutter’s Material and Cupertino decoupling represents a shift toward independently maintained design systems and more flexible cross-platform architectures. While this creates opportunities for faster UI updates and greater customization, it also introduces new considerations around dependency compatibility and long-term maintenance.

For businesses, the immediate priority is to evaluate whether their existing applications are ready for this transition and where architectural changes may be necessary. Whether the migration is handled internally or with support from experienced Flutter developers, the focus should remain on maintaining application stability while preparing for Flutter’s evolving design-system architecture.

How Flutter’s Material and Cupertino Decoupling is Changing Cross-Platform UI Development was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

LLMs don’t know how to design software that uses LLMs. They’re comfortable writing normal programs, but if you throw an AI-shaped problem at them, they will usually screw it up. Why is that?

Going down the symbolic rabbit hole

For example, this post describes an attempt to vibe-code a memory tool that would flag when one memory contradicted another¹. This is a great instance of a task that was virtually impossible five years ago but is now relatively trivial due to LLMs. You can simply task a LLM with scanning for contradictions, either in a big batch or pairwise².

However, when asked for the “state of the art” approach³, the AI agent in this case did not recommend LLMs. It started building a bewilderingly complex symbolic system to convert the memory items into structured logical atoms, then mechanically compare them with a solver. This, of course, did not and could not work, because there is no analytic way of determining whether any two natural-language sentences express the same proposition.

The LLM knew this was impossible! When the user eventually lost patience and said “hey, why isn’t this working”, Claude immediately explained that this was a known 130-year-old problem with no solution. And yet it happily went around and around for weeks iterating on a dead end.

I’ve run into this myself. When I was building Autodeck (AI-generated spaced repetition cards) my agents would routinely try to categorize cards by regex or keyword search instead of just making another LLM call.

Why can’t LLMs use LLMs correctly?

Why would this be happening? I have two obvious explanations and one deeper one.

The first obvious explanation is that most training code is pre-LLMs. Assuming the labs aren’t feeding the current avalance of slop repositories directly into the models⁴, the vast majority of the code that models learn from was written before LLMs were an option. So it would make sense that they’d reach for non-LLM approaches, in the same way that they’d reach for jQuery over modern vanilla JS, or Backbone.js over React, right? Wrong, actually! LLMs don’t choose jQuery and Backbone. Whatever part of the training process pushes them towards up-to-date knowledge in other areas isn’t successfully pushing them towards LLMs, so this can’t be the whole story.

The second obvious explanation is that RLVR is not a good environment to write code that calls LLMs. Much of the time LLMs spend training is spent in reinforcement learning environments where an automatic grader determines their performance (for instance, by running some code they wrote and checking the outputs). I don’t know this for a fact, but I would be surprised if these environments contained the credentials and API access for a LLM to call other LLMs⁵. So even if the pretrained LLM was comfortable writing that kind of code, the reinforcement learning process might discourage⁶ it from doing so.

The third explanation, which I like the most, is that current AI agents are just not very good at software design. On this explanation, picking a doomed symbolic approach instead of simply calling a LLM is not a weird aberration but a normal instance of AI agents picking the wrong tool for the job. I’ve seen this behavior from LLMs in other contexts too: trying to build complex (and doomed) consensus algorithms instead of tolerating stale data, introducing synchronous checks in event-driven systems, and so on. In the past I’ve chalked these up to alignment, but I’m open to the idea that they’re just ordinary errors of software design.

Conclusion

One lesson I learn over and over again is that I can’t judge a LLM by the standards of a human. Any human programmer who was capable of implementing a sophisticated symbolic solver would know that it wouldn’t work, and so if they suggested that approach I’d assume⁷ they had a good reason. Only a LLM could be both smart enough and dumb enough to make this mistake.

I write a lot about the skills that are involved in working effectively with LLMs. I still stand by what I wrote in February 2025:

Using LLMs well involves extracting value from what they’re good at and avoiding wasting time at what they’re bad at.

This is surprisingly hard, because of the point above. LLMs are good and bad seemingly at random: they will work hard for hours but sometimes be shockingly low-effort, they will draw on inhumanly broad expertise but fail to apply the most basic common-sense, they can successfully rewrite enormously complex programs but will often make very silly errors in design.

If you can predict where they will do well or badly ahead of time, you can get enormous value from LLMs; if you can’t, you will likely waste a lot of time and tokens going down hopeless approaches.