Podcast
Planet GNOME
Hosted by Unknown Author · EN
Planet GNOME - https://planet.gnome.org/
11episodes
Episodes
Newest firstAll episodes
Tobias Bernard: Introducing Project Aardvark
Dec 18, 2024Tap to summarizeTwo weeks ago we got together in Berlin for another (Un)boiling The Ocean event (slight name change because Mastodon does not deal well with metaphors). This time it was laser-focused on local-first sync, i.e. software that can move seamlessly between real-time collaboration when there’s a network connection, and working offline when there is no connection. The New p2panda This event was the next step in our ongoing collaboration with the p2panda project. p2panda provides building blocks for local-first software and is spearheaded by Andreas Dzialocha and Sam Andreae. Since our initial discussions in late 2023 they made a number of structural changes to p2panda, making it more modular and easier to use for cases like ours, i.e. native GNOME apps. Sam and Andreas introducing the new p2panda release. This new version of p2panda shipped a few weeks ago, in the form of a dozen separate Rust crates, along with a new website and new documentation. On Saturday night we had a little Xmas-themed release party for the new p2panda version, with food, Glühwein, and two talks from Eileen Wagner (on peer-to-peer UX patterns) and Sarah Grant (on radio communication). The Hackfest Earlier on Saturday and then all day Sunday we had a very focused and productive hackfest to finally put all the pieces together and build our long-planned prototype codenamed “Aardvark”, a local-first collaborative text editor using the p2panda stack. Simplified diagram of the overall architecture, with the GTK frontend, Automerge for CRDTs, and p2panda for networking. Our goal was to put together a simple Rust GTK starter project with a TextView, read/write the TextView’s content in and out of an Automerge CRDT, and sync it with other local peers via p2panda running in a separate thread. Long story short: we pulled it off! By the end of the hackfest we had basic collaborative editing working on the local network (modulo some bugs across the stack). It’s of course still a long road from there to an actual releasable app, but it was a great start. https://blogs.gnome.org/tbernard/files/2024/12/aardvark-demo.webm The reason why we went with a text editor is not because it’s the easiest thing to do — freeform text is actually one of the more difficult types of CRDT. However, we felt that in order to get momentum around this project it needs to be something that we ourselves will actually use every day. Hence, the concrete use case we wanted to target was replacing Hedgedoc for taking notes at meetings (particularly useful when having meetings at offline, where there’s no internet). The current state of Aardvark: Half of the UI isn’t hooked up to anything yet, and it only sort of works on the local network :) While the Berlin gang was hacking on the text editor, we also had Ada, a remote participant, looking into what it would take to do collaborative sketching in Rnote. This work is still in the investigation stage, but we’re hopeful that it will get somewhere as a second experiment with this stack. Thanks to everyone who attended the hackfest, in particular Andreas for doing most of the organizing, and Sam Andreae and Sebastian Wick, who came to Berlin specifically for the event! Thanks also to Weise7 for hosting us, and offline for hosting the release party. The Long Game Since it’s early days for all of this stuff, we feel that it’s currently best to experiment with this technology in the context of a specific vertically integrated app. This makes it easy to iterate across the entire stack while learning how best to fit together various pieces. However, we’re hoping that eventually we’ll settle on a standard architecture that will work for many types of apps, at which point parts of this could be split out into a system service of some kind. We could then perhaps also have standard APIs for signaling servers (sometimes needed for peers to find each other) and “dumb pipe” sync/caching servers that only move around encrypted packets (needed in case none of the other peers are online). With this there could be many different interchangeable sync server providers, making app development fully independent of any specific provider. Martin Kleppmann’s talk at Local-First Conf 2024 outlines his vision for an ecosystem of local-first apps which all use the same standard sync protocol and can thus share sync services, or sync peer-to-peer. This is all still pretty far out, but we imagine a world where as an app developer the only thing you need to do to build real-time collaboration is to integrate a CRDT for your data, and use the standard system API for the sync service to find peers and send/receive data. With this in place it should be (almost) as easy to build apps with seamless local-first collaboration as it is to build apps using only the local file system. Next Steps It’s still early days for Aardvark, but so far everyone’s very excited about it and development has been going strong since the hackfest. We’re hoping to keep this momentum going into next year, and build the app into a more full-fledged Hedgedoc replacement as part of p2panda’s NGI project by next summer. That said, we see the main value of this project not in the app itself, but rather the possibility for our community to experiment with local-first patterns, in order to create capacity to do this in more apps across our ecosystem. As part of that effort we’re also interested in working with other app developers on integration in their apps, making bindings for other languages, and working on shared UI patterns for common local-first user flows such as adding peers, showing network status, etc. If you’d like to get involved, e.g. by contributing to Aardvark, or trying local-first sync in your own app using this stack feel free to reach out on Matrix (aardvark:gnome.org), or the Aardvark repo on Github. Happy hacking!
Transcribe →Cassidy James Blaede: Publish Your Godot Engine Game to Flathub
Dec 11, 2024Tap to summarizeIf you follow me on the fediverse (@cassidy@blaede.family), you may have seen me recently gushing about ROTA, a video game I recently discovered. Besides the absolutely charming design and ridiculously satisfying gameplay, the game itself is open source, meaning the developer has published the game’s underlying code out to the world for anyone to see, learn from, and adapt. As someone passionate about the Linux desktop ecosystem broadly and Flathub as an app store specifically, I was excited by the possibility of helping to get ROTA onto Flathub so more people could play it—plus, such a high-quality game being on Flathub helps the reputation and image of Flathub itself. So I kicked off a personal project (with the support of my employer¹) to get it onto Flathub—and I learned a lot—especially what steps were confusing or unclear. As a result, here’s how I recommend publishing your Godot Engine game to Flathub. Oh, and don’t be too scared; despite the monumental size of this blog post, I promise it’s actually pretty easy! 😇 Overview 1. Handling Your PCK File Bonus Points: Export in CI About That Binary… 2. Desktop Entry, Icon, and MetaInfo Files Desktop Entry Icon MetaInfo Bonus Points: Flathub Quality Guidelines 3. Flatpak manifest You Did It! Bonus Points: Publishing Updates Definitions Overview Let’s take a look at what we’re going to achieve at a high level. This post assumes you have source code for a game built with a relatively recent version of Godot Engine (e.g. Godot Engine 3 or 4), access to a Linux computer or VM for testing, and a GitHub account. If you’re missing one of those, get that sorted before continuing! You can also check the list of definitions at the bottom of this page for reference if you need to better understand something, and be sure to check out the Flathub documentation for a lot more details on Flatpak publishing in general. To build a Flatpak of a Godot Engine game, we only need three things: Exported PCK file Desktop Entry, icon, and MetaInfo files Flatpak manifest to put it all together The trick is knowing how and where to provide each of these for the best experience publishing your game (and especially updates) to Flathub. There are a bunch of ways you can do it, but I strongly recommend: Upload your PCK file to a public, versioned URL, e.g. as a source code release artifact. Include the Desktop Entry, icon, and MetaInfo files in the repo with your game’s source code if it’s open source, or provide them via a dedicated repo, versioned URL, or source code release artifact. You can alternatively upload these directly to the Flatpak Manifest repository created by Flathub, but it’s better to keep them with your game’s other files if possible. Your manifest will live in a dedicated GitHub repo owned by the Flathub org. It’s nice (but not required) to also include a version of your manifest with your game’s source code for easier development and testing. Before we get into each of those steps in more detail, you will need to pick an app ID for your game. This is a unique machine-oriented (not intended for humans to need to know) ID used across the Linux desktop and throughout the Flatpak process. It must be in valid reverse domain name notation (RDNN) format for a domain or code hosting account associated with the game; for example, if your website is example.com, the ID should begin with com.example. I strongly recommend using your own domain name rather than an io.itch. or io.github. prefix here, but ultimately it is up to you. Note that as of writing, Itch.io-based IDs cannot be verified on Flathub. 1. Handling Your PCK File When you export a Godot Engine game for PC, you’re actually creating a platform-agnostic PCK file that contains all of your game’s code and assets, plus any plugins and libraries. The export also provides a copy of the platform-specific binary for your game which—despite its name—is actually just the Godot Engine runtime. The runtime simply looks for a PCK file of the same name sitting on disk next to it, and runs it. If you’re familiar with emulating retro games, you can think of the binary file as the Godot “emulator”, and the PCK file as your game’s “ROM.” To publish to Flathub, we’ll first need your game’s exported PCK file accessible somewhere on the web via a public, versioned URL. We’ll include that URL in the Flatpak manifest later so Flatpak Builder knows where to get the PCK file to bundle it with the Godot Engine binary into a Flatpak. Technically any publicly-accessible URL works here, but if your game is open source, I highly recommend you attach the PCK file as a release artifact wherever your source code is hosted (e.g. GitHub). This is the most similar to how open source software is typically released and distributed, and will be the most familiar to Flathub reviewers as well as potential contributors to your game. No matter where you publish your PCK file, the URL needs to be public, versioned, and stable: Flatpak Builder should always get the exact same file when hitting that URL for that release, and if you make a new release of your game, that version’s PCK file needs to be accessible at a new URL. I highly recommend semantic versioning for this, but it at least needs to be incrementally versioned so it’s always obvious to Flathub reviewers which version is newest, and so it matches to the version in the MetaInfo (more on that later). Match your game’s regular versioning scheme if possible. Bonus Points: Export in CI Since Godot Engine is open source and has command-line tools that run on Linux, you can use a source code platform’s continuous integration (CI) feature to automatically export and upload your PCK file. This differs a bit depending on your source code hosting platform and Godot Engine version, but triggered by a release, you run a job to: Grab the correct version of the Godot Engine tools binary from their GitHub release Export the PCK file from the command line (Godot Docs) Upload that PCK file to the release itself This is advantageous because it ensures the PCK file attached to the release is exported from the exact code from in the release, increasing transparency and reducing the possibility of human error. Here is one example of such a CI workflow. About That Binary… Since the exported bina...
Transcribe →Michael Meeks: 2024-12-02 Monday
Dec 2, 2024Tap to summarizeMail chew, 1:1's with Miklos & Lily, lunch. Set off to Paris via the Eurostar.
Transcribe →Felipe Borges: Announcement: GNOME will have an Outreachy intern working on librsvg
Dec 2, 2024Tap to summarizeWe are excited to announce that the GNOME Foundation is sponsoring an Outreachy internship for the December-March round! The intern will work with mentor Federico Mena Quintero on the project, “Implement the SVG2 text layout algorithm in librsvg.” The intern’s blog will soon be added to Planet GNOME, where you can follow their project updates and learn more about them. Stay tuned!
Transcribe →Michael Meeks: 2024-12-01 Sunday
Dec 1, 2024Tap to summarizeAll Saints, family service + Baptism in the morning, caught up with wider church family; home for Pizza lunch with E. Put up Christmas decorations left & right. Slugged variously, watched Night Action some Fallout - gratuitous gore, but interesting effects & characters.
Transcribe →Udo Ijibike: Outreachy Internship Series: Files Usability Test Report
Nov 27, 2024Tap to summarizeDuring my Outreachy internship with GNOME, Tamnjong Larry Tabeh and I conducted user research exercises under the inspiring mentorship of Allan Day and Aryan Kaushik. In this blog post, I’ll discuss the usability test we conducted for GNOME’s Files, also known as Nautilus. This blog post will introduce the study, outline our methodology, and present our key findings from the usability test. I’ve also attached a downloadable report at the end of this blogpost that discusses (in detail) our observations and recommendation(s) for each task performed in the usability test. Without further ado, let’s jump right in! 1. Introduction Files is the default file manager of the GNOME desktop. It provides a simple and integrated way of managing files when running a Linux-based OS by supporting all the basic functions of a file manager and more. With recent GNOME releases introducing significant changes to the Files user experience, and more improvements planned for subsequent releases, the design team wanted to assess the effectiveness of these updates and learn more about other aspects of the user experience. To support these efforts, we executed a user research project to identify areas for improvement, and gather actionable insights from observed user behaviours that can inform design decisions when addressing identified issues. 1.1. Research Goals Our research goals were to: Assess the effectiveness of the new menu structure and the discoverability of the following menu items: Icon Size editors Properties Select All Undo/Redo Sort Open Item Location Show Hidden Files Add To Bookmark Evaluate the ease of use of Files’s Search feature, and the intuitiveness of its Search Filters. Investigate the extent to which any difficulty experienced when right-clicking an empty space in List View impacts the user experience when accessing a folder context-menu. 1.2. Research Questions Upon completion of the study, we wanted to be able to answer the following questions: Menu Structure Is the current organization of the menus effective? Can people find the buttons they need for basic tasks when they need them? Search Experience Do people understand how to search in Files? Do people understand the search filters and how to use them? Are the search filters effective for their context of use? List View Layout Is it challenging for people to access the folder context menu in list view when they have a lot of files? Does the current design meet user expectations when accessing folder context menu in list view? 2. Study Design 2.1. Approach To answer our research questions, we opted for a moderated task-based usability test. This approach meant that we could simulate typical usage conditions and observe participants interact with Files. This made it easy for us to identify pain-points and gaps in the specific aspects of the Files user experience that we were interested in, and allowed us to engage participants in discussions that deepened our understanding of the challenges they experienced with Files. To plan the study, we started by defining the ideal participant for our research goals. Next, we established an optimal sequence for the tasks we wanted participants to perform, then crafted a scenario for each, after which we designed the testing environment. Then concluded preparations with a pilot test to identify weaknesses in the study plan and implement revisions where necessary before testing with recruited participants. 2.2. Recruitment Criteria To generate the data we needed, we had to observe individuals who were unfamiliar with the Files menu structure. This requirement was crucial, as previous use of Files could influence a participant’s interactions, which would have made it difficult for us to discern valid usability issues from their interactions. We also needed participants to be able to perform basic computing tasks independently: tasks like navigating software and managing files on their computer. This proficiency was important to ensuring that any challenges observed during the study were specifically related to the Files user experience, rather than stemming from a lack of general computer skills. Therefore, we defined our recruitment criteria as follows: Has never used GNOME prior to their usability test session. Is able to use a computer moderately well. 2.3. Testing Environment During testing, participants interacted with development versions of Files, specifically, versions 47.rc-7925df1ba and 47.rc-3faeec25e. Both versions were the latest available at the time of testing and had identical implementations of the features we were targeting. To elicit natural interactions from the participants, we enhanced the testing environment with a selection of files and folders that were strategically organized, named, and hidden, to create states in Files that encouraged and facilitated the tasks we planned to observe. 3. Participant Overview We recruited and tested with six first-time GNOME users, aged twenty-one to forty-seven, from diverse backgrounds, with varying levels of computer expertise. This diversity in the sample helped us keep our findings inclusive by ensuring that we considered a broad range of experiences in the usability test. Although the majority of the participants reported current use of Windows 11 as shown below, a few also reported previous use of macOS and earlier versions of Windows OS. 4. Methodology For this usability test: We conducted in-person usability tests with six computer users who met our selection criteria. The moderating researcher followed a test script and concluded each session with a brief, semi-structured interview. Participants attempted eleven tasks in the following order: Change the icon size Find the size of a folder with Properties Select all files in a folder with “Select All” Undo an action with the “Undo” button Change the sort order Change Files display from grid view to list view Create a new folder while in list view Find a file using the search feature, with filters Go to a file’s location from search results with “Open Item Location” Reveal hidden items in a folder with “Show Hidden Files” Add a folder to the sidebar with “Add to Bookmarks” Participants were encouraged to continuously think aloud while the performing tasks and each session lasted at least 40 minutes. All sessions were recorded with participant consent and were later transcribed for analysis. To analyze the collected data, we summarized the participants’ experiences for each task using Jim Hall’s Heat Map technique and synthesized findings from our session notes through Thematic Analysis. 5. Usability Test Result Applying Jim Hall’s Heat Map technique we summarized the observed experience for all tasks performed in the usability test. The heatmap below shows the completion rate for each task and the level of difficulty experienced by participants when performing them. The tasks are in rows and participants are represented in columns. The cell where a row (Task) i...
Transcribe →Felipe Borges: GNOME Settings 47 Retrospective
Nov 27, 2024Tap to summarizeWhile cutting the 47.2 release earlier today, I couldn’t help but reflect on everything we’ve accomplished this cycle. But instead of just listing code changes, I want to use this opportunity to give credit where it’s due, because to me, software is about people! Much of what we have achieved this cycle is thanks to the dedication of passionate volunteer contributors such as Matthijs Velsink, Automeris Naranja, Hari Rana, Alice Mikhaylenko, Andy Holmes, Adrian Vovk, Corey Berla, Joan Torres, Joshua, Adrien Plazas, Jamie Murphy, and many others. I’m also deeply grateful to the translation teams for making GNOME accessible in so many different languages. The GNOME Design team has been invaluable throughout this cycle. A big thank you to Allan Day, Jakub Steiner, Sam Hewitt, and Jamie Gravendeel, for their essential contributions. Special thanks to Matthijs Velsink for taking on the challenging role of co-maintaining Settings with me. I couldn’t manage it without Matthijs’ outstanding contributions to fixes, features, and reviews. We’re lucky to have him as part of the project. Release 47 holds extra significance for me. Wearing my downstream hat, I can share (it’s no secret) that the upcoming RHEL 10 Workstation will primarily feature GNOME 47 components. Building a solid upstream foundation for this version has been one of my top priorities, and I’m happy with the results. Thanks to the evolution of libadwaita, we’ve been able to port many of our custom widgets to modern libadwaita ones. This transition enhances consistency across the desktop, improves accessibility, and ensures better responsiveness on screens of various sizes. A big shoutout to the incredible folks working on libadwaita for making this possible! With Libadwaita we added Accent Color settings, allowing customizing our default blue accent color throughout the GNOME app ecosystem. Personally, I’ve been rocking the purple accent color on my desktop. We also revisited the interface for adding local and enterprise user accounts, improving it with libadwaita widgets, a new password and username feedback widget, and addressing some technical debt along the way. Speaking of interface modernization, we’ve also revamped several UIs in the Printing settings. Over time, some of our UIs have evolved at different paces, often leaving us with interfaces in transitional states and UX inconsistencies. A common example was nested dialogs, where a button within a dialog could open yet another dialog. To address this, many top-level dialogs have been converted into subpages using libadwaita’s AdwNavigationView, resulting in a smoother browsing experience. We continually refine the settings texts and descriptions to align more closely with the GNOME Human Interface Guidelines. Many settings have also been reworded to improve clarity and discoverability too. There’s so much more that happened this cycle, including a lot of performance improvements, bug fixes, and various tweaks. You can find more changes listed on the ‘Version History’ dialog in GNOME Software. We’re always looking for contributors, and there are many ways you can help improve GNOME Settings. Visit apps.gnome.org/Settings to learn how to get started.
Transcribe →Juan Pablo Ugarte: Cambalache 0.94 Released!
Nov 27, 2024Tap to summarizeHello, I am pleased to announce a new Cambalache stable release. Version 0.94.0 – Accessibility Release! Gtk 4 and Gtk 3 accessibility support Support property subclass override defaults AdwDialog placeholder support Improved object description in hierarchy Lots of bug fixes and minor UI improvements How it started? A couple of months ago I decided to make a poll on Mastodon about which feature people would like to see next. To my surprise GtkExpression did not come up first and GResources where not the last one. Data Model First things firsts, how to store a11y data in the project” So what are we trying to sotre? from Gtk documentation: GtkWidget allows defining accessibility information, such as properties, relations, and states, using the custom <accessibility> element: <object class="GtkButton" id="button1"> <accessibility> <property name="label">Download</property> <relation name="labelled-by">label1</relation> </accessibility> </object> These looks a lot like regular properties so my first idea was to store them as properties in the data model. So I decided to create one custom/fake interface class for each type of a11y data CmbAccessibleProperty, CmbAccessibleRelation and CmbAccessibleState. These are hardcoded in cmb-catalog-gen tool and look like this # Property name: (type, default value, since version) self.__a11y_add_ifaces_from_enum([ ( "Property", "GtkAccessibleProperty", { "autocomplete": ["GtkAccessibleAutocomplete", "none", None], "description": ["gchararray", None, None], ... } ), ( "Relation", "GtkAccessibleRelation", { "active-descendant": ["GtkAccessible", None, None], "controls": ["CmbAccessibleList", None, None], # Reference List "described-by": ["CmbAccessibleList", None, None], # Reference List ... } ), ( "State", "GtkAccessibleState", { "busy": ["gboolean", "False", None], "checked": ["CmbAccessibleTristateUndefined", "undefined", None], "disabled": ["gboolean", "False", None], "expanded": ["CmbBooleanUndefined", "undefined", None], ... } ) ]) This function will create the custom interface with all the properties and make sure all values in the GtkEnumeration are covered. One fundamental difference with properties is that some a11y relations can be used more than once to specify multiple values. To cover this I created a new value type called CmbAccessibleList which is simply a coma separated list of values. This way the import and export code can handle loading and exporting a11y data into Cambalache data model. Editing a11y data in the UI Now since these interfaces are not real, no actual widget implements them, they wont show up automatically in the UI. This can be easily solved by adding a new tab “a11y” to the object editor which only shows a11y interface properties.Now at this point it is possible to create and edit accessibility metadata for any UI but as Emmanuelle pointed out not every a11y property and relation is valid for every role. To know what is valid or not you need to read WAI-ARIA specs or write a script that pulls all the metadata from it. With this metadata handy is it easy to filter properties and relations depending on the a11y role.BTW keep in mind that accessible-role property should not be changed under normal circumstances. Where to get it? From Flathub flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo flatpak install flathub ar.xjuan.Cambalache or directly from gitlab git clone https://gitlab.gnome.org/jpu/cambalache.git Matrix channel Have any question? come chat with us at #cambalache:gnome.org Mastodon Follow me in Mastodon @xjuan to get news related to Cambalache development. Happy coding!
Transcribe →Daniel García Moreno: Hackweek 24
Nov 22, 2024Tap to summarizeIt's the time for a new Hack Week. The Hack Week 24 was from November 18th to November 22th, and I've decided to join the New openSUSE-welcome project this time. The idea of this project is to revisit the existing openSUSE welcome app, and I've been trying to help here, specifically for the GNOME desktop installation. openSUSE-welcome Right now after installing any openSUSE distribution with a graphical desktop, the user is welcomed on first login with a custom welcome app. This custom application is a Qt/QML with some basic information and useful links. The same generic application is used for all desktops, and for popular desktops right now exists upstream applications for this purpose, so we were talking on Monday morning about it and decided to use specific apps for desktops. So for GNOME, we can use the GNOME Tour application. gnome-tour GNOME Tour is a simple rust/gtk4 application with some fancy images in a slideshow. This application is generic and just shows information about GNOME desktop, so I created a fork for openSUSE to do some openSUSE specific customization and use this application as openSUSE welcome in GNOME desktop for Tumbleweed and Leap. Desktop patterns, the welcome workflow After some testing and investigation about the current workflow for the welcome app: x11_enhanced pattern recommends opensuse-welcome app. We can add a Recommends: gnome-tour to the gnome pattern The application run using xdg autostart, so gnome-tour package should put the file in /etc/xdg/autostart and set to hidden on close. In the case of having a system with multiple desktops, we can choose the specific welcome app using the OnlyShowIn/NotShowIn config in desktop file So I've created a draft PR to do not show the openSUSE-welcome app in GNOME, and I've also the gnome-tour fork in my home OBS project. I've been testing this configuration in Tumbleweed with GNOME, KDE and XFCE installed and it works as expected. The openSUSE-welcome is shown in KDE and XFCE and the gnome-tour app is only shown in GNOME. Next steps The next steps to have the GNOME Tour app as default welcome for openSUSE GNOME installation are: Send forked gnome-tour package to GNOME:Next project in OBS. Add the Recommends: gnome-tour to patterns-gnome to GNOME:Next project in OBS. Make sure that any other welcome application is not shown in GNOME. Review openQA tests that expect opensuse-welcome and adapt for the new application.
Transcribe →Sam Thursfield: Status update, 21/11/2024
Nov 21, 2024Tap to summarizeA month of low energy here. My work day is spent on a corporate project which I can’t talk about due to NDAs, although I can say it’s largely grunt work at the moment. I’m not much of a gamer but sometimes you need a dose of solid fun. I finally started playing through Age of Empires II: The Conquerers, which has aged 24 years at this point, like a fine whisky. I played the original AoE when it came out, and I loved the graphics and the scenarios but got burned out by how dumb the units would be. All that was greatly improved in the second edition; although your guys will still sometimes wander off to chip away single-handedly at an enemy castle with their tiny sword, the new keyboard shortcuts make it less frustrating to micro-manage an army. I guess this is old news for everyone except me but, what a game. I’m preparing some QA related talk submissions for FOSDEM 2025. I haven’t had time or energy to work on QA testing in GNOME, but I still have a clear idea of how we can move forwards, and I’ll keep talking about it a little longer to see if we can really go somewhere. There is still a small community joining our monthly call which gives a certain momentum to the project. In terms of search, unfortunately I don’t feel much momentum around this at the moment. Besides the heroic contributions from Carlos, we did get a new IDE from Demigod’s and Rachel’s summer of code project. Somehow that hasn’t even made its way into Fedora 41, despite being part of the latest GNOME 47 release, so it’s still tricky to use it in demos. I looked at submitting some desktop search related talk to FOSDEM but there’s not a single dev room I can see where a proposal would even fit. There we are. One final thought. This was a pretty engaging 20 minute talk by Cabel Sasser on the topic of a bizarre mural he saw at a McDonalds burger restaurant in Washington, USA. I recommend watching it if you haven’t, but you can also jump straight to the website about the mural’s artist, Wes Cook. Something jumped out at me in the middle of the talk when he said “We all want to be seen.” Most folk want some recognition of the work we do and some understanding. In the software industry it’s very difficult because what we do is so specialised. But we’re now at a point where graphical desktops have been mainstream for nearly 30 years. Everyone uses one in their job. Smartphones are 15 years old and the tech isn’t hugely evolving. A lot of this stuff is based on open source projects with 15+ year histories, and the people who can tell the stories of how they were made and how they work are all still around and still active. It could be worth spending some effort recognising what we have, and talking about it, and the people who make it happen. (If only we could have a desktop room at FOSDEM again…)
Transcribe →
Page 1 of 2