GNOME

Mail chew; interested to see Open Usage announced for holding and managing FLOSS trademarks in a light-weight way. If it can reduce the galloping bureaucracy and the risk of in-fighting that can come with formal governance structures, as ... [More] well as avoiding the extraordinarily overheads of formal entities, that sounds rather positive. Just having the pleasant, collegial engineering relationships in a project without the overhead would be great. Then again, I guess SFC, SPI, Public Software and others already provide nice containers for projects with varying degress of flexibility, lets see what happens. [Less]

Recently I kind of took over the maintainership of libhandy-rs, the Rust bindings of libhandy. I have since then been preparing for a new release so that Rust & GTK app developers can update to the latest gtk-rs release as soon as possible. I ... [More] also heavily depend on it on my various little apps.The latest release which targets libhandy-0.0 v0.0.13 features various improvements: Proper documentation support, note that the docs are built from the main branch Builders support Generate more missing bindings Starting from this release, libhandy-rs have a libhandy::init() which should be called right after gtk::init() The next release of libhandy-rs will be targeting libhandy-1 and will hopefully adds the latest missing bits for a complete Rust bindings of libhandy.A big thanks to the GTK-rs community, I learned so much stuff by contributing :) [Less]

A morning of marketing bits; catch up with Paolo, admin and community mail reading.

Marc-André Lureau has landed GUri support in GLib, and it’ll be available in GLib 2.65.1 (due out in the next few days). GUri is a new API for parsing and building URIs, roughly equivalent to SoupURI already provided by libsoup — but since URIs ... [More] are so pervasive, and used even if you’re not actually doing HTTP conversations, it makes sense to have a structured representation for them in GLib. To parse a URI, use g_uri_parse() or g_uri_split(): g_autoptr(GError) local_error = NULL; const gchar *uri_str; g_autoptr(GUri) uri = NULL; g_autoptr(GHashTable) query_params = NULL; uri_str = "https://discourse.gnome.org/search?q=search%20terms#ember372"; uri = g_uri_parse (uri_str, G_URI_FLAGS_PARSE_STRICT | G_URI_FLAGS_ENCODED_QUERY, &local_error); if (uri == NULL) { /* Handle the error */ g_error ("Invalid URI: %s", uri_str); return; } g_assert_cmpstr (g_uri_get_scheme (uri), ==, "https"); g_assert_cmpstr (g_uri_get_host (uri), ==, "discourse.gnome.org"); g_assert_cmpstr (g_uri_get_path (uri), ==, "/search"); g_assert_cmpstr (g_uri_get_query (uri), ==, "q=search%20terms"); g_assert_cmpstr (g_uri_get_fragment (uri), ==, "ember372"); /* Parse the params further. Using g_uri_parse_params() requires that we pass G_URI_FLAGS_ENCODED_QUERY to g_uri_parse() above, otherwise the %-encoded values could be decoded to create more separators */ query_params = g_uri_parse_params (g_uri_get_query (uri), -1, "&", G_URI_PARAMS_NONE, &local_error); if (query_params == NULL) { /* Handle the error */ g_error ("Invalid query: %s", g_uri_get_query (uri)); return; } g_assert_cmpstr (g_hash_table_lookup (query_params, "q"), ==, "search terms"); Building a URI is a matter of calling g_uri_build() or g_uri_join(), which should be self-explanatory. Please try it out! The API is unstable until GLib makes its 2.66.0 stable release (freezing on 2020-08-08), so now is the time to comment on things which don’t make sense or are hard to use. [Less]

At the end of the last year I wrote a long blog post summarizing the main work I was involved with as part of Igalia’s Chromium team. In it I mentioned that a big chunk of my time was spent working on the migration to the new C++ Mojo types across ... [More] the entire codebase of Chromium, in the context of the Onion Soup 2.0 project. For those of you who don’t know what Mojo is about, there is extensive information about it in Chromium’s documentation, but for the sake of this post, let’s simplify things and say that Mojo is a modern replacement to Chromium’s legacy IPC APIs which enables a better, simpler and more direct way of communication among all of Chromium’s different processes. One interesting thing about this conversion is that, even though Mojo was already “the new thing” compared to Chromium’s legacy IPC APIs, the original Mojo API presented a few problems that could only be fixed with a newer API. This is the main reason that motivated this migration, since the new Mojo API fixed those issues by providing less confusing and less error-prone types, as well as additional checks that would force your code to be safer than before, and all this done in a binary compatible way. Please check out the Mojo Bindings Conversion Cheatsheet for more details on what exactly those conversions would be about. Another interesting aspect of this conversion is that, unfortunately, it wouldn’t be as easy as running a “search & replace” operation since in most cases deeper changes would need to be done to make sure that the migration wouldn’t break neither existing tests nor production code. This is the reason why we often had to write bigger refactorings than what one would have anticipated for some of those migrations, or why sometimes some patches took a bit longer to get landed as they would span way too much across multiple directories, making the merging process extra challenging. Now combine all this with the fact that we were confronted with about 5000 instances of the old types in the Chromium codebase when we started, spanning across nearly every single subdirectory of the project, and you’ll probably understand why this was a massive feat that would took quite some time to tackle. Turns out, though, that after just 6 months since we started working on this and more than 1100 patches landed upstream, our team managed to have nearly all the existing uses of the old APIs migrated to the new ones, reaching to a point where, by the end of December 2019, we had completed 99.21% of the entire migration! That is, we basically had almost everything migrated back then and the only part we were missing was the migration of //components/arc, as I already announced in this blog back in December and in the chromium-mojo mailing list. Progress of migrations to the new Mojo syntax by December 2019 This was good news indeed. But the fact that we didn’t manage to reach 100% was still a bit of a pain point because, as Kentaro Hara mentioned in the chromium-mojo mailing list yesterday, “finishing 100% is very important because refactoring projects that started but didn’t finish leave a lot of tech debt in the code base”. And surely we didn’t want to leave the project unfinished, so we kept collaborating with the Chromium community in order to finish the job. The main problem with //components/arc was that, as explained in the bug where we tracked that particular subtask, we couldn’t migrate it yet because the external libchrome repository was still relying on the old types! Thus, even though almost nothing else in Chromium was using them at that point, migrating those .mojom files under //components/arc to the new types would basically break libchrome, which wouldn’t have a recent enough version of Mojo to understand them (and no, according to the people collaborating with us on this effort at that particular moment, getting Mojo updated to a new version in libchrome was not really a possibility). So, in order to fix this situation, we collaborated closely with the people maintaining the libchrome repository (external to Chromium’s repository and still relies in the old mojo types) to get the remaining migration, inside //components/arc, unblocked. And after a few months doing some small changes here and there to provide the libchrome folks with the tools they’d need to allow them to proceed with the migration, they could finally integrate the necessary changes that would ultimately allow us to complete the task. Once this important piece of the puzzle was in place, all that was left was for my colleague Abhijeet to land the CL that would migrate most of //components/arc to the new types (a CL which had been put on hold for about 6 months!), and then to land a few CLs more on top to make sure we did get rid of any trace of old types that might still be in codebase (special kudos to my colleague Gyuyoung, who wrote most of those final CLs). Progress of migrations to the new Mojo syntax by July 2020 After all this effort, which would sit on top of all the amazing work that my team had already done in the second half of 2019, we finally reached the point where we are today, when we can proudly and loudly announce that the migration of the old C++ Mojo types to the new ones is finally complete! Please feel free to check out the details on the spreadsheet tracking this effort. So please join me in celebrating this important milestone for the Chromium project and enjoy the new codebase free of the old Mojo types. It’s been difficult but it definitely pays off to see it completed, something which wouldn’t have been possible without all the people who contributed along the way with comments, patches, reviews and any other type of feedback. Thank you all! Last, while the main topic of this post is to celebrate the unblocking of these last migrations we had left since December 2019, I’d like to finish acknowledging the work of all my colleagues from Igalia who worked along with me on this task since we started, one year ago. That is, Abhijeet, Antonio, Gyuyoung, Henrique, Julie and Shin. Now if you’ll excuse me, we need to get back to working on the Onion Soup 2.0 project because we’re not done yet: at the moment we’re mostly focused on converting remote calls using Chromium’s legacy IPC to Mojo (see the status report by Dave Tapuska) and helping finish Onion Soup’ing the remaining directores under //content/renderer (see the status report by Kentaro Hara), so there’s no time to waste. But those migrations will be material for another post, of course. [Less]

It’s been a long time since I last blogged. In the interim I started a new job at Igalia as a JavaScript Engine Developer on the compilers team, and attended FOSDEM in Brussels several million years ago in early February back when “getting on a ... [More] plane and traveling to a different country” was still a reasonable thing to do. In this blog post I would like to present Temporal, a proposal to add modern and comprehensive handling of dates and times to the JavaScript language. This has been the project I’m working on at Igalia, as sponsored by Bloomberg. I’ve been working on it for the last 6 months, joining several of my coworkers in a cross-company group of talented people who have already been working on it for several years. This is the kind of timekeeping you get with the old JavaScript Date… (Public domain photograph by Julo) I already collaborated on a blog post about Temporal, “Dates and Times in JavaScript”, so I won’t repeat all that here, but all the explanation you really need is that Temporal is a modern replacement for the Date object in JavaScript, which is terrible. You may also want to read “Fixing JavaScript Date”, a two-part series providing further background, by Maggie Pint, one of the originators of Temporal. How Temporal can be useful in GNOME I’m aware that this blog is mostly read by the GNOME community. That’s why in this blog post I want to talk especially about how a large piece of desktop software like GNOME is affected by JavaScript Date being so terrible. Of course most improvements to the JavaScript language are driven by the needs of the web.1 But a few months ago this merge request caught my eye, fixing a bug that made the date displayed in GNOME wrong by a full 1,900 years! The difference between Date.getYear() not doing what you expect (and Date.getFullYear() doing it instead) is one of the really awful parts of JavaScript Date. In this case if there had been a better API without evil traps, the mistake might not have been made in the first place, and it wouldn’t have come down to a last-minute code freeze break. In the group working on the Temporal proposal we are seeking feedback from people who are willing to try out the Temporal API, so that we can find out if there are any parts that don’t meet people’s needs and change them before we try to move the proposal to Stage 3 of the TC39 process. Since I think GNOME Shell and GNOME Weather, and possibly other apps, might benefit from using this API when it becomes part of JavaScript in the future, I’d be interested in finding out what we in the GNOME community need from the Temporal API. It seems to me the best way to do this would be to make a port of GNOME Shell and/or GNOME Weather to the experimental Temporal API, and see what issues come up. Unfortunately, it would defeat the purpose for me to do this myself, since I am already overly familiar with Temporal and by now its shortcomings are squarely in my blind spot! So instead I’ll offer my help and guidance to anyone who wants to try this out. Please get in touch with me if you are interested. How to try it out Since Temporal is of course not yet a built-in object in JavaScript, to try it out we will need to import a polyfill. We have published a polyfill which is experimental only, for the purpose of trying out the API and integrating it with existing code. Here’s a link to the API documentation. The polyfill is primarily published as an NPM library, but we can get it to work with GJS quite easily. Here’s how I did it. First I cloned the tc39/proposal-temporal repo, and ran npm install and npm run build in it. This generates a file called polyfill/script.js which you can copy into your code, into a place in your imports path so that the importer can find it. Then you can import Temporal: const {Temporal} = imports.temporal.temporal; Note that the API is not stable, so only use this to try out the API and give feedback! Don’t actually include it in your code. We have every intention of changing the API, maybe even drastically, based on feedback that we receive. Once you have tried it out, the easiest way to tell us about your findings is to complete the survey, but do also open an issue in the bug tracker if you have something specific. Intl, or how to stop doing _("%B %-d %Y") While I was browsing through GNOME Shell bug reports to find ones related to JavaScript Date, I found several such as gnome-shell#2293 where the translated format strings lag behind the release while translators figure out how to translate cryptic strings such as "%B %-d %Y" for their locales. By doing our own translations, we are actually creating the conditions to receive these kinds of bug reports in the first place. Translations for these kinds of formats that respect the formatting rules for each locale are already built into JavaScript engines nowadays, in the Intl API via libicu, and we could take advantage of these translations to take some pressure off of our translators. In fact, we could do this right now already, no need to wait for the Temporal proposal to be adopted into JavaScript and subsequently make it into GJS. We already have everything we need in GNOME 3.36. With Intl, the function I linked above would become: _updateTitle() { const locale = getCachedLocale(); const timeSpanDay = GLib.TIME_SPAN_DAY / 1000; const now = new Date(); const rtf = new Intl.RelativeTimeFormat(locale, {numeric: 'auto'}); if (this._startDate <= now && now <= this._endDate) this._title.text = rtf.format(0, 'day'); else if (this._endDate < now && now - this._endDate < timeSpanDay) this._title.text = rtf.format(-1, 'day'); else if (this._startDate > now && this._startDate - now < timeSpanDay) this._title.text = rtf.format(1, 'day'); else if (this._startDate.getFullYear() === now.getFullYear()) this._title.text = this._startDate.toLocaleString(locale, {month: 'long', day: 'numeric'}); else this._title.text = this._startDate.toLocaleString(locale, {year: 'numeric', month: 'long', day: 'numeric'}); } (Note, this presumes a function getCachedLocale() which determines the correct locale for Intl by looking at the LC_TIME, LC_ALL, etc. evnvironment variables. If GNOME apps wanted to move to Intl generally, I think it might be worth adding such a function to GJS’s Gettext module.) Whereas in the future with Temporal, it would be even simpler and clearer, and I couldn’t resist rewriting that method! We wouldn’t need to store a start Date at 00:00 and end Date at 23:59.999 which is really just a workaround for the fact that we are talking here about a date without a time component, that is purely a calendar day. Temporal covers this use case out of the box: _updateTitle() { const locale = getCachedLocale(); const today = Temporal.now.date(); const {days} = today.difference(this._date); if (days <= 1) { const rtf = new Intl.RelativeTimeFormat(locale, {numeric: 'auto'}); // Note: if this negation seems a bit unwieldy, be aware that we are // considering revising the API to allow negative-valued durations days = Temporal.Date.compare(today, this._date) < 0 ? days : -days; this._title.text = rtf.format(days, 'day'); } else { const options = {month: 'long', day: 'numeric'}; if (today.year !== this._date.year) options.year = 'numeric'; this._title.text = this._date.toLocaleString(locale, options); } } Calendar systems One exciting thing about Temporal is that it will support non-Gregorian calendars. If you are a GNOME user or developer who uses a non-Gregorian calendar, or develops code for users who do, then please get in touch with me! In the group of people developing Temporal everyone uses the Gregorian calendar, so we have a knowledge gap about what users of other calendars need. We’d like to try to close this gap by talking to people. A Final Note In the past months I’ve not been much in the mood to write blog posts. My mind has been occupied worrying about the health of my family, friends, and myself; feeling fury and shame at the inequalities of our society that, frankly, the pandemic has made harder to fool ourselves into forgetting if it doesn’t affect us directly; and fury at our governments that perpetuate these problems and resist meaningful attempts at reform. With all that’s going on in the world, blogging about technical achievements feels a bit ridiculous and inconsequential, but, well, I’m writing this, and you’re reading this, and here we are. So keep in mind there are other important things too. Be safe, be kind, but don’t forget to stay furious after the dust settles. [1] One motivation for why some are eagerly awaiting Temporal as part of the JavaScript language, as opposed to a library, is that it would be built-in to the browser. The most popular library for fixing the deficiencies of Date, moment.js, can mean an extra download of 20–100 kb, depending on whether you include all locales and support for time zones. This adds up to quite a lot of wasted data if you are downloading this on a large number of the websites you visit, but this specifically doesn’t affect GNOME. [Less]

A fun design exercise is to take an established system or process and introduce some major change into it, such as adding a completely new constraint. Then take this new state of things, run with it and see what happens. In this case let's see how ... [More] one might design a revision control system where merging is prohibited. Or, formulated in a slightly different way:What if merging is to revision control systems as multiple inheritance is to software design?What is merging used for?First we need to understand what merging is used for so that wa can develop some sort of a system that achieves the same results via some other mechanism. There are many reasons to use merges, but the most popular ones include the following.An isolated workspace for big changesMost changes are simple and consists of only one commit. Sometimes, however, it is necessary to make big changes with intermediate steps, such as doing major refactoring operations. These are almost always done in a branch and then brought in to trunk. This is especially convenient if multiple people work on the change.Trunk commits are always cleanBringing big changes in via merges means that trunk is always clean and buildable. More importantly bisection works reliably since all commits in trunk are known good. This is typically enforced via a gating CI. This allows big changes to have intermediate steps that are useful but broken in some way so they would not pass CI. This is not common, but happens often enough to be useful.An alternative to merging is squashing the branch into a single commit. This is suboptimal as it destroys information breaking for example git blame -kind of functionality as all changes made point to a single commt made by a single person (or possibly a bot).Fix trackingThere are several systems that do automatic tracking of bug fixes to releases. The way this is done is that a fix is written in its own branch. The bug tracking system can then easily see when the fix gets to the various release branches by seeing when the bugfix branch has been merged to them.A more linear designIn practice many (possibly even most) projects already behave like this. They keep their histories linear by rebasing, squashing and cherry picking, never merging. This works but has the downsides mentioned above. If one spends some time thinking about this problem the fundamental disconnect comes fairly clear. A "linear" revision control system has only one type of a change which is the commit whereas "real world" problems have two different types: logical changes and individual commits that make up the logical change. This structure is implicit in the graph of merge-based systems, but what if we made it explicit? Thus if we have a commit graph that looks like this:the linear version could look like this:The two commits from the right branch have become one logical commit in the flat version. If the revision control system has a native understanding of these kinds of physical and logical commits all the problematic cases listed could be made to work transparently. For example bisection would work by treating all logical commits as only one change. Only after it has proven that the error occurred inside a single logical commit would bisection look inside it.This, by itself, does not fix bug tracing. As there are no merges you can't know which branches have which fixes. This can be solved by giving each change (both physical and logical) a logical ID which remains the same over rebase and edit operations as opposed to the checksum-based commit ID which changes every time the commit is edited. This changes the tracking question from "which release branches have merged this feature fix branch" to "which release branches have a commit with this given logical ID" which is a fairly simple problem to solve.This approach is not new. LibreOffice has tooling on top of Git that does roughly the same thing as discussed here. It is implemented as freeform text in commit messages with all the advantages and disadvantages that brings.One obvious question that comes up is could you have logical commits inside logical commits. This seems like an obvious can of worms. On one hand it would be mathematically symmetrical and all that but on the other hand it has the potential to devolve into full Inception, which you usually want to avoid. You'd probably want to start by prohibiting that and potentially permitting it later once you have more usage experience and user feedback.Could this actually work?Maybe. But the real question is probably "could a system like this replace Git" because that is what people are using. This is trickier. A key question would whether you can automatically convert existing Git repos to the new format with no or minimal loss of history. Simple merges could maybe be converted in this way but in practice things are a lot more difficult due to things like octopus merges. If the conversion can not be done, then the expected market share is roughly 0%. [Less]

We are very proud to be announcing today the 0.4 release of Getting Things GNOME (“GTG”), codenamed “You Are (Not) Done”. This much-awaited release is a major overhaul that brings together many updates and enhancements, including new features, a ... [More] modernized user interface and updated underlying technology. Screenshot of GTG 0.4 Beyond what is featured in these summarized release notes below, GTG itself has undergone over 630 changes affecting over 500 files, and received hundreds of bug fixes, as can be seen on here and here. We are thankful to all of our supporters and contributors, past and present, who made GTG 0.4 possible. Check out the “About” dialog for a list of contributors for this release. A summary of GTG’s development history and a high-level explanation of its renaissance can be seen in this teaser video: A demonstration video provides a tour of GTG’s current features: A few words about the significance of this release As a result of the new lean & agile project direction and contributor workflow we have formalized, this release—the first in over 6.5 years—constitutes a significant milestone in the revival of this community-driven project. This milestone represents a very significant opportunity to breathe new life into the project, which is why I made sure to completely overhaul the “contributor experience”, clarifying and simplifying the process for new contributors to make an impact. I would highly encourage everybody to participate towards the next release. You can contribute all sorts of improvements to this project, be it bug fixes or new features, adopting one of the previous plugins, doing translation and localization work, working on documentation, or spreading the word. Your involvement is what makes this project a success. — Jeff (yours truly) “When I switched from Linux to macOS a few years ago, I never found a todo app that was as good as GTG, so I started to try every new shiny (and expensive) thing. I used Evernote, Todoist, Things and many others. Nothing came close. I spent the next 6 years trying every new productivity gadget in order to find the perfect combo.In 2019, Jeff decided to take over GTG and bring it back from the grave. It’s a strange feeling to see your own creation continuing in the hands of others. Living to see your software being developed by others is quite an accomplishment. Jeff’s dedication demonstrated that, with GTG, we created a tool which can become an essential part of chaos warrior’s productivity system. A tool which is useful without being trendy, even years after it was designed. A tool that people still want to use. A tool that they can adapt and modernise. This is something incredible that can only happen with Open Source.” — Lionel Dricot, original author of GTG (quote edited with permission) It has been over seven years since the 0.3rd impact. This might very well be the Fourth Impact. Shinji, get in the f%?%$ing build bot! — Gendo Ikari Release notes Technology Upgrades GTG and libLarch have been fully ported to Python 3, GTK 3, and GObject introspection (PyGI). User Interface and Frontend Improvements General UI overhaul The user interface has been updated to follow the current GNOME Human Interface Guidelines (HIG), style (see GH GTG PR #219 and GH GTG PR #235 for context) and design patterns: Client-side window decorations using the GTK HeaderBar widget. Along with the removal of the menu bars, this saves a significant amount of space and allows for more content to be displayed on screen. The Preferences dialog was redesigned, and its contents cleaned up to remove obsolete settings (see GH GTG PR #227). All windows are properly parented (set as transient) with the main window, so that they can be handled better by window managers. Symbolic icons are available throughout the UI. Improvements to padding and borders are visible throughout the application. Main window (“Task Browser”) The menu bar has been replaced by a menu button. Non-contextual actions (for example: toggle Sidebar, Plugins, Preferences, Help, and About) have been moved to the main menu button. Searching is now handled through a dedicated Search Bar that can be toggled on and off with the mouse, or the Ctrl+F keyboard shortcut. The “Workview” mode has been renamed to the “Actionable” view. “Open”, “Actionable”, and “Closed” tasks view modes are available (see GH GTG PR #235). An issue with sorting tasks by title in the Task Browser has been fixed: sorting is no longer case-sensitive, and now ignores tag marker characters (GH GTG issue #375). Start/Due/Closed task dates now display as properly translated in the Task Browser (GH GTG issue #357) In the Task Browser’s right-click context menus, more start/due dates choices are available, including common upcoming dates and a custom date picker (GH GTG issue #244). Task Editor The Calendar date picker pop-up widgets have been improved (see GH GTG PR #230). The Task Editor now attempts to place newly created windows in a more logical way (GH GTG issue #287). The title (first line of a task) has been changed to a neutral black header style, so that it doesn’t look like a hyperlink. New Features You can now open (or create) a task’s parent task (GH GTG issue #138). You can now select multiple closed tasks and perform bulk actions on them (GH GTG issue #344). It is now possible to rename or delete tags by right-clicking on them in the Task Browser. You can automatically generate and assign tag colors. (LP GTG issue #644993) The Quick Add entry now supports emojis The Task Editor now provides a searchable “tag picker” widget. The “Task Reaper” allows deleting old closed tasks for increased performance. Previously available as a plugin, it is now a built-in feature available in the Preferences dialog (GH GTG issue #222). The Quick Deferral (previously, the “Do it Tomorrow” plugin) is now a built-in feature. It is now possible to defer multiple tasks at once to common upcoming days or to a custom date (GH GTG issue #244). In the unlikely case where GTG might encounter a problem opening your data file, it will automatically attempt recovery from a previous backup snapshot and let you know about it (LP GTG issue #971651) Backend and Code Quality improvements Updates were made to overall code quality (GH GTG issue #237) to reduce barriers to contribution: The code has been ported to use GtkApplication, resulting in simpler and more robust UI code overall. GtkBuilder/Glade “.ui” files have been regrouped into one location. Reorganization of various .py files for consistency. The debugging/logging system has been simplified. Various improvements to the test suite. The codebase is mostly PEP8-compliant. We have also relaxed the PEP8 max line length convention to 100 characters for readability, because this is not the nineties anymore. Support is available for Tox, for testing automation within virtualenvs (see GH GTG PR #239). The application’s translatable strings have been reviewed and harmonized, to ensure the entire application is translatable (see GH GTG PR #346). Application CSS has been moved to its own file (see GH GTG PR #229). Outdated plugins and synchronization services have been removed (GH GTG issue #222). GTG now provides an “AppData” (FreeDesktop AppStream metadata) file to properly present itself in distro-agnostic software-centers. The Meson build system is now supported (see GH GTG PR #315). The development version’s launch script now allows running the application with various languages/locales, using the LANG environment variable for example. Appdata and desktop files are named based on the chosen Meson profile (see GH GTG PR #349). Depending on the Meson profile, the HeaderBar style changes dynamically to indicate when the app is run in a dev environment, such as GNOME Builder (GH GTG issue #341). Documentation Updates The user manual has been rewritten, reorganized, and updated with new images (GH GTG issue #243). It is also now available as an online publication. The contributor documentation has been rewritten to make it easier for developers to get involved and to clarify project contribution guidelines  (GH GTG issue #200). Namely, updates were made to the README.md file to clarify the set-up process for the development version, as well as numerous new guides and documentation for contributors in the docs/contributors/ folder. Infrastructure and other notable updates The entire GTG GNOME wiki site has been updated (GH GTG issue #200), broken links have been fixed, references to the old website have been removed. We have migrated from LaunchPad to GitHub (and eventually GitLab), so references to LaunchPad have been removed. We now have social media accounts on Mastodon and Twitter (GH GTG issue #294). Flatpak packages on Flathub are going to be our official direct upstream-to-user software distribution mechanism (GH GTG issue #233). Notice In order to bring this release out of the door, some plugins have been disabled and are awaiting adoption by new contributors to test and maintain them. Please contribute to maintain your favorite plugin. Likewise, we had to remove the DBus module (and would welcome help to bring it back into a better shape, for those who want to control the app via DBus). Getting and installing GTG 0.4 We hope to have our flatpak package ready in time for this announcement, or shortly afterwards. See the install page for details. Spreading this announcement We have made some social postings on Twitter, on Mastodon and on LinkedIn that you can re-share/retweet/boost. Please feel free to link to this announcement on forums and blogs as well! The post Rebuild of EvanGTGelion: Getting Things GNOME 0.4 released! appeared first on The Open Sourcerer. [Less]

With GUADEC two weeks away, this was the perfect time to talk to Program Manager and GUADEC organizer Kristi Progri. To see her amazing work live, register for GUADEC today! Photo courtesy of Kristi Progri. Licensed CC-BY-NC-ND-SA. Tell us a little ... [More] bit more about yourself. For people who have known me for a long time, I am Kiki. That’s my nickname, which comes from when I was playing basketball and I had four other team mates with the same name. I was born and grew up in the country with the largest number of bunkers in the world, left over from the communist era. I finished my bachelor studies in International Affairs and Diplomacy and my Master’s Degree is in ‘Information Systems Security’ A few years ago I co-founded the Open Source Diversity initiative and for around five years I was the chairwoman of a local hackerspace in my hometown that promotes all Free & Open Source technologies and data. For many years I was part of the organizing team for many years of the biggest open source conference in Albania. What is your role within the GNOME community? I am the Program Coordinator in the GNOME Foundation where I help to organize various events, leading many initiatives within the community including the Engagement Team, and working closely with all the volunteers and contributors. I also coordinate internships and help with general Foundation activities. Do you have any other affiliations you want to share? Before joining GNOME, I was very active in Mozilla community. I have been part of the Tech Speakers program and a Mozilla Representative for more than seven years now. I have organized many events and workshops and also have participated as a speaker talking about Free Software communities at many events around the globe. Why did you get involved in GNOME? I was introduced to Free Software when I was in high school, my friend had a computer running Debian and he started explaining how it worked. This was the first time I heard about it and I immediately understood that I would never be part of these communities. It looked so complicated and not my cup of tea, but it looks like I was very wrong. Once I went for to a hackerspace meeting I completely changed my mind and from that moment the hackerspace become my second home. Why are you still involved with GNOME? Diversity, people, community, sorting out dramas in and outside community, are some very important keywords that drive me to love working in such environment. I am working full time, so GNOME gets a big part of my attention everyday, which I am happy to share. What are you working on right now? My working desk is full of post-it notes of to do tasks My main thing now is organizing GUADEC online edition, working as well Google Season of Docs, University Outreach Initiative, other activities and tasks part of the Engagement team, and many others things which I am sure I have missed. What are you excited about right now – either in GNOME or free and open source software in general? We are building a new GNOME Community in Africa and spreading our community more in Asia, I am so excited to know what the future will bring us and how big GNOME will get. I feel like we are gaining momentum and I see very motivated people coming and contributing. What is a major challenge you see for the future of GNOME? As in many Free Software communities we have a big challenge with how to get newcomers on board and to keep them motivated to continue contributing. We need to have a very good structured way within the community to guide people for the tasks we need contributors and show them the way. Another major challenge I see is how GNOME will adapt with the new changes that are occurring in the world due to Covid-19 in terms of events, conferences, and hackfest organization . What do you think GNOME should focus on next? Financial sustainability and keeping the shiny growth rate we have right now should be one of the most important focuses. As previously mentioned these are difficult times we are currently living in, in the making the world a bit unsafe and therefore this might mean that finding the resources and donors will be challenging. What else should we have asked about that we didn’t? Please answer Whats you favorite physical activity? Weightlifting Answers edited for length. [Less]

This is the continuation from this post. Several moons have bypassed us [1] in the time since the first post, and Things Have Happened! If you recall (and of course you did because you just re-read the article I so conveniently linked above) ... [More] , libxkbcommon supports an include directive for the rules files and it will load a rules file from $XDG_CONFIG_HOME/xkb/rules/ which is the framework for custom per-user keyboard layouts. Alas, those files are just sitting there, useful but undiscoverable. To give you a very approximate analogy, the KcCGST format I described last time are the ingredients to a meal (pasta, mince, tomato). The rules file is the machine-readable instruction set to assemble your meal but it relies a lot on wildcards. Feed it "spaghetti, variant bolognese" and the actual keymap ends up being the various components put together: "pasta(spaghetti)+sauce(tomato)+mince". But for this to work you need to know that spag bol is available in the first place, i.e you need the menu. This applies to keyboard layouts too - the keyboard configuration panel needs to present a list so the users can clickedy click-click on whatever layout they think is best for them. This menu of possible layouts is provided by the xkeyboard-config project but for historical reasons [2], it is stored as an XML file named after the ruleset: usually /usr/share/X11/xkb/rules/evdev.xml [3]. Configuration utilities parse that file directly which is a bit of an issue when your actual keymap compiler starts supporting other include paths. Your fancy new layout won't show up because everything insists on loading the system layout menu only. This bit is part 2, i.e. this post here. If there's one thing that the world doesn't have enough of yet, it's low-level C libraries. So I hereby present to you: libxkbregistry. This library has now been merged into the libxkbcommon repository and provides a simple C interface to list all available models, layouts and options for a given ruleset. It sits in the same repository as libxkbcommon - long term this will allow us to better synchronise any changes to XKB handling or data formats as we can guarantee that the behaviour of both components is the same. Speaking of data formats, we haven't actually changed any of those which means they're about as easy to understand as your local COVID19 restrictions. In the previous post I outlined the example for the KcCGST and rules file, what you need now with libxkbregistry is an XKB-compatible XML file named after your ruleset. Something like this: $ cat $HOME/.config/xkb/rules/evdev.xml us banana banana US (Banana) custom Custom options custom:foo Map Tilde to nothing custom:baz Map Z to K This looks more complicated than it is: we have models (not shown here), layouts which can have multiple variants and options which are grouped together in option group (to make options mutually exclusive). libxkbregistry will merge this with the system layouts in what is supposed to be the most obvious merge algorithm. The simple summary of that is that you can add to existing system layouts but you can't modify those - the above example will add a "banana" variant to the US keyboard layout without modifying "us" itself or any of its other variants. The second part adds two new options based on my previous post. Now, all that is needed is to change every user of evdev.xml to use libxkbregistry. The gnome-desktop merge request is here for a start. [1] technically something that goes around something else doesn't bypass it but the earth is flat, the moon is made of cheese, facts don't matter anymore and stop being so pedantic about things already![2] it's amazing what you can handwave away with "for historical reasons". Life would be better if there was less history to choose reasons from.[3] there's also evdev.extras.xml for very niche layouts which is a separate file for historical reasons [2], despite there being a "popularity" XML attribute [Less]