Work pressure + Burnout == Low contributions?

Over the past few months, I’ve been struggling with a tough question. How do I balance my work commitments and personal life while still contributing to open source?

On the surface, it looks like a weird question. Like I really enjoy contributing and working with contributors, and when I was in college, I always thought... "Why do people ever step back? It is so fun!". It was the thing that brought a smile to my face and took off any "stress". But now that I have graduated, things have taken a turn.

It is now that when work pressure mounts, you use the little time you get to not focus on writing code and instead perform some kind of hobby, learn something new or spend time with family. Or, just endless video scroll and sleep.

This has led me to be on my lowest contributions streak and not able to work on all those cool things I imagined, like reworking the Pitivi timeline in Rust, finishing that one MR in GNOME Settings that is stuck for ages, or fixing some issues in GNOME Extensions website, or work on my own extension's feature request, or contributing to the committees I am a part of.

It’s reached a point where I’m genuinely unsure how to balance things anymore, and hence wanted to give all whom I might not have been able to reply to or have not seen me for a long time an update, that I'm there but just in a dilemma of how to return.

I believe I'm not the only one who faces this. After guiding my juniors for a long while on how to contribute and study at the same time and still manage time for other things, I now am at a road where I am in the same situation. So, if anyone has any insights on how they manage their time, or keep up the motivation and juggle between tasks, do let me know (akaushik [at] gnome [dot] org), I'd really appreciate any insights :)

One of them would probably be to take fewer things on my plate?

Perhaps this is just a new phase of learning? Not about code, but about balance.

One of the unintended side-effects of writing applications using language bindings is that you inherit the dependencies of the binding.

This made things a bit complicated when GIRepository moved from gobject-introspection-1.0 to girepository-2.0 as we very much want language bindings to move to the new API.

Where this adds great difficulty on maintainers is in projects like Libpeas which provides plug-in capabilities for GTK application developers across multiple programming languages.

In practice this has allowed applications like Gedit, Rhythmbox, and GNOME Builder to be written in C but load plugins from languages such as Python, Lua, JavaScript, Rust, C, C++, Vala, or any other language capable of producing a .so / .dylib / .dll .

A very early version of Libpeas, years before I took over maintaining the library, had support for GObject Introspection baked in. This allowed really interesting (at the time) tooling to perform dynamic method call dispatching using a sort of proxy object implemented at runtime. Practically nobody is using this feature from what I can tell.

But maintaining ABI being what it is, the support for it has long been part of the libpeas-1.x ABI.

A couple years ago I finally released a fresh libpeas-2.x ABI which removed a lot of legacy API. With objects implementing GListModel and PleasPluginInfo becoming a GObject , the need for libpeas-gtk dwindled. It’s extremely easy for your application to do everything provided by the library. Additionally, I removed the unused GObject Introspection support which means that libpeas-2.x no longer needs to link against gobject-introspection-1.0 (nor girepository-2.0 ).

One area where those are still used is the testsuite. This can complicate testing because we want to make sure that APIs work across language bindings but if the language binding uses a specific version of GObject Introspection that does not align with what the libpeas project is using for tests, it will of course lead to runtime disasters.

Such is the case with some language bindings. The Lua LGI project is scarcely maintained right now and still uses gobject-introspection-1.0 instead of girepository-2.0 . I submitted patches upstream to port it over, but without an official maintainer well versed in C and language bindings there isn’t anyone to review and say “yes merge this”.

There is a fork now that includes some of the patches I submitted upstream, but the namespace is different so it isn’t a 1:1 replacement.

The PyGObject project has moved to girepository-2.0 upstream and that caused some breakage with applications in Fedora 42 that were still using the legacy libpeas-1.x ABI. For that reason, I believe the older PyGObject was released With Fedora 42.

If you are using libpeas-2.x in your application, you have nothing to fear with any of the language runtimes integrated with libpeas. Since libpeas doesn’t link against either introspection libraries, it can’t hurt you. Just make sure your dependencies and language bindings are all in sync and you should be fine.

If you are using libpeas-1.x still (2.x was released a little over 2 years ago) then you are in a much worse shape. Language bindings are moving (or have moved) to girepository-2.0 while libpeas cannot realistically be ported and maintain ABI. Too much is exposed as part of the library itself.

It is imperative that if you want to keep your application working that you are either on libpeas-2.x or you’re bundling your application in such a way that you can guarantee your dependencies are all on the same version of GObject Introspection.

Halfway ABI

There exists a sort of “half-way-ABI” that someone could work on with enough motivation which is to break ABI as a sort of libpeas-1.38 . It would move to girepository-2.0 and all the ABI side-effects that come with it. Since the introspection support in libpeas-1.x is rarely used there should be little side-effects other than recompiling against the new ABI (and the build system transitions that go along with that).

In my experience maintaining the largest application using libpeas (being Builder), that is really a lot more effort than porting your applications to libpeas-2.x .

Is my app effected?

So in short, here are a few questions to ask yourself to know if you’re affected by this.

• Does my application only use embedded plug-ins or plug-ins from shared-modules such as *.so ? If so, then you are all set!
• Do I use libpeas-1.x? If no, then great!
• Does my libpeas-1.x project use Python for plug-ins? If yes, port to libpeas-2.x (or alternatively work suggested halfway-ABI for libpeas).
• Does my libpeas-1.x or libpeas-2.x project use Lua for plug-ins? If yes, make sure all your dependencies are using gobject-introspection-1.0 only. Any use of girepository-2.0 will end in doom.

Since JavaScript support with GJS/MozJS was added in libpeas-2.x , if you’re using JavaScript plug-ins you’re already good. GJS recently transitioned to girepository-2.0 already and continues to integrate well with libpeas. But do make sure your other dependencies have made the transition.

How this could have been avoided?

Without a time machine there are only three options besides what was done and they all create their own painful side-effects for the ecosystem.

1. Never break ABI even if your library was a stop gap, never change dependencies, never let dependencies change dependencies, never fix anything.
2. When pulling GObject Introspection into the GLib project, rename all symbols to a new namespace so that both libraries may co-exist in process at the same time. Symbol multi-versioning can’t fix overlapping type name registration in GType.
3. Don’t fix any of the glaring issues or inconsistencies when pulling GObject Introspection into GLib. Make gobject-introspection-1.0 map to the same thing that girepository-2.0 does.

All of those have serious side-effects that are equal to if not worse than the status-quo.

Those that want to “ do nothing ” as maintainers of their applications can really just keep shipping them on Flatpak but with the Runtime pinned to their golden age of choice.

Moral of the story is that ABI’s are hard even when you’re good at it. Doubly so if your library does anything non-trivial.

It’s Friday, so it’s time for a GNOME Foundation update, and there are some exciting items to share. As ever, these are just the highlights: there’s plenty more happening in the background that I’m not covering.

Fundraising progress

I’m pleased to be able to report that, in recent weeks, the number of donors in our Friends of GNOME program has been increasing. These new regular donations are already adding up to a non-trivial rise in income for the Foundation, which is already making a significant difference to us as an organization.

I’d like to take this moment to thank every person who has signed up with a regular donation. You are all making a major difference to the GNOME Foundation and the future of the GNOME project. Thank you! We appreciate every single donation.

The new contributions we are receiving are vital, but we want to go further, and we are working on our plans for both fundraising and future investments in the GNOME project.

New accountant

This week we secured the services of a new accountant, Dawn Matlak . Dawn is extremely knowledgeable, and comes with a huge amount of relevant experience, particularly around fiscal hosting. She’s also great to work with, and we’re looking forward to collaborating with her.

Dawn is going to be doing a fair amount of work for us in the coming months. In addition to helping us to prepare for our upcoming audit, she is also going to be overhauling some of our finance systems, in order to reduce workloads, increase reliability, and speed up processing.

GNOME.Asia

In other news, GNOME.Asia 2025 is happening in Tokyo on 13-15 December, and it’s approaching fast! Talk submissions have been reviewed and accepted, and the schedule is starting to come together. Information is being added to the website, and social activities are being planned. It’s shaping up to be a great event.

Registration for attendees isn’t open just yet, but it isn’t far off – look out for the announcement.

That’s it from me this week. I am on vacation next week, so I’ll be skipping next week’s post. See you in two weeks!

GTK has been using SVG for symbolic icons since essentially forever. It hasn’t been a perfect relationship, though.

Pre-History

For the longest time (all through the GTK 3 era, and until recently), we’ve used librsvg indirectly, through gdk-pixbuf, to obtain rendered icons, and then we used some pixel tricks to recolor the resulting image according to the theme.

This works, but it gives up on the defining feature of SVG: its scalability.

Once you’ve rasterized your icon at a given size, all you’re left with is pixels. In the GTK 3 era, this wasn’t a problem, but in GTK 4, we have a scene graph and fractional scaling, so we could do *much* better if we don’t rasterize early.

Unfortunately, librsvg’s API isn’t set up to let us easily translate SVG into our own render nodes. And its rust nature makes for an inconvenient dependency, so we held off on depending on it for a long time.

History

Early this year, I grew tired of this situation, and decided to improve our story for icons, and symbolic ones in particular.

So I set out to see how hard it would be to parse the very limited subset of SVG used in symbolic icons myself. It turned out to be relatively easy . I quickly managed to parse 99% of the Adwaita symbolic icons, so I decided to merge this work for GTK 4.20.

There were some detours and complications along the way. Since my simple parser couldn’t handle 100% of Adwaita (let alone all of the SVGs out there), a fallback to a proper SVG parser was needed. So we added a librsvg dependency after all. Since our new Android backend has an even more difficult time with rust than our other backends, we needed to arrange for a non-rust librsvg branch to be used when necessary.

One thing that this hand-rolled SVG parser improved upon is that it allows stroking, in addition to filling. I documented the format for symbolic icons here .

Starting over

A bit later, I was inspired by Apple’s SF Symbols work to look into how hard it would be to extend my SVG parser with a few custom attributes to enable dynamic strokes.

It turned out to be easy again . With a handful of attributes , I could create plausible-looking animations and transitions. And it was fun to play with. When I showed this work to Jakub and Lapo at GUADEC, they were intrigued, so I decided to keep pushing this forward, and it landed in early GTK 4.21, as GtkPathPaintable .

To make experimenting with this easier, I made a quick editor.  It was invaluable to have Jakub as an early adopter play with the editor while I was improving the implementation. Some very good ideas came out of this rapid feedback cycle, for example dynamic stroke width.

You can get some impression of the new stroke-based icons Jakub has been working on here .

Recent happenings

As summer was turning to fall, I felt that I should attempt to support SVG more completely, including grouping and animations. GTK’s rendering infrastructure has most of the pieces that are required for SVG after all: transforms, filters, clips, paths, gradients are all supported.

This was *not* easy.

But eventually, things started to fall into place. And this week, I’ve replaced  GtkPathPaintable with GtkSvg , which is a GdkPaintable that supports SVG. At least, the subset of SVG that is most relevant for icons. And that includes animations.

This is still a subset of full SVG, but converting a few random lottie files to SVG animations gave me a decent success rate for getting things to display mostly ok.

The details are spelled out here .

Summary

GTK 4.22 will natively support SVG, including SVG animations.

If you’d like to help improve this further, here are some some suggestions.

If you would like to support the GNOME foundation, who’s infrastructure and hosting GTK relies on, please donate .

Time for another GNOME Crosswords release! This one highlights the features our interns did this past summer. We had three fabulous interns — two through GSoC and one through Outreachy. While this release really only has three big features — one from each — they were all fantastic.

Thanks goes to to my fellow GSoC mentors Federico and Tanmay. In addition, Tilda and the folks at Outreachy were extremely helpful. Mentorship is a lot of work, but it’s also super-rewarding. If you’re interested in participating as a mentor in the future and have any questions about the process, let me know. I’ll be happy to speak with you about them.

Dictionary pipeline improvements

First, our Outreachy intern Nancy spent the summer improving the build pipeline to generate the internal dictionaries we use. These dictionaries are used to provide autofill capabilities and add definitions to the Editor, as well as providing near-instant completions for both the Editor and Player. The old pipeline was buggy and hard to maintain. Once we had a cleaned it up, Nancy was able to use it to effortlessly produce a dictionary in her native tongue: Swahili.

We have no distribution story yet, but it’s exciting to have it so much easier to create dictionaries in other languages. It opens the door to the Editor being more universally useful (and fulfills a core GNOME tenet).

You can read about it more details in Nancy’s final report .

Word List

Victor did a ton of research for Crosswords, almost acting like a Product Manager. He installed every crossword editor he could find and did a competitive analysis , noting possible areas for improvement. One of the areas he flagged was the word list in our editor. This list suggests words that could be used in a given spot in the grid. We started with a simplistic implementation that listed every possible word in our dictionary that could fit. This approach— while fast — provided a lot of dead words that would make the grid unsolvable. So he set about trying to narrow down that list.

It turns out that there’s a lot of tradeoffs to be made here ( Victor’s post ). It’s possible to find a really good set of words, at the cost of a lot of computational power. A much simpler list is quick but has dead words. In the end, we found a happy medium that let us get results fast and had a stable list across a clue. He’ll be blogging about this shortly.

Victor also cleaned up our development docs , and researched satsolve algorithms for the grid. He’s working on a lovely doc on the AC-3 algorithm, and we can use it to add additional functionality to the editor in the future.

Printing

Toluwaleke implemented printing support for GNOME Crosswords.

This was a tour de force, and a phenomenal addition to the Crosswords codebase. When I proposed it for a GSoC project, I had no idea how much work this project could involve. We already had code to produce an svg of the grid — I thought that we could just quickly add support for the clues and call it a day. Instead, we ended up going on a wild ride resulting in a significantly stronger feature and code base than we had going in.

His blog has more detail and it’s really quite cool ( go read it! ). But from my perspective, we ended up with a flexible and fast rendering system that can be used in a lot more places. Take a look:

The resulting PDFs are really high quality — they seem to look better than some of the newspaper puzzles I’ve seen. We’ll keep tweaking them as there are still a lot of improvements we’d like to add, such as taking the High Contrast / Large Text A11Y options into account. But it’s a tremendous basis for future work.

Increased Polish

There were a few other small things that happened

• I hooked Crosswords up to Damned Lies . This led to an increase in our translation quality and count
• This included a Polish translation, which came with a new downloader!
• I ported all the dialogs to AdwDialog, and moved on from (most) of the deprecated Gtk4 widgets
• A lot of code cleanups and small fixes

Now that these big changes have landed, it’s time to go back to working on the rest of the changes proposed for GNOME Circle.

Until next time, happy puzzling!

A few months ago, I introduced my GSoC project : Adding Printing Support to GNOME Crosswords . Since June, I’ve been working hard on it, and I’m happy to share that printing puzzles is finally possible!

The Result

GNOME Crosswords now includes a Print option in its menu, which opens the system’s print dialog. After adjusting printer settings and page setup, the user is shown a preview dialog with a few crossword-specific options, such as ink-saving mode and whether (and how) to include the solution. The options are intentionally minimal, keeping the focus on a clean and straightforward printing experience.

Below is a short clip showing the feature in action:

The resulting file: output.pdf

Crosswords now also ships with a standalone command-line tool, ipuz2pdf , which converts any IPUZ puzzle file into a print-ready PDF. It offers a similarly minimal set of layout and crossword-specific options.

The Process

• Studied and profiled the existing code and came up with an overall approach for the project.
• Built a new grid rendering framework, resulting in a 10× speedup in rendering. Dealt with a ton of details around text placement and rendering, colouring, shapes, and more.
• Designed and implemented a print layout engine with a templating system , adjusted to work with different puzzle kinds, grid sizes, and paper sizes.
• Integrated the layout engine with the print dialog and added a live print preview .
• Bonus: Created ipuz2pdf , a standalone command-line utility (originally for testing) that converts an IPUZ file into a printable PDF.

The Challenges

Working on a feature of this scale came with plenty of challenges. Getting familiar with a large codebase took patience, and understanding how everything fit together often meant careful study and experimentation. Balancing ideas with the project timeline and navigating code reviews pushed me to grow both technically and collaboratively.

On the technical side, rendering and layout had their own hurdles. Handling text metrics, scaling, and coordinate transformations required a mix of technical knowledge, critical thinking, and experimentation. Even small visual glitches could lead to hours of debugging. One notably difficult part was implementing the box layout system that powers the dynamic print layout engine.

The Lessons

This project taught me a lot about patience, focus, and iteration. I learned to approach large problems by breaking them into small, testable pieces, and to value clarity and simplicity in both code and design. Code reviews taught me to communicate ideas better, accept feedback gracefully, and appreciate different perspectives on problem-solving.

On the technical side, working with rendering and layout systems deepened my understanding of graphics programming. I also learned how small design choices can ripple through an entire codebase, and how careful abstraction and modularity can make complex systems easier to evolve.

Above all, I learned the value of collaboration, and that progress in open source often comes from many small, consistent improvements rather than big leaps.

The Conclusion

In the end, I achieved all the goals set out for the project, and even more. It was a long and taxing journey, but absolutely worth it.

The Gratitude

I’m deeply grateful to my mentors, Jonathan Blandford and Federico Mena Quintero , for their guidance, patience, and support throughout this project. I’ve learned so much from working with them. I’m also grateful to the GNOME community and Google Summer of Code for making this opportunity possible and for creating such a welcoming environment for new contributors.

What Comes After

No project is ever truly finished, and this one is no exception. There’s still plenty to be done, and some already have tracking issues . I plan to keep improving the printing system and related features in GNOME Crosswords.

I also hope to stay involved in the GNOME ecosystem and open-source development in general. I’m especially interested in projects that combine design, performance, and system-level programming. More importantly, I’m a recent CS graduate looking for a full-time role in the field of interest stated earlier. If you have or know of any opportunities, please reach out at feyidab01@gmail.com .

Finally, I plan to write a couple of follow-up posts diving into interesting parts of the process in more detail. Stay tuned!

Thank you!

• Slept badly, up early, mail chew, sync with Dave. Plugged away at 2026 projections with Julie & Tracie.
• Published the next TORF strip highlighting why what everyone really wants is a support and maintenance subscription:
  
• Snatched lunch, engaging CP all-hands meeting, all afternoon & evening Collabora quarterly mgmt meeting.

I have just released CapyPDF 1.8. It's mostly minor fixes and tweaks but there are two notable things. The first one is that CapyPDF now supports variable axis fonts. The other one is that CapyPDF will now produce PDF version 2.0 files instead of 1.7 by default. This might seem like a big leap but really isn't. PDF 2.0 is pretty much the same as 1.7, just with documentation updates and deprecating (but not removing) a bunch of things. People using PDF have a tendency to be quite conservative in their versions, but PDF 2.0 has been out since 2017 with most of it being PDF 1.7 from 2008.

It is still possible to create version with older PDF specs. If you specify, say, PDF/X3, CapyPDF will output PDF 1.3 as the spec requires that version and no other even though, for example, Adobe's PDF tools accept PDF/X3 whose version later than 1.3.

The PDF specification is currently undergoing major changes and future versions are expected to have backwards incompatible features such as HDR imaging. But 2.0 does not have those yet.

Things CapyPDF supports

CapyPDF has implemented a fair chunk of the various PDF specs:

• All paint and text operations
• Color management
• Optional content groups
• PDF/X and PDF/A support
• Tagged PDF (i.e. document structure and semantic information)
• TTF, OTF, TTC and CFF fonts
• Forms (preliminary)
• Annotations
• File attachments
• Outlines
• Page naming

Laravel Mix “Unable to Locate Mix File” Error: Causes and Fixes

If you’re working with Laravel and using Laravel Mix to manage your CSS and JavaScript assets, you may have come across an error like this:

Spatie\LaravelIgnition\Exceptions\ViewException  
Message: Unable to locate Mix file: /assets/vendor/css/rtl/core.css

Or in some cases:

Illuminate\Foundation\MixFileNotFoundException
Unable to locate Mix file: /assets/vendor/fonts/boxicons.css

This error can be frustrating, especially when your project works perfectly on one machine but fails on another. Let’s break down what’s happening and how to solve it.

What Causes This Error?

Laravel Mix is a wrapper around Webpack , designed to compile your resources/ assets (CSS, JS, images) into the public/ directory. The mix() helper in Blade templates references these compiled assets using a special file: mix-manifest.json .

This error occurs when Laravel cannot find the compiled asset . Common reasons include:

1. Assets are not compiled yet
   If you’ve just cloned a project, the public/assets folder might be empty. Laravel is looking for files that do not exist yet.
2. mix-manifest.json is missing or outdated
   This file maps original asset paths to compiled paths. If it’s missing, Laravel Mix won’t know where to find your assets.
3. Incorrect paths in Blade templates
   If your code is like: <link rel="stylesheet" href="{{ asset(mix('assets/vendor/css/rtl/core.css')) }}" /> but the RTL folder or the file doesn’t exist, Mix will throw an exception.
4. Wrong configuration
   Some themes use variables like $configData['rtlSupport'] to toggle right-to-left CSS. If it’s set incorrectly, Laravel will try to load files that don’t exist.

How to Fix It

Here’s a step-by-step solution:

1. Install NPM dependencies

Make sure you have Node.js installed, then run:

npm install

2. Compile your assets

• Development mode (fast, unminified):

npm run dev

• Production mode (optimized, minified):

npm run build

This will generate your CSS and JS files in the public folder and update mix-manifest.json .

3. Check mix-manifest.json

Ensure the manifest contains the file Laravel is looking for:

"/assets/vendor/css/rtl/core.css": "/assets/vendor/css/rtl/core.css"

4. Adjust Blade template paths

If you don’t use RTL, you can set:

$configData['rtlSupport'] = '';

so the code doesn’t try to load /rtl/core.css unnecessarily.

5. Clear caches

Laravel may cache old views and configs. Clear them:

php artisan view:clear
php artisan config:clear
php artisan cache:clear

Pro Tips

• Always check if the file exists in public/assets/... after compiling.
• If you move your project to another machine or server, you must run npm install and npm run dev again.
• For production, make sure your server has Node.js and NPM installed , otherwise Laravel Mix cannot build the assets.

Conclusion

The “Unable to locate Mix file” error is not a bug in Laravel , but a result of missing compiled assets or misconfigured paths. Once you:

1. Install dependencies.
2. Compile assets,
3. Correct Blade paths, and
4. Clear caches; your Laravel project should load CSS and JS files without issues.