I’m passing by to let you know that Flock to Fedora 2025 is happening from June 5th to 8th in Prague , here in the Czech Republic.

I will be presenting about Flatpaks, Fedora, and the app ecosystem, and would love to meet up with people interested in chatting about all things GNOME, Flatpak, and desktop Linux.

If you’re a GNOME contributor interested in attending Flock, please let me know . If we have enough people, I will organize a GNOME Beers meetup too.

The Linux App Summit (LAS) 2025 is just around the corner, and we’re thrilled to remind you that registrations are now open for both online and in-person attendees!

Event Dates: April 25-26, 2025
Location: Tirana, Albania

Join us for two days of inspiring talks and community engagement. Whether you’re are a developer, a contributor, or someone curious about the open source ecosystem, LAS is the perfect place to connect, learn, and share ideas.

Register now: Linux App Summit Registration

Stay tuned for more updates, and we can’t wait to see you in Tirana!

Cantarell has been used as the default interface font since November 2010, but unfortunately, font technology is moving forward, while Cantarell isnʼt.

Similarly, Source Code Pro was used as the default monospace font, but its maintenance hasnʼt been well. Aesthetically, it has fallen out of taste too.

GNOME was ready to move on, which is why the Design Team has been putting effort into making the switch to different fonts in recent cycles.

The Sans

Inter was quite a straightforward choice, due to its modern design, active maintenance, and font feature support. It might be the most popular open source sans font, being used in Figma, GitLab, and many other places.

An issue was created to discuss the font. From this, a single design tweak was decided on: the lowercase L should be disambiguated.

A formal initiative was made for the broader community to try out the font, catch issues that had to be resolved, and look at the platform to see where we need to change anything in terms of visuals. Notably, the Shell lock screen got bolder text .

At this point, some issues started popping up, including some nasty Cantarell-specific hacks in Shell, and broken small caps in Software. These were quickly fixed thereafter, and due to GTKʼs robust font adaptivity, apps were mostly left untouched.

However, due to Interʼs aggressive use of calt , some unintended behavior arose in arbitrary strings as a result of ligatures. There were two fixes for this, but they would both add maintenance costs which is what weʼre trying to move away from:

1. Subset the font to remove calt entirely
2. Fork the font to remove the specific ligature that caused issues

This blocked the font from being the default in GNOME 47, as Rasmus, the Inter maintainer, was busy at the time, and the lack of contact brought some uncertainty into the Design Team. Luckily, when Rasmus returned during the 48 development cycle, he removed the problematic ligature and Inter was back in the race.

No further changes were required after this, and Inter, now as Adwaita Sans, was ready for GNOME 48.

The Mono

After the sans font was decided on as Inter, we wanted a matching monospace font. Our initial font selection consisted of popular monospace fonts and recommendations from Rasmus.

We also made a list of priorities, the new font would need:

1. A style similar to Adwaita Sans
2. Active maintenance
3. Good legibility
4. Large language coverage

Some fonts on our initial font selection fell off due to shortcomings in this list, and we were left with IBM Plex Mono , Commit Mono and Iosevka .

Just like for the sans font, we made a call for testing for these three fonts. The difference in monospace fonts can be quite hard to notice, so the non-visual benefits of the fonts were important.

The favorite among users was Commit Mono, due to its fairly close neutral design to Adwaita Sans. However, the font that we ended up with was Iosevka. This made some people upset, but this decision was made for a couple of reasons:

1. Iosevka has more active maintenance
2. Iosevkaʼs configuration might have the best free tooling out there
3. When configured, Iosevka can look extremely similar to Adwaita Sans
4. The language coverage of Iosevka is considerably larger

So, in the end, kramo and me went through all its glyphs, configured them to look as close to Adwaita Sans as possible, and made that Adwaita Mono.

Naming

We wanted unique names for the fonts, because it will allow us to more easily switch them out in the future if necessary. Only the underlying repository will have to change, nothing else.

The configured Inter was originally named GNOME UI Font, but due to the introduction of the monospace font and our design system being called Adwaita, we moved the fonts under its umbrella as Adwaita Fonts.

Technical Details

We use OpenType Feature Freezer to get the disambiguated lowercase L in Inter, as recommended by upstream.

Iosevka has their own configuration system which allows you to graphically customize the font, and export a configuration file that can be used later down the line.

The repository which hosts the fonts originally started out with the goal to allow distributions to build the fonts themselves, which is why it used Makefiles with the help of Rose .

Due to Iosevka requiring NPM packages to be configured, the scope was changed to shipping the TTF files themselves. Florian Müllner therefore ported the repository to shell scripts which allows us to update the files only, heavily simplifying the maintenance process.

The repository and fonts are licensed under the SIL Open Font License .

Conclusion

We want to thank everyone that contributed to this font switch by testing, discussing, and coding!

Adwaita Fonts will be the default in GNOME 48, and we hope youʼre as happy with this change as we are.

Making STM32WL55 work with Rust

I recently got my hands on a STM32WL55 development kit (NUCLEO-WL55JC2 to be more precise) and wanted to program it in Rust. Since things did not work out of the box and I had to spend many hours figuring out how to make it work, I thought I document the steps I took to make it work for the next person who bumps into this:

Pre-requisites

• STM32CubeProgrammer
• probe-rs
• target-gen

Note: The target-gen docs instruct how to run it from the repository but it's not necessary and you can install with cargo install target-gen .

Getting Started

Powering up the board is super easy. Just connect the USB cable to the board and your computer. Now if you're as eager as I was, you'll want to already want to try out the lora-rs examples but if you do that already, you'll get an error:

❯ cargo r --bin lora_p2p_receive
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running `probe-rs run --chip STM32WL55JC target/thumbv7em-none-eabi/debug/lora_p2p_receive`
 WARN probe_rs::probe::stlink: send_jtag_command 242 failed: JtagGetIdcodeError
Error: Connecting to the chip was unsuccessful.

The first thing you'll want to do is to disable security (yeah, I know!). To do that, you'll need to run this script:

write(){
  str=""
  for arg do
    str+=" ${arg}"
  done
  /home/user/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI -c port=SWD mode=UR -q -ob "${str}"
}

echo RDP: Read Out protection Level 1
write RDP=0xBB

echo RDP+ESE: Read Out protection Level 0 + Security disabled
write RDP=0xAA ESE=0x0

echo WRP: Write Protection disabled
write WRP1A_STRT=0x7F WRP1A_END=0x0 WRP1B_STRT=0x7F WRP1B_END=0x0

echo ------ User Configuration ------
echo nRST: No reset generated when entering the Stop/Standby/Shutdown modes
write nRST_STOP=0x1 nRST_STDBY=0x1 nRST_SHDW=0x1

echo WDG_SW: Software window/independent watchdogs
write WWDG_SW=0x1 IWDG_SW=0x1

echo IWDG: Independent watchdog counter frozen in Stop/Standby modes
write IWGD_STDBY=0x0 IWDG_STOP=0x0

echo BOOT: CPU1+CPU2 CM0+ Boot lock disabled
write BOOT_LOCK=0x0 C2BOOT_LOCK=0x0

echo ------ Security Configuration ------
echo HDPAD: User Flash hide protection area access disabled
write HDPAD=0x1

echo SPISD: SPI3 security disabled
write SUBGHSPISD=0x1

echo SBRSA: Reset default value of SRAM Start address secure
write SNBRSA=0x1F SBRSA=0x1F

echo SBRV: Reset default value of CPU2 Boot start address
write SBRV=0x8000

Now if you run the example again, you'll get a different error:

❯ cargo r --bin lora_p2p_receive
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running `probe-rs run --chip STM32WL55JC target/thumbv7em-none-eabi/debug/lora_p2p_receive`
Error: The flashing procedure failed for 'target/thumbv7em-none-eabi/debug/lora_p2p_receive'.

Caused by:
    Trying to write flash, but found more than one suitable flash loader algorithim marked as default for NvmRegion { name: Some("BANK_1"), range: 134217728..134479872, cores: ["cm4", "cm0p"], is_alias: false, access: Some(MemoryAccess { read: true, write: false, execute: true, boot: true }) }.

That means you're almost there. You just need to tell probe-rs that all but one flash algorithm are the default. I wish this was as easy as setting a CLI arg but unfortunately you need to a tiny bit more:

❯ target-gen  arm -f "STM32WLxx_DFP"
2025-03-16T12:17:56.163918Z  WARN target_gen::generate: Device STM32WL54CCUx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.163936Z  WARN target_gen::generate: Device STM32WL54CCUx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.163938Z  WARN target_gen::generate: Device STM32WL54CCUx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164440Z  WARN target_gen::generate: Device STM32WL54JCIx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164443Z  WARN target_gen::generate: Device STM32WL54JCIx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164445Z  WARN target_gen::generate: Device STM32WL54JCIx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164948Z  WARN target_gen::generate: Device STM32WL55CCUx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164954Z  WARN target_gen::generate: Device STM32WL55CCUx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164956Z  WARN target_gen::generate: Device STM32WL55CCUx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165458Z  WARN target_gen::generate: Device STM32WL55JCIx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165463Z  WARN target_gen::generate: Device STM32WL55JCIx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165465Z  WARN target_gen::generate: Device STM32WL55JCIx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166001Z  WARN target_gen::generate: Device STM32WL5MOCHx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166005Z  WARN target_gen::generate: Device STM32WL5MOCHx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166007Z  WARN target_gen::generate: Device STM32WL5MOCHx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
Generated 1 target definition(s):
    /home/user/lora-rs/STM32WL_Series.yaml
Finished in 3.191890047s

Now edit this file and change all default: true lines under flash_algorithms to default: false , except for the one under stm32wlxx_cm4 (the core we want to use). Then edit the .cargo/config.toml file as well and change the probe-rs commandline in it, to make use of this chip description file by adding --chip-description-path /tmp/STM32WL_Series.yaml to it.

At this point everything should work and you should be able to flash and run the lora-rs examples:

❯ cargo r --bin lora_p2p_receive
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
     Running `probe-rs run --chip STM32WLE5JCIx --chip-description-path /tmp/STM32WL_Series.yaml target/thumbv7em-none-eabi/debug/lora_p2p_receive`
      Erasing ✔ 100% [####################] 140.00 KiB @  61.45 KiB/s (took 2s)
  Programming ✔ 100% [####################] 139.00 KiB @  41.50 KiB/s (took 3s)                                                                                                                                                                                                                                                                                                                                                                  Finished in 5.63s
0.000000 TRACE BDCR ok: 00008200
└─ embassy_stm32::rcc::bd::{impl#3}::init @ /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/embassy-stm32-0.2.0/src/rcc/bd.rs:216
0.000000 DEBUG rcc: Clocks { hclk1: MaybeHertz(48000000), hclk3: MaybeHertz(48000000), hsi: MaybeHertz(0), lse: MaybeHertz(0), lsi: MaybeHertz(32000), msi: MaybeHertz(4000000), pclk1: MaybeHertz(48000000), pclk1_tim: MaybeHertz(48000000), pclk2: MaybeHertz(48000000), pclk2_tim: MaybeHertz(48000000), pclk3: MaybeHertz(48000000), pll1_p: MaybeHertz(0), pll1_q: MaybeHertz(48000000), rtc: MaybeHertz(32000), sys: MaybeHertz(48000000) }
...

Making STM32WL55 work with Rust

I recently got my hands on a STM32WL55 development kit (NUCLEO-WL55JC2 to be more precise) and wanted to program it in Rust. Since things did not work out of the box and I had to spend many hours figuring out how to make it work, I thought I document the steps I took to make it work for the next person who bumps into this:

Pre-requisites

• STM32CubeProgrammer
• probe-rs
• target-gen

Note: The target-gen docs instruct how to run it from the repository but it's not necessary and you can install with cargo install target-gen .

Getting Started

Powering up the board is super easy. Just connect the USB cable to the board and your computer. Now if you're as eager as I was, you'll want to already want to try out the lora-rs examples but if you do that already, you'll get an error:

❯ cargo r --bin lora_p2p_receive
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running `probe-rs run --chip STM32WL55JC target/thumbv7em-none-eabi/debug/lora_p2p_receive`
 WARN probe_rs::probe::stlink: send_jtag_command 242 failed: JtagGetIdcodeError
Error: Connecting to the chip was unsuccessful.

The first thing you'll want to do is to disable security (yeah, I know!). To do that, you'll need to run this script:

write(){
  str=""
  for arg do
    str+=" ${arg}"
  done
  /home/user/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI -c port=SWD mode=UR -q -ob "${str}"
}

echo RDP: Read Out protection Level 1
write RDP=0xBB

echo RDP+ESE: Read Out protection Level 0 + Security disabled
write RDP=0xAA ESE=0x0

echo WRP: Write Protection disabled
write WRP1A_STRT=0x7F WRP1A_END=0x0 WRP1B_STRT=0x7F WRP1B_END=0x0

echo ------ User Configuration ------
echo nRST: No reset generated when entering the Stop/Standby/Shutdown modes
write nRST_STOP=0x1 nRST_STDBY=0x1 nRST_SHDW=0x1

echo WDG_SW: Software window/independent watchdogs
write WWDG_SW=0x1 IWDG_SW=0x1

echo IWDG: Independent watchdog counter frozen in Stop/Standby modes
write IWGD_STDBY=0x0 IWDG_STOP=0x0

echo BOOT: CPU1+CPU2 CM0+ Boot lock disabled
write BOOT_LOCK=0x0 C2BOOT_LOCK=0x0

echo ------ Security Configuration ------
echo HDPAD: User Flash hide protection area access disabled
write HDPAD=0x1

echo SPISD: SPI3 security disabled
write SUBGHSPISD=0x1

echo SBRSA: Reset default value of SRAM Start address secure
write SNBRSA=0x1F SBRSA=0x1F

echo SBRV: Reset default value of CPU2 Boot start address
write SBRV=0x8000

Making it all work

Now if you run the example again, you'll get a different error:

❯ cargo r --bin lora_p2p_receive
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running `probe-rs run --chip STM32WL55JC target/thumbv7em-none-eabi/debug/lora_p2p_receive`
Error: The flashing procedure failed for 'target/thumbv7em-none-eabi/debug/lora_p2p_receive'.

Caused by:
    Trying to write flash, but found more than one suitable flash loader algorithim marked as default for NvmRegion { name: Some("BANK_1"), range: 134217728..134479872, cores: ["cm4", "cm0p"], is_alias: false, access: Some(MemoryAccess { read: true, write: false, execute: true, boot: true }) }.

That means you're almost there. You just need to tell probe-rs that all but one flash algorithm are the default. I wish this was as easy as setting a CLI arg but unfortunately you need to a tiny bit more:

❯ target-gen  arm -f "STM32WLxx_DFP"
2025-03-16T12:17:56.163918Z  WARN target_gen::generate: Device STM32WL54CCUx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.163936Z  WARN target_gen::generate: Device STM32WL54CCUx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.163938Z  WARN target_gen::generate: Device STM32WL54CCUx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164440Z  WARN target_gen::generate: Device STM32WL54JCIx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164443Z  WARN target_gen::generate: Device STM32WL54JCIx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164445Z  WARN target_gen::generate: Device STM32WL54JCIx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164948Z  WARN target_gen::generate: Device STM32WL55CCUx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164954Z  WARN target_gen::generate: Device STM32WL55CCUx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164956Z  WARN target_gen::generate: Device STM32WL55CCUx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165458Z  WARN target_gen::generate: Device STM32WL55JCIx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165463Z  WARN target_gen::generate: Device STM32WL55JCIx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165465Z  WARN target_gen::generate: Device STM32WL55JCIx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166001Z  WARN target_gen::generate: Device STM32WL5MOCHx, memory region SRAM1 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166005Z  WARN target_gen::generate: Device STM32WL5MOCHx, memory region SRAM2 has no processor name, but this is required for a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166007Z  WARN target_gen::generate: Device STM32WL5MOCHx, memory region FLASH has no processor name, but this is required for a multicore device. Assigning memory to all cores!
Generated 1 target definition(s):
    /home/user/lora-rs/STM32WL_Series.yaml
Finished in 3.191890047s

Now edit this file and change all default: true lines under flash_algorithms to default: false , except for the one under stm32wlxx_cm4 (the core we want to use). Then edit the .cargo/config.toml file as well and change the probe-rs commandline in it, to make use of this chip description file by adding --chip-description-path STM32WL_Series.yaml to it.

At this point everything should work and you should be able to flash and run the lora-rs examples:

❯ cargo r --bin lora_p2p_receive
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
     Running `probe-rs run --chip STM32WLE5JCIx --chip-description-path STM32WL_Series.yaml target/thumbv7em-none-eabi/debug/lora_p2p_receive`
      Erasing ✔ 100% [####################] 140.00 KiB @  61.45 KiB/s (took 2s)
  Programming ✔ 100% [####################] 139.00 KiB @  41.50 KiB/s (took 3s)                                                                                                                                                                                                                                                                                                                                                                  Finished in 5.63s
0.000000 TRACE BDCR ok: 00008200
└─ embassy_stm32::rcc::bd::{impl#3}::init @ /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/embassy-stm32-0.2.0/src/rcc/bd.rs:216
0.000000 DEBUG rcc: Clocks { hclk1: MaybeHertz(48000000), hclk3: MaybeHertz(48000000), hsi: MaybeHertz(0), lse: MaybeHertz(0), lsi: MaybeHertz(32000), msi: MaybeHertz(4000000), pclk1: MaybeHertz(48000000), pclk1_tim: MaybeHertz(48000000), pclk2: MaybeHertz(48000000), pclk2_tim: MaybeHertz(48000000), pclk3: MaybeHertz(48000000), pll1_p: MaybeHertz(0), pll1_q: MaybeHertz(48000000), rtc: MaybeHertz(32000), sys: MaybeHertz(48000000) }
...

New cycle, new libadwaita version. Let's look at the changes.

Toggle groups

Last time I mentioned that Maximiliano 's toggle groups were ready by the end of the last cycle but it was too late to get them into 1.6.

AdwToggleGroup a replacement for the specific pattern of using multiple exclusive instances of GtkToggleButton in a box. Compared to a box it provides a clearer styling and simpler to use API. Toggles can be accessed either by their index, or optionally by their name. It can also be vertical, though I don't expect that to be frequently used.

If the switch-like style doesn't work in a given context, they can also be made flat, then they look the same way as a group of flat buttons.

Inline view switcher

While the app-wide switcher use case had been well covered by AdwViewSwitcher for years, we didn't have anything for inline use cases like putting a switcher into a card, into a sidebar or into the middle of a boxed list page. Most apps used GtkStackSwitcher there, some instead implemented a custom switcher with the same kind of visuals as toggle groups (the design has existed for a while).

So, there's now also a view switcher version using a toggle group internally - AdwInlineViewSwitcher .

Stack improvements

Like AdwViewSwitcher , AdwInlineViewSwitcher works with AdwViewStack rather than GtkStack , which may present a problem as in these contexts it often makes sense to animate transitions. So, AdwViewStack supports crossfade transitions now.

They work a bit differently than in GtkStack - it always interpolates size, it doesn't clip the contents so can be used to e.g. transition between two cards without clipping their shadows ( GtkStack does clip it as it also supports slide transitions where it makes sense), and it uses different easing. It also moves children differently depending on their :halign and :valign values.

Wrap box

Another widget that's been started a long time ago and never finished until this cycle is AdwWrapBox . It behaves like a GtkBox but can wrap children onto additional lines. Unlike GtkFlowBox , it doesn't place children in a grid, however, treating them more like words in a paragraph.

This can be used in situations like displaying a list of tags.

Wrap box can be tweaked in a number of ways, e.g. starting each line from the right rather than from the left (or vice versa for RTL locales), justifying each line (either via stretching children or adding spacing between them), wrapping upwards instead of downwards and so on.

Adaptive preview

I already mentioned it in a previous blog post , but libadwaita now has adaptive preview mode, inspired by responsive design modes in various web browsers. To reiterate, it allows to preview a given app on different devices - mostly mobile phones - without the need to resize the window in precise ways to check if the app works or not at a given size.

Since the original blog post, it gained a few new features - such as scaling when the content doesn't fit, displaying device bezels, and taking screenshots with that bezel intact:

The UI in the inspector has been revamped, and there's now a separate shortcut for opening the preview: Ctrl + Shift + M .

Sizing Changes

This cycle, Sergey Bugaev did a lot of sizing fixes throughout both GTK and libadwaita, aimed at improving consistency in width-for-height and height-for-width scenarios. Most of the time this shouldn't affect existing apps, but one notable change is in how AdwClamp reports its natural width (or height for vertical clamps): when containing a small child, previously it could stretch it past its natural size, even though it's meant to reduce the child size rather than increase it.

Some apps relied on the previous (buggy) sizing behavior, and may need to be adjusted now that it's fixed.

Font additions

GNOME 48 has new fonts - Adwaita Sans and Adwaita Mono, replacing Cantarell and Source Code Pro. The change to Adwaita Sans is highly visible as almost every bit of text in the UI uses it. The monospace font, however, is a lot less visible. Let's look at why.

For a long time, GNOME has had the monospace-font-name preference, which wasn't actually used all that much. It's not exposed anywhere in GtkSettings , it's not used for the monospace style class in CSS (instead, the Monospace font is used), and so on.

To use it, apps need to listen to its changes manually and adapt their UI accordingly. When running in Flatpak, they also can't use GSettings for this and have to access the settings portal, manually or via libportal .

Only a small handful of apps went to those lengths - basically just terminals and text editors.

Similarly, there's also a document-font-name preference, intended to be used for the app content, e.g. articles (as opposed to UI). Similarly, it's really hard to use and has been mostly ignored.

So, libadwaita now handles both of them. AdwStyleManager has gained properties for retrieving them: :monospace-font-name and :document-font-name .

They are also exposed in CSS, as the --monospace-font-family , --monospace-font-size , --document-font-family and --document-font-size variables. In addition to that, the .monospace style class uses them automatically.

CSS editor in GTK Inspector is using .monospace and gets the new font automatically

The document font meanwhile isn't used anywhere in standard widgets or styles yet, but it may change in the future, e.g. to increase the text size there.

Miscellaneous style changes

A few smaller style changes happened this cycle.

Banners

Instead of using accent color for the entire widget, banners are now neutral, while the button can optionally use suggested style, controlled using the :button-style property.

Thanks to Jamie Murphy for this change.

Toasts

Toasts are now lighter and opaque. This helps them stand out and remain legible against dark backgrounds or on top of noisy content.

Colors

The UI colors throughout libadwaita styles are now very slightly tinted towards blue instead of using neutral grey color. In most cases it will just work, but apps that hardcode matching colors may need an update.

Tab overview is now using a darker background for light style and lighter background for dark style, to improve contrast with thumbnails.

Rounding

Widgets like buttons are now slightly more rounded. Apps may need to adjust border-radius on custom widgets to match in rare cases.

Other changes

• Thanks to an addition in GTK, AdwDialog now blocks app-wide and window-wide shortcuts, same as modal windows did.

• Emmanuele added easing functions based on cubic Bézier curves to AdwEasing : ADW_EASE , ADW_EASE_IN , ADW_EASE_OUT and ADW_EASE_IN_OUT .

• AdwPreferencesPage can now display a banner at the top, which allows to use banners in AdwPreferencesDialog .

• AdwAboutDialog can now link to other apps to showcase them.

  

• AdwBottomSheet now has a way to hide its bottom bar. This can be useful e.g. for music players that use the bottom bar to display the currently playing track, and want to hide it when nothing is playing.

• Peter Eisenmann added a convenience property for retrieving the visible page's tag in AdwNavigationView .

• Additionally, AdwNavigationView can now make its pages either horizontally or vertically homogeneous, meaning it will be as wide/tall as the largest page in its navigation stack rather than potentially resizing when switching pages.

• AdwNavigationSplitView now allows to put its sidebar after the content instead of before, same as AdwOverlaySplitView . In this case, the content is treated as the root page and the sidebar as subpage when collapsed, instead of the other way around.

• FineFindus added a way to dismiss all toasts at once in an AdwToastOverlay .

• AdwPreferencesDialog now hides the pages from the view switcher and search when their :visible property is set to FALSE .

• The .dim-label style class has been renamed to .dimmed to better reflect what it does (since it was never exclusive to labels). The old name is still available but deprecated.

---

Large parts of this work were made possible by STF funding. Additionally, thanks to all of the contributors who made this release possible.

Exciting news! The GNOME Internship Committee and Open Source Community Africa (OSCA) are teaming up to host the GNOME Internship event!
If you plan to apply for Google Summer of Code (GSoC) or Outreachy internships, this online event is for you!

Join us to:
Learn about these internship programs
Gain insights from past participants
Ask questions directly to mentors and organizers

This is a great opportunity to prepare your application, understand the selection process, and boost your chances of success!

Date: March 15th (Saturday)
Time: 4:00 PM – 7:00 PM UTC
Join here: https://meet.gnome.org/rooms/tl3-fsa-gyb-arq/join

Don’t miss out—mark your calendars and get ready to start your open-source internship journey with GNOME

• Up early, run with J. early partner call, then tech-planning call, sync with Lily; lunch; catch-up with Karen, mail chew.
• Dug into some profiles in the afternoon.

• Up early, mail chew, catch up with Dave.
• Published the next strip: looking at an exciting first steering commitee meeting.
  
• Partnership call, admin, lunch, sales call, plugged away at some code and planning.
• Bit of talk preparation in the evening. Finished Outies by Pournelle - suffered from trying to read it too quickly, perhaps should try again.