GNOME

Porting Files to GTK 4 has been helping me learn and appreciate even more the legacy of the nautilus software package. Its two-decades-long history is closely entangled with the history of the GNOME project. As I prepare to merge the removal of ... [More] more than 20 thousand lines of code, I’ve decided to stop and pay some tribute to the legacy widget that’s about to be decommissioned. Living legend The day is May 27, 1998: the day before the start of the Fourth Annual Linux Expo. Federico Mena, co-founder of the GNOME project, uploads a work-in-progress version of the GnomeCanvas widget. This widget would then be included in an “Initial revision” of nautilus as the basis for its icon view.     Screenshots from Eazel website, preserved by the Internet Archive. Federico’s 1998’s TODO list is still found, more than 23 years later, in the nautilus source code. Die-hard icons At some point renamed/forked to FooCanvas and later EelCanvas, this base widget continued to serve as the fundamental base for the GNOME desktop files and file browser’s icon view across major versions. However, as GNOME 3 no longer featured icons on desktop, a free-position canvas was no longer required. Various efforts were made to implement a less complex grid view, but the canvas refused to be dethroned easily. On Jul 22, 2012, Jon McCann renamed the icon-view to canvas-view to pave way for a new icon view. I recall that around that time there was a nautilus git branch implementing a new icon view using GtkIconView. The branch has since been deleted, and I can’t find an archived discussion about it, so I can’t assert why it has been abandoned. I think it was partly due to poor performance for a large number of items. In any case, GtkIconView, like EelCanvas, didn’t employ child widgets for the content items. This kept the content items from taking advantage of newer toolkit features. This was seen as a critical deficiency in the 2013 DX hackfest, which has prompted the introduction of GtkFlowBox, based on the earlier EggWrapBox widget. Fast forward to 2016, Carlos Soriano starts working on a new GtkFlowBox-based view. It was discussed in a hackfest later that year, but it was concluded that the performance for large directories was the biggest problem. It has been included in releases as an experimental setting, but couldn’t replace the old canvas. Another reason why the canvas stuck was that it was a requirement for the icons on desktop. While GNOME 3 didn’t use this, it was still a feature that was supported in nautilus and enabled in some distributions. Carlos has initially tried to separate the desktop icons into a separate program, but in the end the only viable solution was to drop the desktop icons implementation from nautilus. Enter GTK 4 In the early days of GTK 4 development, Ernestas Kulik has ported Files to that new in-development GTK version. This notably included a GTK 4 port of EelCanvas. It looked like the canvas would survive yet another major transition. However, GTK 4 would take a few more years to be developed, and the growing API changes would end up making a port of EelCanvas all but viable. The limited performance scalability of GtkFlowBox when used as a grid view for content apps has lead GTK developers to create scalable view widgets, which ultimately resulted in GtkGridView and its siblings, available in GTK 4. Now, this left Files development in a sort of a chicken and egg problem: adopting GtkGridView required porting to GTK 4 first, but porting to GTK 4 required replacing EelCanvas with something first. Interregnum So, I’ve picked up Carlos experimental GtkFlowBox-based view and completed it, in order to use it as a stand-in for GtkGridView until after the app is ported to GTK 4. It has reached feature parity with the canvas view, which is finally going to retirement. Old (EelCanvas-based) grid view on the left. New (GtkFlowBox-based) grid view on the right. I’m deleting EelCanvas in the git repository of nautilus, but the legacy of GnomeCanvas lives on in other software packages, such as Evolution or nautilus forks nemo and caja. One does not simply remove 20k LOC. [Less]

About two years ago, the Meson manual was published and made available for purchase. The sales were not particularly stellar and the bureaucracy needed to keep the sales channel going took a noticeable amount of time and effort. The same goes for ... [More] keeping the book continually up to date.Thus it came to pass that sales were shut down a year ago. At the time there were some questions on whether the book could be made freely available. This was not done, as it would not really have been fair to all the people who paid actual money to get it. So the book has been unavailable since.However since an entire year has passed since then, the time has come. I'm making the full PDF manual available for personal use. You can download your own copy via this link. The contents have not been updated in more than a year, so it's not really up to date on details but the fundamentals are still valid.Enjoy, and have a happy whatever-it-is-that-you-call-the-holiday-at-this-time-of-year.The boring small printEven though the book is freely downloadable it is not under any sort of an open license. You can download it and read it for personal use, but redistribution of any kind is not permitted. [Less]

Last minute end of year invoicing admin thrash; grateful for turning the bottom of people's budgets into Free Software in 2022. Pleased to see what we've achieved in 2022 with a nice Thank You blog from the marketing team.

Calls with various staff; company meet-up in gather.town, nice to see some different faces. Sync. with Andras. Julie & Isaac & David over for dinner - lovely to see them; played games variously in the evening.

So it's that time of the year again and about time for an end-of-year post.Some news in Maps for the upcoming GNOME 42.Finally, we have added support for running development versions of Maps (such as from the Nightly Flatpak repo) in parallel with ... [More] the stable onesThe develop one is distinguished by the “cogwheel” background in the headerbar, and also by it's ”bio-hazard” strip icon as seen above. Also we've had an old feature request laying around about supporting a command-line option to initiate a search.In the meantime in Evolution there was discussions about being able to launch a search using a configured map application, rather than just using the OpenStreetMap web-based search. In that issue it was suggested there is a draft maps: URI scheme that has been used by Apple Maps on iOS.So I have implemented this is Maps, so that Maps will now register as a mime-handler for the maps: URI scheme. And you can then open URIs of the form something like:maps:q=search%20queryThis could be tested from the command line using the gio command$ gio open maps:q=search%20query I also took the opportunity to add a DBus action to perform search.This can be tested using a command-line like the following:$ gdbus call --session --dest org.gnome.Maps.Devel --object-path /org/gnome/Maps/Devel --method org.freedesktop.Application.ActivateAction 'search' "[<'search query'>]" "{}" or by using the d-feet DBus debugger (and even though the output states no return, Maps will actually launch, or activate the currently running instance with the search performed).And I also implemented an old-school command-line argument -S with the same semantic (taking the search query as it's argument) as per the original feature request.These will either show the search popover in Maps when there are multiple search results, or just open the place bubble with the place selected when the search was specific enough to have a single result (such as when searching for a contact's address). Furthermore, as a little refinement the routing instructions for turn-by-turn based modes now also makes use of the u-turn icons: There was also a corner-case bug introduced by me when refactoring the instruction types to decouple them the GraphHopper-specific codes, resulting in a bug in some cases with u-turns preventing the route to show up. This was spotted, and fixed by one of our newcomer contributors Marina Billes.One thing missing when it comes to the instruction icons by the way is that we miss icons for “keep left” and “keep right”. So I've created an issue for that (https://gitlab.gnome.org/GNOME/gnome-maps/-/issues/410). (I first gave Inkscape a go, but I quickly realized icons attempt to draw looks more like deformed sausages :-) ). Another thing that's been on my mind for a while is the default zoom levels we use when “going to” a place when selecting a search result. Currently we find a suitable zoom level based on the so called bounding box of a feature (when it's available in the result item). This means things like buildings and parks can usually be shown initially so that it fits in the present window. For other object that are mere nodes (just a pair of coordinates), we have used some presets based on the place types as defined by the geocode-glib library. But these are quite limited and only covers a few cases.So I started playing with a WiP branch to select more fine-grained default zoom levels for more place types with a heuristic based on the types we get from the OSM data.This way, e.g. the continents (which are represented in OSM as nodes) gets a better fit, and not just defaults to a fully zoomed-in (as a fallback) place somewhere in a rural area or such: And also a few more distinct levels for different place “sizes”, such as hamlets so we don't have to resort to a “one size fits” all level more suitable for larger towns and cities:  And I guess that will wrap it up for this time!Happy Holidays everyone! [Less]

It took a long time, and massive amounts of energy and sweat and blood, but as of last week, Settings is finally ported to GTK4 and uses libadwaita for platform integration. This was by far the biggest application I’ve ported to GTK4. In total ... [More] , around 330 files needed to be either rewritten or at least modified as part of the porting process. It also required GTK4 ports of some dependencies, like gnome-desktop, libnma, and colord-gtk. The Users, Cellular, and Online Accounts panels aren’t ported yet. They have dependencies that needs porting, and we agreed on porting them afterwards. Some of these ports are tricky, such as the Online Accounts panel which requires a GTK4 version of WebKit2GTK – which depends on libsoup3, and that conflicts with librest’s dependency on libsoup2, so all of a sudden we have a bunch of intertwined dependencies to take care of. Another dependency that needs porting is GCR, but seems like it’s not going to be as complicated as Online Accounts. By using libadwaita, we will finally be able to standardize rows and preferences groups across different panels. There are contributors working on it already, and updates will be shared in no time, stay tuned! All in all, I’m pretty satisfied with this port. Settings is one of the largest GNOME applications, so having it ported before GNOME 42 was a small miracle. There are bugs to fix, issues to uncover, and regressions to iron out, but so far it’s been working well enough for mundane operations, and I expect it to mature enough until the release. As always, contributions fixing these regressions will be warmly welcomed. [Less]

Amidst the holidays that perhaps aren't turning out exactly as hoped, one can take comfort in small tokens of continuity – like the fact that xsnow is still being actively maintained. Thanks, everyone, for all the good software. Let's extract the best from the year to come.

You must have seen multiple apps which show the app’s information like app version and last updated at time in their footers or via a floating action button. In this tutorial, you’ll learn to create a component to show such kind of information in a ... [More] Nuxt app. Contents Prerequisites Reading App Information Files Creating an App Information Component Conclusion Prerequisites For this tutorial, it is assumed that you have already set up a Nuxt app and have a manual or automated way of adding .version and .last-updated-at files to your project. We build our Nuxt app using Github Actions. In our workflow, we have set up a system that automatically determines the next release version and adds it to the .version file. At the same time, it also creates a .last-updated-at file and adds to it the build date and time. Reading App Information Files The first step is to be able to read the contents of .version and .last-updated-at files. The only place this can be done is the nuxt.config.js. To read the files on the file system, first, you need to install the fs NPM package. To do so, open your terminal, navigate to your project directory and run the following command: npm install --save fs Next, add the following code at the start of the nuxt.config.js file: import fs from 'fs' // 1 let appVersion try { appVersion = fs.readFileSync('./.version', 'utf8') } catch (err) { appVersion = 'dev' } // 2 let appLastUpdatedAt try { appLastUpdatedAt = fs.readFileSync('./.last-updated-at', 'utf8') } catch (err) { appLastUpdatedAt = new Date() } In the above code: You try to read the .version file using the fs.readFileSync method and assign the result to appVersion. In case the .version file doesn’t exist, an error occurs, so appVersion is set to dev. In the same way, you try to read the .last-updated-at file using the fs.readFileSync method and assign the result to appVersion. In case the .last-updated-at file doesn’t exist, an error occurs, so appLastUpdatedAt is set to the current time (new Date()). Finally, in the export default object of the nuxt.config.js, add the appVersion and appLastUpdatedAt variables to the publicRuntimeConfig object: export default { ... // environment variables used by nuxt publicRuntimeConfig: { appVersion, appLastUpdatedAt, }, ... } By adding variables to publicRuntimeConfig, you can access them anywhere - both client and server side - in the Nuxt app using $config.appVersion and $config.appLastUpdatedAt. Creating an App Information Component Now that your configuration is set, it’s time to create an app information component. First, create an AppInfo.vue file in the components directory and add the following template code to it: <template> Version: {{ $config.appVersion }} /> Updated at: {{ $config.appLastUpdatedAt }} template> Next, you can import this component in a layout or in a page by adding the following code: <template> /> template> Finally, restart your Nuxt app by running the following command in your terminal: npm run dev Open your app in the browser and you’ll get something like this: We have skipped the styling part as you can style the app information component as per your liking. Conclusion That’s it! You have successfully implemented an app information component in your Nuxt app. In the same way, you can add things like Changelog, What’s New, and more to your app by taking the help of publicRuntimeConfig in a Nuxt app. [Less]

Its a time to be thankful for what you can do, rather than be pissed off about things that you can’t do because we’re in the 3rd year of a global pandemic. I made it home to Shropshire, in time to cast an important vote, and to spend Christmas ... [More] with my folks… something I couldn’t do last year. Work involves a client with software integration difficulties. Our goal is to enable a Python 3 migration in the company, which involves a tangle of dependencies in various languages. The interesting aspect is that we’re trialling BuildStream as the solution. We know BuildStream can control the mix of C/C++/Go/Java/etc. dependencies, in a way which Python-only tools like virtualenv cannot, and we hope it will be less friction compared to introducing a fullblown packaging system like DPKG. The project is challenging for a number of reasons and I am not enjoying working over VPN+SSH to another continent, but I’m sure we will learn a lot. I was excited to see Your Year in Music available on Listenbrainz this year. I’d love to be able to export the generated playlists with Calliope, but I don’t have the time to implement it myself. Besides that I am mostly concentrating on relaxing and finishing off some music. Here’s the weather in Wales today – cloud or snow? [Less]

I drafted a post on how the Dirtywave M8 is an amazing synth, but given the time and the growing scope of that post, I’ll sum it up in a short blurb instead. For a single man project, this synth is a miracle. Very geeky, all shortcut driven ... [More] , standing on the shoulders of tracker giants, particularly LSDJ, it has a solid workflow and most definitely isn’t a gimmick. You’ll have to do without any visual aid. This is what I love on the Elektron boxes, where the display really helps you understand what you’re doing when filtering or creating an LFO. All you have here are hex numbers and consistent shortcuts. But it sounds absolutely marvelous and allows you to create music anywhere. I’d like to share two tracks I’ve learned the ropes of the device on, but also the genre itself. I’ve listened to DNB mainly through Noisia/Vision radio podcast that made my runs possible (I hated running all my life, but it’s really the best way to combat the negative effects of sitting behind a computer all day). But I’ve never actually tried producing a track within that DNB realm. Tengu on Bandcamp. Woohan on Bandcamp. While I lean on samples for the beats, the base is all the internal FM (with multiple oscilator types, not just sine) and macrosynth engines. I’ve also been learning the ropes of Blender’s geometry nodes recently. While only scratching the surface, I created this visualizer for the track. The heavy lifting is done with baking the sound to f-curves, which is then somewhat tweaked to acceptable ranges with f-curve modifiers. I also have to mention the absolutely bonkers amazing visual identity of the M8 project. It just couldn’t be more hip. This is also my very last gear acquisition. For sure. Previously, Previously, Previously, Previously, Previously, Previously, Previously. [Less]