Update on what happened across the GNOME project in the week from February 03 to February 10.

GNOME Core Apps and Libraries

Software

Lets you install and update applications and system extensions.

Philip Withnall announces

Georges blogged about some nice performance improvements he’s made in gnome-software recently: https://feaneron.com/2023/02/07/profiling-optimizing-gnome-software/

GLib

The low-level core library that forms the basis for projects such as GTK and GNOME.

Philip Withnall reports

Emmanuele Bassi has just landed a new GPathBuf API in GLib, for easily building file paths, https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3216

GNOME Incubating Apps

Loupe

A simple and modern image viewer.

Sophie reports

This week we made a bunch of progress in planning out the image rendering for Loupe. Not only did we land the first upstream tweak we needed, but we also discussed neat upcoming features in GTK that Loupe can make use of.

I also landed a few minor tweaks.

• Added a double-tap gesture on touchscreens for zooming in and out
• Added a more natural rubber-band effect for zoom gestures when hitting the maximum or minimum zoom level
• Added some space between the images in the sliding view
• Fixed some issues for right-to-left text direction
• Fixed swipe gesture on touchscreens
• Added shortcuts for the Home and End button to got to the first or last image

GNOME Circle Apps and Libraries

gtk-rs

Safe bindings to the Rust language for fundamental libraries from the GNOME stack.

slomo says

Just in time for the GNOME 44 API/ABI freeze there was a new gtk-rs release, and new releases of the Rust bindings for various other GNOME libraries. Check https://gtk-rs.org/blog/2023/02/10/new-release.html for the release notes.

Gaphor

A simple UML and SysML modeling tool.

Arjan says

TWIG-Bot Last weekend, Gaphor 2.16.0 has been released.

• The Model browser now supports multi select
• The GUI has been improved: diagram name shows in the header, improvements in spadding, backdrop when no diagrams are opened and icons. Thanks to Tobias Bernard.
• The editor’s CSS editor now supports dark mode and variables.
• It’s now easier to add top-level packages and diagrams in the model browser.

Third Party Projects

nxyz says

This week I released Paleta , a simple gtk4/libadwaita app that allows you to extract colors from an image and manage them in palettes. Extraction is done with the color-thief library and palettes are saved persistently. You can get it from Flathub .

Hunter Wittenborn announces

After a few months of work, Celeste has been released. Celeste is a file synchronization application, written in GTK, that can connect to a wide variety of cloud providers, including Google Drive, Dropbox, Nextcloud, ownCloud, and WebDAV. More storage types are also planned for the future, including Microsoft OneDrive and Amazon S3.

Celeste can be installed as a Flatpak , Snap , or Debian package .

The project is currently in it’s alpha state, so if you have any issues please report them on the project’s issue tracker .

fiaxh reports

Dino 0.4 was released . Dino is a secure and privacy-friendly messaging application. It uses the XMPP (Jabber) protocol for decentralized communication. The release adds support for message reactions and replies. We also switched from GTK3 to GTK4 and make use of libadwaita now.

Diego Iván says

This week, I released a PDF Metadata Editor . Edit the title, author, keywords, creator, producer, creation and modification dates of your PDF documents. You can get it from Flathub .

Daniel Wood announces

This week Design, a 2D CAD application for GNOME gets all touchy! Adding gesture input, usability improvements on small screens and more…

• Touch input for pan, pinch to zoom and double tap to zoom all
• Fix tabs not being shown
• Fixes for text rotation
• Fix files being read incorrectly
• Fix ARC selection
• Improve selection precision
• Added ability to Save As
• Handle keyboard shortcuts

Design 43-alpha3 is available from Flathub: https://flathub.org/apps/details/io.github.dubstar_04.design

Gradience

Change the look of Adwaita, with ease.

tfuxu says

This week, Gradience version 0.4.0 have been released, this release is a preparation for 0.8.0, the next major release that will bring GNOME Shell theming support and other long awaited features. Version 0.4.0 introduces a CLI interface, some bug fixes and general quality of life improvement changes.

Here are some of the changes:

• Added CLI interface, useful for creating scripts or for those who prefer terminal tools (CLI guide available here )
• Now Gradience warns user when switching to other presets, if current one has unsaved changes
• When running Gradience from terminal, you will see easier to understand error messages, thanks to the new logging facility
• Fixed sorting in “Explore” tab of Preset Manager not working with non-English locales
• Now Gradience will now internally use hexadecimal color values or RGBA formatted colors if transparency is used

And some other bug fixes and under-the-hood improvements. You can find more detailed changelog here .

As always, the latest release is available to download from Flathub .

Gir.Core

Gir.Core is a project which aims to provide C# bindings for different GObject based libraries.

badcel announces

Gir.Core 0.3.0 was released. Most prominent features in this release include:

• Addition of WebKitGtk to the supported libraries
• Improved runtime behaviour if using .NET 7 instead of .NET 6
• New C test library to not rely on API of other libraries to do unit tests
• Support for detailed signals via GObject.Signal.Connect
• The GType of a class / interface is now available in the public API

Additionally there were several bugs fixed, some new API was made available and some code cleanup took place. For details checkout the release notes .

Denaro

A personal finance manager.

Nick announces

Denaro V2023.2.0 is here! Your favorite weekly pizza man is back with a new update for your favorite personal finance manager! In this update, we gave users the ability to add passwords to protect and encrypt their account files, we provided a way for users to transfer money between accounts of different currencies, and we improved the look and feel of the application, as well as many, many other features and enhancements. Here’s a full changelog:

• Added the ability to add a password to an account (This will encrypt the nmoney file)
• Added the ability to transfer money between accounts with different currencies by providing a conversion rate in TransferDialog
• Added the ability to configure how Denaro uses locale separators in amount fields
• Added the ability to copy individual transactions
• Added the ability to sort transactions by amount
• LC_MONETARY and LC_TIME will now be respected
• Added “Help” button to toast notification when there are 0 imported transactions
• Recent accounts are now available to select from the TransferDialog
• Improved importing of qif and ofx files
• Added a “New Window” action to the main menu

Shell Extensions

Cleo Menezes Jr. reports

Version 16 of Auto Activities has been released.

In this new version, the user is able to choose between showing the activities overview or the apps grid when there are no windows in the workspace. In addition, the maximum window check delay limit has been increased from 1 to 10 seconds

Special thanks to Zetta1Reid0 who helped implement this.

Follow the development Get it on GNOME Extensions

Just Perfection

A tweak tool to customize the GNOME Shell and to disable UI elements.

Just Perfection says

Just Perfection GNOME Shell Extension version 23 released with more features such as overview spacing size, screen recording and sharing indicator visibility, switcher popup delay, …

This version named after Spanish painter Francisco Goya.

We also had some bug fixes in this version.

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!

Some of the core GTK developers recently got together for a few days to do some focused work and talk about current and future plans.

It is difficult to summarize three days of discussions in a blog post, but here are some of the highlights.

Icon themes

The GtkIconTheme code has been with us for a long time. It implements the icon theme spec, and comes from an era when we were shipping big sets of icons with the desktop and themes were expected to switch them out. That is not really how icons are made or used today.

We need a better solution for the workflow from a designer making icons a set of icons in a sheet to the developer copying individual icons into their app.

Inside GTK, this will need some form of “asset manager” to maintain the mapping from icon name to image / file / resource.

Languages

While we can’t get away from providing a C interface with gobject-introspection metadata for all our language bindings, it could be nice to use a more expressive language and a more powerful compiler than C has to offer.

Of course we can’t and won’t rewrite all of GTK in a different language. It would be nice to experiment with replacing smaller parts. Allowing new code to be written in different languages would also potentially bring in new contributors.

Input

We discussed the scroll speed question, and decided to write up an explanatory comment in the issue about what we consider the right solution:

• treat wheel and touchpad scrolling separately
• inject configuration from the control-center/compositor into libinput
• gtk gets it via events

The other big input question we talked about is ‘asynchronous event handling’ and its problems. The two main cases where this comes up are webkit, with its ui<>web process communication, and IBus. In both cases, we think that there is no actual interest in reinjecting unhandled events into the GTK capture/bubble propagation. Instead, such leftover event should just be handled ‘locally’ (in the IBus case, adding/removing characters to the entry, or moving the cursor).

Platform libraries

With GTK4, we’ve made the intentional change to move away from having everything in GTK itself, and instead introduced the idea of  ‘platform libraries’ like libadwaita to carry the more platform-specific widgetry.

Overall, we are happy with how this has turned out, and we would like to continue with this approach. There is maybe room for moving some things that are more plumbing than widgetry back into GTK itself.

GTK5 ?

We need to open a .90 branch to do things that would break the APIs that we have deprecated now (like the file chooser, and more general the chooser dialog/widget split). Some of us have been itching to start on that work. But there’s also still a lot of work to be done in 4.x (GtkListView fixes, for example).

With an eye towards the color management work that is planned to land in 4.12, the suggestion is to open a 4.90 development branch after 4.12. That would put it towards the end of this year, and 3 years after the 4.0 release, which seems reasonable.

The End

On the last day, we had the pleasure of hosting both the documentation and the tracker teams at our place.

Three hackfests in a room!

We’d like to thank the GNOME foundation for supporting our meeting.

This was my first time attending FOSDEM and I had a lot of fun! It truly lived up to my expectations of full corridors, lots of known faces, and Delirium.

During the conference days I was around the GNOME booth where interactions were great! Lots of people passing by and sharing kind words of appreciation to our desktop. We had lots of interest in GUADEC and LAS, as well as many people curious about the state of GNOME on mobile. The t-shirt/hoodie sales were a huge success! We were pretty much sold out by Sunday morning.

Special thanks to Kristi, Caroline, Rosanna, Sonny, David, Regina, Martin, Anisa, Rob, Zeeshan, and everyone that helped in the booth (I’m probably missing here people that were at the booth when I was elsewhere). Also, shoutout to the GNOME corridor gang!

On Saturday afternoon we had a mini-docs hackfest to work on the GNOME Settings documentation . There has been lots of recent GNOME Settings changes that made part of our docs outdated, so our mission was to update the docs. I think we did a great job getting the ball rolling for the new panels docs and discussing future work.

I would like to thank David King, Dominika Vágnerová, and Petr Kovar for attending the hackfest, and the GNOME Foundation for sponsoring the space where the Settings-docs and the GTK hackfests took place.

Next on my conference plans is Linux App Summit ! If you missed the news, the Call for Proposals is now open! Hurry up!

After a whole lot of bashing my head against the desk I finally managed to find out what Acrobat reader's "error 14" means, I managed to make both font subsetting and graphics generation work. Which means you can now do things like this:

After this improving the code to handle full PDF graphics seems mostly to be a question of adding functions for all primitives in the PDF graphics model. The big unknown thing is PDF form support, of which I know nothing. Being a new design it probably is a lot less convoluted than PDF fonts were.

Dependencies

The code is a few thousand lines of C++ 20. It requires surprisingly few dependencies:

• Fmt
• Zlib
• Libpng
• Freetype
• LittleCMS

Some of these are not actually necessary. Fmtlib will be in the standard library in C++23. Libpng is only used to load PNG images from disk. The library could require its users to load graphics themselves and pass images in as pixel arrays. Interestingly doing font subsetting requires parsing the raw data of TrueType files by hand, so Freetype is not strictly mandatory, though it does make some things easier.

The only things you'd actually need are Zlib and LittleCMS. If one wanted to support CCIT Group 4 compression for 1 bit images, you'd need a dependency on libtiff.

A plain C API

The unfortunate side of library development is that if you want your library to be widely used, you have to provide a plain C API. For PDF it's not all that bad as you can mostly copy what Cairo does as its C API is quite nice to use. You might want to design this early on as getting the C API as easy and reliable to use as possible has effects on how the internal architecture works. As an example you should make all objects independent of each other. If the end user has to do things like "be sure to destroy all objects of type X before calling function F on object Y", then, because this is C, they are going to get it wrong and cause segfaults (at best).

Python integration

Once you have the C API, though, you can do all sorts of fun things, such as using Python's ctypes module . It takes a bit of typing and drudgery, but eventually you can create a "dependencyless" Python wrapper. With it you can do this to create an empty PDF file:

o = PdfOptions()
g = PdfGenerator(b"python.pdf", o)
g.new_page()

That's all you can do ATM, as these are the only methods exposed in the C API. Just implementing these made it very clear that the API is not good and needs to be changed.

When working on GTK 4, special care was taken to ensure that most of a GtkTextView ‘s content could be rendered without GL program changes and maximal use of glDrawArrays() with vertices from a VBO.

That goes a long way towards making smooth scrolling.

In recent releases, GTK gained support for scrolling using more precise scroll units. On macOS with Apple touchpads, for example, that might map physical distance to a certain number of logical pixels within the application.

If you’re at 2x scaling, you might get values from the input system with “half pixel” values (e.g. .5 ) since that would map just fine to the physical pixel boundary of the underlying display server.

That’s great for our future, but not everything from GTK’s early designs around X11 have been excised from the toolkit. Currently, widget allocations are still integer based, meaning at 2x scaling they will sit on 2x physical pixel boundaries even though 1x physical pixel boundaries would be just fine to keep lines sharp (assuming you aren’t fractionally scaling afterwards).

Furthermore, GtkTextView works in logical pixels as well. That means that if you want to smooth scroll a text view and you get those 0.5 logical pixel values (1x physical pixels) you wont scroll until you get to 1.0 which then jumps you 2x physical pixels.

That can create some unsightly jitter, most noticeable during kinetic deceleration.

To fix the widget allocation situation, a future ABI break in GTK would have to move to some sort of float / double for widget coordinates. Everything underneath GTK (like GSK/GDK/Graphene/etc) is already largely doing this as GDK went through substantial improvements and simplification for GTK 4.

But with a little creativity, abstraction, and willingness to completely break ABI for a prototype, you can get an idea of what that would be like.

I put together a quick branch today which makes GtkTextView use double for coordinates so that I could push it to snap to physical pixel boundaries.

The fun thing is finding all the ways it breaks stuff. Like text underline getting into situations where it looks different as you scroll or having to allocate GtkWidget embedded within the GtkTextView on logical pixels.

Like I said earlier, it completely breaks ABI of GtkTextView , so don’t expect to replace your system GTK with it or anything.

Over the past few months, the Endless OS Foundation has been putting focus on improving GNOME Software’s reliability and performance. Endless OS is an OSTree-based immutable OS, and applications are entirely distributed as Flatpaks. GNOME Software is the frontend to that, and since our target userbase is definitely not going to use a terminal, we need to make sure GNOME Software delivers a good experience.

This focus has been materializing with Philip’s long effort to switch GNOME Software to a different threading model , more suitable to what Software does these days; and more recently, I’ve been tasked to look at GNOME Software’s performance from a profiling perspective.

Profile, Profile, Profile

I’ve been looking at performance-related tasks for many years now. It’s a topic of investigation that I personally enjoy, even if it’s a bit annoying and frustrating at times. My first real, big performance investigation was some good six years ago, on GNOME Music . Back then, the strategy to profiling was: guess what’s wrong, change that, see if it works. Not exactly a robust strategy. Luckily, it worked for that particular case.

Then over the next year I started to contribute to Mutter and GNOME Shell, and one of my first bigger performance-related investigations in this area involved frame timings, GJS, and some other complicated stuff . That one was a tad bit more complicated, and it still relied on gut feelings, but luckily some good improvements came out of that too.

Those two instances of gut-based profiling are successful when put like this, but that’s just a trick with words. Those two efforts were successful due to a mix of ungodly amounts of human effort, and luck. I say this because just a few months after, the GNOME Performance Hackfest took place in Cambridge, UK, and that was the beginning of a massive tsunami that took the GNOME community.

This tsunami is called profiling .

In that hackfest, Christian and Jonas started working on integrating Sysprof and Mutter / GNOME Shell. Sysprof was already able to collect function calls without any assistance, but this integration work enabled, for example, measuring where in the paint routines was GNOME Shell taking time to render. Of course, we could have printed timestamps in the console and parsed that, but let’s be honest, that sucks. Visualizing data makes the whole process so much easier.

So much easier that even a fool like myself could contribute. After quickly picking up the work where Jonas left , GNOME Shell was able to produce profiling data like below:

GNOME Shell frame timing marks on Sysprof, as it was in 2018

That integration, alone, allowed us to abandon the Old Ways of profiling, and jump head first into a new era of data-based optimizations. Just looking at the data above, without even looking at function calls, we can extract a lot of information. We can see that the layout phase was taking 4ms, painting was taking 5ms, picking was taking ~2ms, and the whole process was taking ~12ms. Looking at this data in depth is what allowed, for example, reducing pick times by 92% , and rendering times by a considerable factor too.

The most important lesson I could derive from that is: optimizing is borderline useless if not backed by profiling data. Always profile your app, and only optimize based on profiling data. Even when you think you know which specific part of your system is problematic, profile that first, just to confirm.

With these lessons learned, of course, I used this approach to profile GNOME Software.

Profiling an App Store

Naturally, the problem domain that GNOME Software – an app store – operates into is vastly different from that of GNOME Shell – a compositor. GNOME Software is also in the middle of a major transition to a new threading model, and that adds to the challenge of profiling and optimizing it. How do you optimize something that’s about to receive profound changes?

Fortunately for us, GNOME Software already had a basic level of integration with Sysprof, which gave some introspection on how it was spending its time, but not enough. My initial reaction was to extend this Sysprof integration and cover more events, in a more hierarchical manner . The goal was to improve whatever was making navigation through categories slow.

This proved to be a successful strategy. Here’s what profiling GNOME Software gave us:

Zoom in in the image. Take a few seconds to analyse it. Can you spot where the issue is?

If not, let’s do this together.

This slice of profiling shows that the GsPluginJobListApps operation (first line) took 4 whole seconds to execute. That’s a long time! This operation is executed to list the apps of a particular category. This means people have to wait 4 entire seconds, just to see the apps of a category. Certainly a usability killer, exploring these apps is supposed to be fun and quick, and this issue hurts that.

You may notice that there are other sub-events beneath GsPluginJobListApps . The first line is the timing of the whole operation, and beneath that, we have the timings of each individual sub-operation it does to end up with a list of apps.

Skimming through the entire profiler window, the widest black bars beneath the first line are, in order of appearance:

• GsPluginJobListApps:flatpak taking 600ms
• GsPluginJobRefine taking 3.6 seconds
  • GsPluginJobRefine:flatpak taking 600ms
  • GsPluginJobRefine:icons taking about 3 seconds

What that tells us is that the GsPluginJobListApps operation runs a GsPluginJobRefine sub-operation, and the icons are what’s taking most of the time there. Icons!

Refining is GNOME Software terminology for gathering metadata about a certain app, such as the name of the author, origin of the application, description, screenshots, icons, etc.

Icons!

Contrary to all my expectations, what was clear in these profiling sessions is that loading icons was the worst offender to GNOME Software’s performance when navigating through categories. This required further investigation, since there’s a fair bit of code to make icon management fast and tight on memory.

It didn’t take long to figure out what was happening.

Some applications declare remote icons in their metadata, and GNOME Software needs to download these icons. Turns out, in Flathub , there are a couple of apps that declare such remote icons, but the icons don’t actually exist in the URL they point to! Uh oh. Obviously these apps need to fix their metadata, but we can’t let that make GNOME Software slow to a crawl.

Knowing exactly what was the problem, it wasn’t difficult to come up with potential solutions. We always have to download and cache app icons, but we can’t let that block loading categories, so the simplest solution is to queue all these downloads and continue loading the categories . The difference is quite noticeable when comparing with the current state:

Most of the time, GNOME Software already has access to a local icon, or a previously downloaded and cached icon, so in practice it’s hard to see them downloading.

Final Thoughts

I hope to have convinced you, the reader, that profiling your application is an important step when working on optimization. This article is focused on the timing marks, since they’re the easiest to understand on a quick glance, but these marks have little meaning when not accompanied with the function calls stack. There’s a lot to unpack on the subject, and sometimes this feels more like an art than simply a mechanical evaluation of numbers, but it sure it a fun activity.

Sadly, until very recently, even profiling was still a major pain – although much less painful than guess-based profiling – since you’d need to build at least your app and some of its dependencies with debug symbols to get a meaningful call stack. Most of the profiling I’ve mentioned above required building all dependencies up to GLib with debug symbols.

However, seems like a game changing decision has been made by the Fedora community to finally enable frame pointers on their packages by default. And that means that the setup overhead to perform profiling like the above is brutally reduced, it’s almost trivial even, and I’m hopeful with the prospects of democratizing profiling like this. At the very least, I can say that this is a massive improvement to desktop developers.