With apps made for different form factors, it can be hard to find what works for your specific device. For example, we know it can be a bit difficult to find great apps that are actually designed to be used on a mobile phone or tablet. To help solve this, we're introducing a new collection: On the Go.

As the premier source of apps for Linux, Flathub serves a wide range of people across a huge variety of hardware: from ultra powerful developer workstations to thin and light tablets; from handheld gaming consoles to a growing number of mobile phones. Generally any app on Flathub will work on a desktop or laptop with a large display, keyboard, and mouse or trackpad. However, devices with only touch input and smaller screen sizes have more constraints.

Revealing the App Ecosystem​

Using existing data and open standards, we're now highlighting apps on Flathub that report as being designed to work on these mobile form factors. This new On the Go collection uses existing device support data submitted by app developers in their MetaInfo, the same spec that is used to build those app's listings for Flathub and other app store clients. The collection is featured on the Flathub.org home page for all devices.

Many of these apps are adaptive across screen sizes and input methods; you might be surprised to know that your favorite app on your desktop will also work great on a Linux phone, tablet, or Steam Deck's touch screen. We aim to help reveal just how rich and well-rounded the app ecosystem already is for these devices-and to give app developers another place for their apps to shine and be discovered.

Developers: It's Up to You​

As of this writing there are over 150 apps in the collection, but we expect there are cases where app developers have not provided the requisite device support data.

If you're the creator of an app that should work well on mobile form factors but isn't featured in the collection, take a minute to double-check the documentation and your own apps's MetaInfo to ensure it's accurate. Device support data can also be used by native app store clients across form factors to determine what apps are displayed or how they are ranked, so it's a good idea to ensure it's up to date regardless of what your app supports.

05 Feb 2025 12:00am GMT

In the past I may have spoken critically on Truetype fonts and their usage in PDF files. Recently I have come to the conclusion that it may have been too harsh and that Truetype fonts are actually somewhat nice. Why? Because I have had to add support for CFF fonts to CapyPDF. This is a font format that comes from Adobe. It encodes textual PostScript drawing operations into binary bytecode. Wikipedia does not give dates, but it seems to have been developed in the late 80s - early 90s. The name CFF part is an abbeviation for "complicated font format".

Double-checks notes.

Compact font format. Yes, that is what I meant to write. Most people reading this have probably not ever even seen a CFF file so you might be asking why is supporting CFF fonts even a thing nowadays? It's all quite simple. Many of the Truetype (and especially OpenType) fonts you see are not actually Truetype fonts. Instead they are Transfontners, glyphs in disguise. It is entirely valid to have a Truetype font that is merely an envelope holding a CFF font. As an example the Noto CJK fonts are like this. Aggregation of different formats is common in font files, and the main reason OpenType fonts have like four different and mutually incompatible ways of specifying color emoji. None of the participating entities were willing to accept anyone else's format so the end result was to add all of them. If you want Asian language support, you have to dive into the bowels of the CFF rabid hole.

As most people probably do not have sufficient historical perspective, let's start by listing out some major computer science achievements that definitely existed when CFF was being designed.

• File format magic numbers
• Archive formats that specify both the offset and size of the elements within
• Archive formats that afford access to their data in O(number of items in the archive) rather than O(number of bytes in the file)
• Data compression

CFF chooses to not do any of this nonsense. It also does not believe in consistent offset types. Sometimes the offsets within data objects refer to other objects by their order in the index they are in. Sometimes they refer to number of bytes from the beginning of the file. Sometimes they refer to number of bytes from the beginning of the object the offset data is written in. Sometimes it refers to something else. One of the downsides of this is that while some of the data is neatly organized into index structures with specified offsets, a lot of it is just free floating in the file and needs the equivalent of three pointer dereferences to access.

Said offsets are stored with a variable width encoding like so:

This makes writing subset CFF font files a pain. In order to write an offset value at some location X, you first must serialize everything up to that point to know where the value would be written. To know the value to write you have to serialize the the entire font up to the point where that data is stored. Typically the data comes later in the file than its offset location. You know what that means? Yes, storing all these index locations and hotpatching them afterwards once you find out where the actual data pointed to ended up in. Be sure to compute your patching locations correctly lest you end up in lengthy debugging sessions where your subset font files do not render correctly. In fairness all of the incorrect writes were within the data array and thus 100% memory safe, and, really, isn't that the only thing that actually matters?

One of the main data structures in a CFF file is a font dictionary stored in, as the docs say, "key-value pairs". This is not true. The "key-value dictionary" is neither key-value nor is it a dictionary. The entries must come in a specific order (sometimes) so it is not a dictionary. The entries are not stored as key-value pairs but as value-key pairs. The more accurate description of "value-key somewhat ordered array" does lack some punch so it is understandable that they went with common terminology. The backwards ordering of elements to some people confusion bring might, but it perfect sense makes, as the designers of the format a long history with PostScript had. Unknown is whether some of them German were.

Anyhow, after staring directly into the morass of madness for a sufficient amount of time the following picture emerges.

Final words

The CFF specification document contains data needed to decipher CFF data streams in nice tabular format, which is easy to convert to an enum. Trying it fails with an error message saying that the file has prohibited copypasting. This is a bit rich coming from Adobe, whose current stance seems to be that they can take any document opened with their apps and use it for AI training. I'd like to conclude this blog post by sending the following message to the (assumed) middle manager who made the decision that publicly available specification documents should prohibit copypasting:

YOU GO IN THE CORNER AND THINK ABOUT WHAT YOU HAVE DONE! AND DON'T EVEN THINK ABOUT COMING BACK UNTIL YOU ARE READY TO APOLOGIZE TO EVERYONE FOR YOU ACTIONS!

04 Feb 2025 1:16pm GMT

At LaOficina we are currently working on a project to digitize family photographs and one of the challenges is the correct traceability of intellectual property. In this case we have encountered the difficulty of knowing the exact conditions of the received material, a situation that is not new and which is already addressed by the RightsStatements vocabulary, which includes 12 terms that are used, among others, by the Europeana community. Therefore, it is obvious that we need to add this vocabulary to our Wikibase Suite instance. By the way, as an exercise, I have taken the opportunity to compose it from scratch as an independent OWL ontology. It is very simple, but probably it has some conceptual flaws. If it is useful to someone, please use it without restrictions: righstatements-ontology.ttl

If you find something wrong please reach me.

03 Feb 2025 11:00pm GMT

• Breakfast, to the venue with some friends; pottered around talking to people, spoke briefly in the Government dev-room to lots of friendly faces.
• Lunch, got chatting in the queue for chips to several interesting people; back to the booth - before heading back and out to Kasbah in the evening - for a mercifully belly-dancing-free meal.
• Back to chat to Caolan & his lovely daughter - it was bring-a-family-member-to-work weekend, catch up until late.

03 Feb 2025 3:43pm GMT

So a we are a little bit into the new year I hope everybody had a great break and a good start of 2025. Personally I had a blast having gotten the kids an air hockey table as a Yuletide present :). Anyway, wanted to put this blog post together talking about what we are looking at for the new year and to let you all know that we are hiring.

Artificial Intelligence
One big item on our list for the year is looking at ways Fedora Workstation can make use of artificial intelligence. Thanks to IBMs Granite effort we know have an AI engine that is available under proper open source licensing terms and which can be extended for many different usecases. Also the IBM Granite team has an aggressive plan for releasing updated versions of Granite, incorporating new features of special interest to developers, like making Granite a great engine to power IDEs and similar tools. We been brainstorming various ideas in the team for how we can make use of AI to provide improved or new features to users of GNOME and Fedora Workstation. This includes making sure Fedora Workstation users have access to great tools like RamaLama, that we make sure setting up accelerated AI inside Toolbx is simple, that we offer a good Code Assistant based on Granite and that we come up with other cool integration points.

Wayland
The Wayland community had some challenges last year with frustrations boiling over a few times due to new protocol development taking a long time. Some of it was simply the challenge of finding enough people across multiple projects having the time to follow up and help review while other parts are genuine disagreements of what kind of things should be Wayland protocols or not. That said I think that problem has been somewhat resolved with a general understanding now that we have the 'ext' namespace for a reason, to allow people to have a space to review and make protocols without an expectation that they will be universally implemented. This allows for protocols of interest only to a subset of the community going into 'ext' and thus allowing protocols that might not be of interest to GNOME and KDE for instance to still have a place to live.

The other more practical problem is that of having people available to help review protocols or providing reference implementations. In a space like Wayland where you need multiple people from multiple different projects it can be hard at times to get enough people involved at any given time to move things forward, as different projects have different priorities and of course the developers involved might be busy elsewhere. One thing we have done to try to help out there is to set up a small internal team, lead by Jonas Ådahl, to discuss in-progress Wayland protocols and assign people the responsibility to follow up on those protocols we have an interest in. This has been helpful both as a way for us to develop internal consensus on the best way forward, but also I think our contribution upstream has become more efficient due to this.

All that said I also believe Wayland protocols will fade a bit into the background going forward. We are currently at the last stage of a community 'ramp up' on Wayland and thus there is a lot of focus on it, but once we are over that phase we will probably see what we saw with X.org extensions over time, that for the most time new extensions are so niche that 95% of the community don't pay attention or care. There will always be some new technology creating the need for important new protocols, but those are likely to come along a relatively slow cadence.

High Dynamic Range

As for concrete Wayland protocols the single biggest thing for us for a long while now has of course been the HDR support for Linux. And it was great to see the HDR protocol get merged just before the holidays. I also want to give a shout out to Xaver Hugl from the KWin project. As we where working to ramp up HDR support in both GNOME Shell and GTK+ we ended up working with Xaver and using Kwin for testing especially the GTK+ implementation. Xaver was very friendly and collaborative and I think HDR support in both GNOME and KDE is more solid thanks to that collaboration, so thank you Xaver!

Talking about concrete progress on HDR support Jonas Adahl submitted merge requests for HDR UI controls for GNOME Control Center. This means you will be able to configure the use of HDR on your system in the next Fedora Workstation release.

PipeWire
I been sharing a lot of cool PipeWire news here in the last couple of years, but things might slow down a little as we go forward just because all the major features are basically working well now. The PulseAudio support is working well and we get very few bug reports now against it. The reports we are getting from the pro-audio community is that PipeWire works just as well or better as JACK for most people in terms of for instance latency, and when we do see issues with pro-audio it tends to be more often caused by driver issues triggered by PipeWire trying to use the device in ways that JACK didn't. We been resolving those by adding more and more options to hardcode certain options in PipeWire, so that just as with JACK you can force PipeWire to not try things the driver has problems with. Of course fixing the drivers would be the best outcome, but for some of these pro-audio cards they are so niche that it is hard to find developers who wants to work on them or who has hardware to test with.

We are still maturing the video support although even that is getting very solid now. The screen capture support is considered fully mature, but the camera support is still a bit of a work in progress, partially because we are going to a generational change the camera landscape with UVC cameras being supplanted by MIPI cameras. Resolving that generational change isn't just on PipeWire of course, but it does make the a more volatile landscape to mature something in. Of course an advantage here is that applications using PipeWire can easily switch between V4L2 UVC cameras and libcamera MIPI cameras, thus helping users have a smooth experience through this transition period.
But even with the challenges posed by this we are moving rapidly forward with Firefox PipeWire camera support being on by default in Fedora now, Chrome coming along quickly and OBS Studio having PipeWire support for some time already. And last but not least SDL3 is now out with PipeWire camera support.

MIPI camera support
Hans de Goede, Milan Zamazal and Kate Hsuan keeps working on making sure MIPI cameras work under Linux. MIPI cameras are a step forward in terms of technical capabilities, but at the moment a bit of a step backward in terms of open source as a lot of vendors believe they have 'secret sauce' in the MIPI camera stacks. Our works focuses mostly on getting the Intel MIPI stack fully working under Linux with the Lattice MIPI aggregator being the biggest hurdle currently for some laptops. Luckily Alan Stern, the USB kernel maintainer, is looking at this now as he got the hardware himself.

Flatpak
Some major improvements to the Flatpak stack has happened recently with the USB portal merged upstream. The USB portal came out of the Sovereign fund funding for GNOME and it gives us a more secure way to give sandboxed applications access to you USB devcices. In a somewhat related note we are still working on making system daemons installable through Flatpak, with the usecase being applications that has a system daemon to communicate with a specific piece of hardware for example (usually through USB). Christian Hergert got this on his todo list, but we are at the moment waiting for Lennart Poettering to merge some pre-requisite work into systemd that we want to base this on.

Accessibility
We are putting in a lot of effort towards accessibility these days. This includes working on portals and Wayland extensions to help facilitate accessibility, working on the ORCA screen reader and its dependencies to ensure it works great under Wayland. Working on GTK4 to ensure we got top notch accessibility support in the toolkit and more.

GNOME Software
Last year Milan Crha landed the support for signing the NVIDIA driver for use on secure boot. The main feature Milan he is looking at now is getting support for DNF5 into GNOME Software. Doing this will resolve one of the longest standing annoyances we had, which is that the dnf command line and GNOME Software would maintain two separate package caches. Once the DNF5 transition is done that should be a thing of the past and thus less risk of disk space being wasted on an extra set of cached packages.

Firefox
Martin Stransky and Jan Horak has been working hard at making Firefox ready for the future, with a lot of work going into making sure it supports the portals needed to function as a flatpak and by bringing HDR support to Firefox. In fact Martin just got his HDR patches for Firefox merged this week. So with the PipeWire camera support, Flatpak support and HDR support in place, Firefox will be ready for the future.

We are hiring! looking for 2 talented developers to join the Red Hat desktop team
We are hiring! So we got 2 job openings on the Red Hat desktop team! So if you are interested in joining us in pushing the boundaries of desktop linux forward please take a look and apply. For these 2 positions we are open to remote workers across the globe and while the job adds list specific seniorities we are somewhat flexible on that front too for the right candidate. So be sure to check out the two job listings and get your application in! If you ever wanted to work fulltime on GNOME and related technologies this is your chance.

03 Feb 2025 12:29pm GMT

In talking with someone about "preferred form for modification" over the weekend at FOSDEM, the FSF (now sort-of-OSI?) four freedoms came up. They're not bad, but they're extremely developer-focused in their "use case". This is not a new observation, of course, but the changed technical and social context of AI seems to be bringing it to the fore that different users have different variations on the values and why open is so important to them.

Here's a very quick, rough cut of what I proposed instead as key freedoms, and who those matter for. These are not exclusive (eg in many cases developers also care about replication; businesses obviously frequently care about modification, etc.) but compared to the original four freedoms, convey that different stakeholders have different needs-all of which have been served, but not explicitly called out as metrics, by the FOSS movement over the years.

• modification (foremost, for developers): We like to play with things, and often can make them better in the process. Enough said.
• replication (foremost, for scientists): It's not really science if you can't replicate it, and you can't replicate it if it isn't really yours. High overlap with modification and transparency, but something other constituencies can often live without.
• transparency (foremost, for governments): you can't effectively regulate what you can't understand, and it's never OK for something that needs to be regulated to be opaque. (Obviously we allow this all the time but as we're all reminded this week that leads to all kinds of malignancies.)
• cost of re-use (foremost, for business): This is perhaps the least unique, but it's important to remember that statistically businesses very rarely modify open source. They pick and choose what they use, and compose them in almost entirely unique ways, but that's a property of architectural design and cost, not of ability to modify.

These of course get you to mostly the same place as the traditional four freedoms. But importantly for the discussion of "open in AI", replication and transparency require a focus on data, while for many businesses (and certainly for most developers) weights are sufficient and may well be preferred in many/most cases.

One could imagine other use cases and priorities, of course. But I wanted to bang this out quick and there was a nice symmetry to having four. Leave more on the various socials :)

03 Feb 2025 9:04am GMT

It's that time again, and we are in our 7th year doing this conference (if you include LAS GNOME).

This year, LAS will be held in Tirana, Albania and we are going all out this year to make it the best conference representing apps on Linux.

For those who don't know or have not heard of Linux App Summit, the idea is to have desktops work together to help enable application developers to build apps on the Linux platform. It's a parallel effort to the Flathub and Snapstore app stores.

LAS is positioned to promote third party developers, inform the ecosystems are the advances on the desktop, and for developers, designers, and contributors working on the desktops to meet each other and discuss how to move the platform forward as a community.

LAS's success depends on all of you. If you're passionate about making Linux as a viable alternative to proprietary platform then we need your help! Linux enables local control of your technology that you can adapt to your needs. Build local ecosystems enabling a local economy. A community driven platform will protect your privacy, safety, and security without bowing to shareholders or to politicians. This is the place to tell us about it!

So, I ask all of you to attend LAS, help drive our numbers up. Have a great idea that you won't to share with this ecosystem of developers? Implemented something on a phone, in an automobile, or something else? Have a great concept? Want to update all of us on what the next version of your app is going to do?

Through here, we can find out what is missing? What do we need to do move forward? What are the trends we should be looking at?

Feel free to reach out to our team and we'll be happy to answer any questions at info@linuxappsummit.org.

You can submit a talk at https://iinuxappsummit.org/cfp. You can register for the conference at https://linuxappsummit.org/register.

Can't come in person or give the talk in person? Not to worry! LAS is a hybrid conference and you can attend from remote even though we would love to meet you in person.

Finally, we are looking for sponsors. If you know of a company who would make a great sponsor please reach out. If you're interested in sponsoring LAS, you can email us at sponsors@linuxappsummit.org. For more info at https://linuxappsummit.org/sponsor.

03 Feb 2025 5:15am GMT

There is a storm coming and we are re-architecting our build infrastructure.

Buildbot has never been designed to do what Flathub needs: taking arbitrary inputs like application IDs and dynamically creating new pipelines. However, there's no misuse one cannot achieve if something is being configured in A Real Programming Language, and so, back in 2019, Alex Larsson piled a bunch of hacks so we could have not only dynamic configuration based on Flathub organization in GitHub, but also some custom views displaying latest builds.

Fast-forward to 2025, these hacks no longer work with the latest release of Buildbot, rendering our soft fork stuck on a version from 2021. For whatever reason, updating GitHub CI status stopped to work well, allowing people to merge untested code changes. It also requires periodical restarts because it grinds to a halt for no particular reason, dropping new builds in the meantime. The worst offense: I never liked it.

Interlude: Equinix Metal née Packet has been sponsoring our heavy-lifting servers doing actual building for the past 5 years. Unfortunately, they are shutting down, meaning we need to move out by the end of April 2025.

This perfect storm means we need to effectively re-architecture build infrastructure from scratch.

webhook-proxy​

Let's start from improving Buildbot reliability where it falls short. While GitHub shows delivery status of webhook events, and even provides a button to trigger another attempt, there's no public API exposing this data.

As there's no way I'm fixing Buildbot itself, I decided we need a middleman which will take care of redelivering if Buildbot's webhook endpoint responded with non-200 response.

webhook-proxy is a simple Python service which accepts payloads from GitHub, marks new pull requests as pending CI, then forwards unchanged events to Buildbot. Should Buildbot have a hiccup, it will open a circuit breaker and retry with exponential back off until it eventually succeeds.

It ain't much, but it's honest work.

justpak​

An important piece of the future Buildbot replacement is being agnostic of its CI/CD implementation. The idea is to provide only a business logic service, while actual building is delegated elsewhere. As such, it requires some relatively generic tool to execute tasks instead of maintaining two or more pipeline definitions for whatever is the CI/CD solution of the decade.

After evaluating modern make replacements, I settled on just. It seems simple enough for executing external commands, and has a nifty way of defining recipes with a specific shebang from the get-go, so it's all a single file even when using a mix of Python and Bash.

I copied all build steps done by the Buildbot workers to specific recipes to have a single entry point. Then I started doing back flips with GitHub Actions to see if this is a viable way in the first place; turns out it is, although not without some hurdles.

While GitHub Actions have a native way of executing all steps inside a Docker container, the host running said container is full of bloat and barely has any free disk space. bbhtt suggested how to remove unneeded files, which also meant each build step is prefixed with docker run as we want to re-use existing flatpak-builder-lint image instead of meddling with Ubuntu.

Then I went to GNOME GitLab to implement identical pipeline because I have no mouth and I must write YAML. GitLab has its set of quirks but after configuring its runners to stop dropping job output and kindly asking GitLab to stop unconditionally kill jobs whose logs exceeded a certain size, we've got the answer: it will blend!

Application ID	Buildbot	GitHub Actions	GNOME GitLab
Vim	4m 29s	3m 03s	1m 46s
Fractal	28m 29s	31m 09s	23m 37s
QGIS	123m 00s	198m 00s	124m 43s
Ungoogled Chromium	75m 28s	timed out at 6h	177m 29s

Apps on the smaller size can be safely built on GitHub Actions, but anything larger like Chromium, LibreOffice or KDE runtime will need some special treatment by being routed to GNOME GItLab. It's still not as fast as existing infrastructure is, but it will no longer be existing in a quarter, so there's nothing to be complaining about here. As both GitHub Actions and GitLab CI allow triggering workflows through API, it will be also easy to integrate with some external system.

The work-in-progress repo can be found here.

I was initially panicking about replacing aarch64 runners, but it turns out GitHub is providing that since September 2024. Build times are in line with the table above, meaning we are only worried about outliers. I have submitted Flathub to Works on Arm program, and if it gets accepted, we will handle that similarly to x86_64.

The rest of the owl​

It's all cool and dandy, but the crucial part is still missing: a service encapsulating business logic. Buildbot encapsulates starting new builds, figuring out where they should go (Is it a test build? Is it a beta build?), retries for failed builds and managing publishing, all of that with a fancy UI.

There's no punchline here: I'm only starting the legwork to figure out which language and framework to use. If you would like to see something specific implemented, don't hesitate to request it here.

03 Feb 2025 12:00am GMT

• Up early, met cool-kids at breakfast; to FOSDEM! Enjoyed talks in the LibreOffice dev-room, and meeting more hackers, partners, team-mates, old-friends and more. Gave various talks.
• Richer Collaboration in the collaboration dev-room with lots of the latest features to show off:
  
• Also a somewhat different selection of the latest changes on COOL - LibreOffice Technology in the browser in the LibreOffice dev-room as slides.
• Automatic Documents, packed with content and signed - on Attila & Miklos' recent work:
  
• Talked to people around our table in K, showed off my lack of general cluefulness in the FOSDEM Quiz before heading to Beta Co-working for a pasta dinner & good discussions.
• On to the XWIKI / Nextcloud party until very late in the evening.

02 Feb 2025 9:00pm GMT

As my Outreachy internship with GNOME concludes, I'm reflecting on the journey, the effort, the progress, and, most importantly, the future I envision in tech.

The past few months as an intern have been both challenging and incredibly rewarding. From quickly learning a new programming language to meet project demands, to embracing test-driven development and tackling progressively complex tasks, every experience has been a stepping stone. Along the way, I've honed my collaboration and communication skills, expanded my professional network, and developed a deep appreciation for the power of community and open source.

This Outreachy internship has been a pivotal experience, solidifying these values and teaching me the importance of embracing challenges and continuously improving my technical and interpersonal skills, preparing me for the next stage of my engineering career. The supportive environment I found in the GNOME community has been instrumental to my growth. I'm incredibly grateful for my mentor, Federico, who exemplified what true mentorship should be. He showed me the importance of collaborative spirit, genuine understanding of team members, and even taking time for laughter - all of which made transitioning to a new environment seamless and comfortable. His guidance fostered open communication, ensuring seamless synchronization and accessibility. Just before writing this, I had a call with Federico, Felipe (the GNOME Internship Coordinator, an awesome person!), and Aryan to discuss my career post-internship.

While the career advice was invaluable, what truly stood out was their collaborative willingness to support my growth. This dedication to fostering progress is something I deeply admire and will strive to make a core part of my own engineering culture.

My journey from intern to engineer has been significantly shaped by the power of community, and I'm now ready to push myself further, take on new challenges, and build a solid, impactful, and reputable career in technology.

Skills

I possess a strong foundation in several key technologies essential for software and infrastructure engineering.

My primary languages are Golang and Rust, allowing me to build high-performance and reliable systems. I also have experience with Python. I'm a quick learner and eager to expand my skillset further.

Career Goals

My ultimate career aspiration is to secure a role that challenges me to grow as an engineer while contributing to impactful and innovative projects. I am particularly drawn to:

• Cultivating a culture of creativity and structured development while optimizing myself to become the best engineer I can be-just like my Outreachy experience.
• Developing and sustaining critical infrastructure that powers large-scale, globally utilized systems, ensuring reliability, security, and seamless operation.
• Exploring opportunities at MANGA or other big tech companies to work on complex systems, bridging software engineering, security, and infrastructure.

motivations

While the challenge of growth is my primary motivation, the financial stability offered by these roles is also important, enabling me to further invest in my personal and professional development.

Relocation is a significant draw, offering the opportunity to experience different cultures, gain new perspectives and immerse myself in a global engineering community.

As an introverted and private person, I see this as a chance to push beyond my comfort zone, engage with a diverse range of collaborators, and build meaningful connections.

Job Search

I am actively seeking software engineering, infrastructure, and site reliability roles. I am particularly interested in opportunities at large tech companies, where I can contribute to complex systems and further develop my expertise in Golang and Rust after concluding my Outreachy internship with Gnome is concluded in march 2025.

exploring the opportunities

I'm eager to explore software engineering, open source, infrastructure, and site reliability roles. If your team is seeking someone with my skills and experience, I'd welcome a conversation. Connect with me via email or LinkedIn.

I'm excited about the future and ready to take the next step in my career. With the foundation I've built during this internship, I'm confident in my ability to make a meaningful impact in the tech industry

02 Feb 2025 5:53am GMT

We just had a GTK hackfest at FOSDEM. A good time for an update on whats new and exciting in GTK, with an eye towards 4.18.

Requirements

You can no longer call gdk_display_get_default() or gdk_display_open() before gtk_init(). This was causing problems due to incomplete initialization, so we made it fail with a (hopefully clear) error message. If you are affected by this, the usual fix is to just call gtk_init() as early as possible.

On Windows, we have a hard requirement on Windows 10 now. All older versions are long unsupported, and having to deal with a maze of ifdefs and unavailable APIs makes development harder than it should be. Dropping support for very old versions also simplifies the code down the stack, in Pango and GLib.

The same idea applies to macOS, where we now require macOS 10.15.

Spring cleaning

The old GL renderer has been removed. This may be unwelcome news for people stuck on very old drivers and hardware. But we will continue to make the new renderers work as well as possible on the hardware that they can support.

The X11 and Broadway backends have been deprecated, as a clear signal that we intend to remove them in the GTK 5. In the meantime, they continue to be available. We have also deprecated GtkShortcutsWindow, since it needs a new design. The replacement will appear in libadwaita, hopefully next cycle.

It is worth reminding everybody that there is no need to act on deprecations until you are actively porting your app to the next major version of GTK, which is not on the horizon yet.

Incremental improvements

Widget layout and size allocation has received quite a bit of attention this cycle, with the goal of improving performance (by avoiding binary search as much as possible) and correctness. Nevertheless, these changes have some potential for breakage, so if you see wrong or suboptimal layouts in applications, please let us know.

GTK has had difficulties for a while getting its pointer sizes right with fractional scaling on Wayland, but this should all be solved in GTK 4.18. No more huge pointers. Fixing this also required changes on the mutter side.

New beginnings

Accessibility in GTK 4.18 is taking a major step forward, with the new AccessKit backend, which gives us accessibility on Windows and macOS, for the very first time. The at-spi backend is still the default on Linux, and has seen a number of improvements as well.

And, maybe the biggest news: We have an Android backend now. It is still experimental, so you should expect some rough edges and loose ends. For example, there is no GL renderer support yet. But it is exciting that you can just try gtk4-demo on your phone now, and have it mostly work.

Enjoy!

01 Feb 2025 1:59pm GMT

Update on what happened across the GNOME project in the week from January 24 to January 31.

GNOME Core Apps and Libraries

Allan Day reports

GNOME changed its UI and monospace fonts this week, in a long anticipated change that is planned for GNOME 48. The new fonts are called Adwaita Sans and Adwaita Mono. Adwaita Sans is a modified version of Inter, and replaces Cantarell as the UI font. Adwaita Mono is a modified version of Iosevka, and replaces Source Code Pro as the default monospace font. This feature was implemented by Jamie Gravendeel, with last-minute assistance from Florian Muellner.

Libadwaita

Building blocks for modern GNOME apps using GTK4.

Alice (she/her) announces

libadwaita now provides API for accessing the system monospace and document fonts, both programmatically and from CSS.

Additionally, the .monospace style class uses the system font now, instead of monospace, so apps don't need to access it themselves from the settings portal and gsettings anymore

GTK

Cross-platform widget toolkit for creating graphical user interfaces.

Emmanuele Bassi says

The GTK developers held a hackfest in Brussels, covering various topics:

• accessibility
• text rendering
• deprecations
• new Android backend
• GTK5 features

A full report will be published on the GTK development blog, so keep a keen eye for it

Text Editor

Text Editor is a simple text editor that focus on session management.

Allan Day announces

Some news from a previous week: a collection of design updates have appeared in Text Editor, in time for the upcoming GNOME 48 release. The changes include a new document sidebar, which combines document properties and settings. There is also a new floating line/column indicator.

Settings

Configure various aspects of your GNOME desktop.

Allan Day reports

Work continued on GNOME's new Digital Wellbeing features this week. Changes were made to allow screen time to be viewed independently of the screen time limit feature, and a setting was added to allow screen time recording to be disabled. The labels in the settings panel were also polished. Much of this work was made possible by an Endless grant to the GNOME Foundation.

GNOME Circle Apps and Libraries

Brage Fuglseth (he/him) reports

This week Iotas was accepted into GNOME Circle. Iotas aims to provide distraction-free note taking, and lets you sync your notes across devices with Nextcloud. Congratulations!

Hieroglyphic

Find LaTeX symbols

FineFindus says

A new Hieroglyphic update has been released, bringing a number of improvements:

• Improved classifier, which now includes the nearly 500 user-contributed symbols, thanks to everyone who helped.
• The backend infrastructure has been updated to make it easier for future improvements to the classifier.
• The drawing area has been rewritten to use GTK4's rendering capabilities instead of Cairo.

Graphs

Plot and manipulate data

Sjoerd Stendahl reports

This week we released version 1.8.4 of Graphs, it's a minor release primarily focusing on the update to the GNOME 47 runtime:

• Update to the GNOME 47 runtime, with support for accent colours.
• The rubberband on the canvas has been improved, now it has rounded corners similar to Nautilus
• Equation parsing has been improved, now handling edge-cases better. It's now also completely case-insensitive, meaning "Pi" and "PI" are both acceptable variants of the greek letter π.

Meanwhile we're working hard on the next major release. The latest main channel on our Gitlab now has support for actual equations spanning an infinite canvas, and operations are calculated analytically with the equations changing their names accordingly. We've also got a brand new style-editor with a live preview. Stay tuned for an announcement on this later on, in the meantime you can check out the upcoming release on the Flathub beta channel.

Gaphor

A simple UML and SysML modeling tool.

Arjan announces

This week Dan Yeaw release Gaphor 3.0. This release is a major step forward. It contains a lot of UI updates. In addition Gaphor's internal data models has been updated and improved. More details you can find in this blog post. You can find the latest version in Flatpak. macOS and Windows versions are available from our website.

Third Party Projects

Fractal

Matrix messaging app for GNOME written in Rust.

Kévin Commaille announces

How are you going to find your friends and coordinate end of day drinks when you're lost in the middle of a large crowd in a big city? With the new version of your favorite Matrix client, of course! Here is Fractal 10.

• The QR code scanning code has been ported to libaperture, the library behind GNOME Camera. This should result in better performance and more reliability.
• OAuth 2.0 compatibility was added, to make sure that we are ready for the upcoming authentication changes for matrix.org.
• Pills for users and rooms mentions show consistently in the right place instead of seemingly random places, getting rid of one of our oldest and most annoying bug.
• Attachments go through the send queue, ensuring correct order of all messages and improving the visual feedback.
• Videos were often not playing after loading in the room history. This was fixed, and we also show properly when an error occurred.
• We were downloading too many different sizes for avatar images, which would fill the media cache needlessly. We now only download a couple of sizes. This has the extra benefit of fixing blurry or missing thumbnails in notifications.

As usual, this release includes other improvements and fixes thanks to all our contributors, and our upstream projects.

We want to address special thanks to the translators who worked on this version. We know this is a huge undertaking and have a deep appreciation for what you've done. If you want to help with this effort, head over to Damned Lies.

This version is available right now on Flathub.

We have a lot of improvements in mind for our next release, but if you want a particular feature to make it, the surest way is to implement it yourself! Start by looking at our issues or just come say hello in our Matrix room.

Parabolic

Download web video and audio.

Nick announces

Parabolic V2025.1.4 was also released this week with some new features and fixes!

Here's the full changelog:

• Added a new Embed Thumbnails option in Preferences to enable/disable Parabolic's downloading of thumbnails separate from metadata
• Added a disclaimer about embedding thumbnails/subtitles when using generic file types
• Fixed an issue where the incorrect previous video and/or audio format was selected
• Fixed an issue where chapters were embedded even if the option was disabled
• Fixed an issue where splitting media by chapters would result in incorrect media lengths in the split files
• Fixed an issue where video and audio formats were not selectable on GNOME

Events

Kristi Progri reports

CFP for Linux App Summit 2025 is now open! Join us in Tirana, Albania on April 25-26th. Submit your paper by Feb 15th https://conf.linuxappsummit.org/event/7/

For more information and updates check our website: https://linuxappsummit.org/

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!

31 Jan 2025 12:00am GMT

Introduction Built on jj and fzf, jj-fzf offers a text-based user interface (TUI) that simplifies complex versioning control operations like rebasing, squashing, and merging commits. This post will guide you through integrating jj-fzf into your Emacs workflow, allowing to switch between emacs and jj…

29 Jan 2025 11:54pm GMT

I finally got distracted enough to finish my website that has been saying "under construction" for over a year, since I set up this server for my Sharkey instance.

I've wanted to do this for a while - one, so that I actually have a home page, and two, so that I can move my blog here instead of using WordPress.

Setup

Initially I wanted to use a static generator like Hugo, but then I discovered that the web server I'm using (Caddy) can do templates. That's perfectly enough for a simple blog, so I don't actually need a separate generator. This very article is a markdown document, parsed and embedded into a nice-looking page and RSS feed using templates.

In addition, I get all the niceties I couldn't get before:

• Using Markdown instead of HTML with WordPress-specific additions for e.g. image galleries.

• Proper code listings with syntax highlighting (you'll have to view this on the original page though, not from Planet GNOME or your RSS reader):

  <property name="child">
    <object class="AdwToastOverlay" id="toast_overlay">
      <property name="child">
        <object class="AdwNavigationView" id="nav_view"/>
      </property>
    </object>
  </property>
  

• Dark mode support, incl. for images (again, no clue if this works on Planet GNOME):

  

• Just simple niceties like smaller monospace font - I do this a lot and I don't particularly like the way the WordPress theme I was using presents it.

• Finally, while migrating my old posts I had an opportunity to update broken links (such as to the old documentation) and add missing alt text as in quite a few images I set WordPress description instead of alt text and never noticed. If you really want the old version, it's still on the old website and each migrated article links to its original counterpart.

So yeah, so far this was fairly pleasant, I expected much worse. There are still a bunch of things I want to add (e.g. previewing images at full size on click), but it's not like my old blog had that either.

29 Jan 2025 12:00am GMT

As I've done some times previous years, I thought it would be appropriate to give a bit of a status update on goings on with regards to Maps before heading for this year's FOSDEM

Refreshed Location Marker

One of the things that landed since the December update are the new revamped location markers

The marker now uses the system accent color, and sports a "torch" indicating the current heading (when known).

And the circle indicating approximate accuracy of the location now has an outer contour.

And on these notes, I would also like to take the opportunity to mention the BeaconDB project (https://beacondb.net/) with the goal of building a community-sourced wireless positioning database. It is compatible the now-defunct Mozilla Location Service (MLS) and works as a drop-in-replacement with GeoClue.

Improved Visuals for Public Transit Routes Lists

The "badges" showing line numbers/names for public transit journeys, and markers for shown on the map when selecting a trip has been improved to avoid some odd label alignments and better looking contours (on lower contrast against light or dark background). The labels are now drawn directly using GSK instead of piggy-backing on a GtkLabel, doing some Cairo drawing on top of that. One additional benefit here is that it also gets rid of some of the remaining usages of the GdkPixbuf APIs (which will be gone in a future GTK 5).

Transitous Move to MOTIS 2

On the subject of transit, Transitous has now migrated to the new MOTIS 2 API. And consequently the support in Maps has been updated to use the new API (this is also backported to the stable 47.3 release).

The new API is easier to use, and more in-line with the internal data types in Maps, so the code was also a bit simpler. Also now with the new API we get the walking instructions directly from MOTIS instead of using GraphHopper to compute walking "legs". This has made searching for routes in Maps quite a bit faster as well.

FOSDEM

And when talking about FOSDEM, me, Felix Gündling, and Jonah Brüchert will host a talk about Transitous in the "Railways and Open Transport" devroom (K.6.401) on Sunday @ 16:30 CET

https://fosdem.org/2025/schedule/event/fosdem-2025-4105-gnome-maps-meets-transitous-meets-motis/

So maybe see you in FOSDEM!

28 Jan 2025 9:07pm GMT

In October 2024 some members of our community gathered in Medelin, Colombia, for another edition of GNOME Latam. Some of us joined remotely for a schedule packed with talks about GNOME and its ecosystem.

The talks, in Spanish and Portuguese, are now published on YouTube. Check it out!

27 Jan 2025 3:52pm GMT