Ole Aamot: GNOME Internet Radio Locator version 11.10 with GeoClue Location View support

https://blogs.gnome.org/oleaamot/2021/06/17/gnome-internet-radio-locator-11-with-geoclue-support/

The latest release of GNOME Internet Radio Locator 11.10 finally features GeoClue Location View in GNOME Gitlab Commit d0206f2f095b37e1ad1b3f7ead951ad2ea9f5828, since most people don’t live in Boston (wait a few seconds before your computer location is displayed on the map via GeoClue and click Zoom In/Zoom Out and drag on the map to see and listen to radio stations in the location map view. Click on the map marker labels to listen at your location or search with location text (for example “Cambridge, United Kingdom”) in the blank text input box to switch between the radio stations.

GNOME Internet Radio Locator 11 for GNOME 40 is a Free Software program that allows you to easily locate Free Internet Radio stations by broadcasters on the Internet with the help of map and text search.

GNOME Internet Radio Locator 11 for GNOME 40 is developed on the GNOME 40 desktop platform with GNOME Maps, GeoClue, libchamplain and geocode-lib and it requires at least GTK+ 3.0 and GStreamer 1.0 for audio playback.

GNOME Internet Radio Locator 11 for GNOME 40 is available with map marker popups for Internet radio stations in 110 world cities as well as text-based location search for 187 Internet Radio stations in 102 world cities.

You can either zoom/click on the map marker popups to listen to a station or enter city names in the GUI search input field in order to locate radio stations in the city using the text search with auto-completion.

Wait a few seconds to see your current location on the map in the GNOME Internet Radio Locator application.

You can download it from www.gnomeradio.org and the Fedora 34 RPM packages of version 11.10 of GNOME Internet Radio Locator are now also available for free:

gnome-internet-radio-locator-11.10.tar.xz

gnome-internet-radio-locator.spec

gnome-internet-radio-locator-11.10-1.fc34.src.rpm

gnome-internet-radio-locator-11.10-1.fc34.x86_64.rpm

To install gnome-internet-radio-locator-11.10.tar.xz on Fedora Core 34 in GNOME Terminal, run the following installation command to resolve all dependencies:

sudo dnf install http://www.gnomeradio.org/~ole/fedora/RPMS/x86_64/gnome-internet-radio-locator-11.10-1.fc34.x86_64.rpm

To run GNOME Internet Radio Locator 11 for GNOME 40 from GNOME Terminal, run the command

/usr/bin/gnome-internet-radio-locator

To inspect the source code and build the version 11.10 source tree, run

sudo dnf install gnome-common
sudo dnf install intltool libtool gtk-doc geoclue2-devel yelp-tools
sudo dnf install gstreamer1-plugins-bad-free-devel geocode-glib-devel
sudo dnf install libchamplain-devel libchamplain-gtk libchamplain geoclue2
git clone http://gitlab.gnome.org/GNOME/gnome-internet-radio-locator
cd gnome-internet-radio-locator/
./autogen.sh
sudo make install

Ole Aamot: GNOME Internet Radio Locator version 11.10 with GeoClue Location View support

https://blogs.gnome.org/oleaamot/2021/06/17/gnome-internet-radio-locator-version-11-10-with-geoclue-location-view-support/

GNOME Internet Radio Locator 11 for GNOME 40 is a Free Software program that allows you to easily locate Free Internet Radio stations by broadcasters on the Internet with the help of map and text search.

GNOME Internet Radio Locator 11 for GNOME 40 is developed on the GNOME 40 desktop platform with GNOME Maps, GeoClue, libchamplain and geocode-lib and it requires at least GTK+ 3.0 and GStreamer 1.0 for audio playback.

GNOME Internet Radio Locator 11 for GNOME 40 is available with map marker popups for Internet radio stations in 110 world cities as well as text-based location search for 187 Internet Radio stations in 102 world cities.

You can either zoom/click on the map marker popups to listen to a station or enter city names in the GUI search input field in order to locate radio stations in the city using the text search with auto-completion.

Wait a few seconds to see your current location on the map.

Enjoy Free Internet Radio.

You can download it from www.gnomeradio.org and the Fedora 34 RPM packages of version 11.10 of GNOME Internet Radio Locator are now also available for free:

gnome-internet-radio-locator.spec

gnome-internet-radio-locator-11.10-1.fc34.src.rpm

gnome-internet-radio-locator-11.10-1.fc34.x86_64.rpm

To install GNOME Internet Radio Locator 11.10 on Fedora Core 34 in GNOME Terminal, run the following installation command to resolve all dependencies:

sudo dnf install http://www.gnomeradio.org/~ole/fedora/RPMS/x86_64/gnome-internet-radio-locator-11.10-1.fc34.x86_64.rpm

To run GNOME Internet Radio Locator from GNOME Terminal, run the command

/usr/bin/gnome-internet-radio-locator

To inspect the source code and build the version 11.10 source tree, run

sudo dnf install gnome-common
sudo dnf install intltool libtool gtk-doc geoclue2-devel yelp-tools
sudo dnf install gstreamer1-plugins-bad-free-devel geocode-glib-devel
sudo dnf install libchamplain-devel libchamplain-gtk libchamplain geoclue2
git clone http://gitlab.gnome.org/GNOME/gnome-internet-radio-locator
cd gnome-internet-radio-locator/
./autogen.sh
make install

Ravgeet Dhillon: Script as a Task using VS Code IDE

https://www.ravsam.in/blog/script-as-a-task-using-vs-code-ide/

VS Code comes with a great feature of specifying tasks and running them through Command Palette. There can be a variety of scripts that we need to run while developing our applications. For example, before releasing a new build, there are a lot of things that need to be done by the release team. Some of them include bumping release version, creating release notes, generating changelog and the list goes on.

In this tutorial, we will learn how to use VS Code Tasks by taking the example of pre-release commands and ensure that no step is missed along the way.

Contents

Prerequisites

  • A Local Git Repository
  • VS Code Editor
  • Linux Environment

1. Writing Pre Release Script

The first thing we need to do is to create a script - in this case, a bash script. In this script, we will define what steps we need to perform as a part of our pre-release operation.

Let us assume that before releasing, we do two operations. First, we create a .version file and add today’s date to it. Then we create an empty commit with a message - do-production-release.

With the steps determined, let us create a pre-release.sh in .vscode directory and add the following code:

#!/bin/sh

date > .version
git commit --allow-empty -m "do-production-release"

We can test run the above script by doing:

bash .vscode/pre-release.sh

Make sure to give proper permissions to the script before running it.

2. Setting Tasks

Now comes the most interesting part of the tutorial. VS Code allows us to specify tasks in tasks.json. The beauty of the VS Code tasks is that we can run them directly from VS Code Command Palette which is especially helpful for non-technical members of our team.

Let us create a tasks.json file in .vscode directory and add the following contents in the file:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Pre-Release Setup",
            "type": "shell",
            "command": "bash",
            "args": ["${workspaceFolder}/.vscode/pre-release.sh"]
        }
    ]
}

It is important to understand what we are doing so that we can customize the workflow according to our needs.

label is used to identify the script in the VS Code Command Palette.

"label": "Pre-Release Setup"

type is set to shell since you need to execute a shell script.

"type": "shell"

command is used the specify the base command to which the arguments can be passed.

"command": "bash"

args is an array that provides arguments to the command. ${workspaceFolder} is the internal variable provided by the VS Code. It is the absolute path to our project’s root directory.

"args": ["${workspaceFolder}/.vscode/pre-release.sh"]

3. Running Tasks

Let us open the VS Code Command Palette using Ctrl + Shift + P, type Tasks: Run Task and press Enter.

VS Code Command Palette to run tasks

We will be presented with a list of tasks that we specified in the tasks.json. We will select the Pre-Release Setup and press Enter. We will see the task output in VS Code Integrated Terminal.

VS Code Command Palette to select tasks

Conclusion

We now have a good overview of how we can use VS Code tasks to run our scripts as tasks in a better way. We can also add more tasks like running pre-staging release, running pre-dev release and more.

Felipe Borges: Integrating sandboxed Vala apps with the host system through xdg-desktop-portals

https://feborg.es/vala-xdg-desktop-portals/

Portals are a mechanism through which applications can interact with the host environment from within a sandbox. They give the ability to interact with data, files, and services without the need to add sandbox permissions.

Examples of capabilities that can be accessed through portals include opening files through a file chooser dialog, or printing. More information about portals can be found in Sandbox Permissions.

Some portals, such as the FileChooser one, provide an almost seamless experience without much extra code on the app side. For other portals, you usually need some code to talk to the portal’s DBus interface or use libportal.

Vala was designed specifically for the development of GNOME apps, and it has some nice syntax-sugar that makes the communication with DBus pretty simple to implement.

GNOME Boxes is written in Vala and, for this reason, instead of consuming libportal, I introduced a small singleton Portal class that centralizes the whole portal communication logic for the app. This turned out to be quite convenient, so I am copy-pasting it in other Vala apps I work on, and sharing this here in case it can be useful to you too. 🙂

This works because in Vala you can define a namespace matching the desired DBus interface name and with annotations, you can bind objects, properties, and methods to a DBus service. See the Vala DBus Client Samples for more examples.

With the Portal singleton, a call to the Background portal requesting permission for the app to run in the background gets as simple as:

var portals = Portals.get_default ();
yield portals.request_to_run_in_background ((response, results) => {
    if (response == 0)
        // do something...
});

Notice that this is an async call and you may pass a callback to handle its response.

Nothing written here is new, but I thought it was worth sharing this snippet to help others make their apps integrate with xdg-desktop-portals and reduce the unnecessary exposition of user data in sandboxed environments.

Tobias Bernard: Community Power Part 2: The Process

https://blogs.gnome.org/tbernard/2021/06/15/community-power-2/

In part 1 of this series we looked at some common misconceptions about how power works inside the GNOME project and went over the roles and responsibilites of various sub-groups.

With that in place, let’s look at how of a feature (or app, redesign, or other product initiative) goes from idea to reality.

The Why

At the base of everything are the motivations for why we embark on new product initiatives. These are our shared values, beliefs, and goals, rooted in GNOME’s history and culture. They include goals like making the system more approachable or empowering third party developers, as well as non-goals, such as distracting people or introducing unnecessary complexity.

Since people across the project generally already agree on these it’s not something we talk about much day-to-day, but it informs everything we do.

This topic is important for understanding our development process, but big enough to warrant its own separate post in this series. I’ll go into a lot more detail there.

The What

At any given moment there are potentially hundreds of equally important things people working on GNOME could do to further the project’s goals. How do we choose what to work on when nobody is in charge?

This often depends on relatively hard to predict internal and external factors, such as

  • A volunteer taking a personal interest in solving a problem and getting others excited about it (e.g. Alexander Mikhaylenko’s multi-year quest for better 1-1 touchpad gestures)
  • A company giving their developers work time to focus on getting a specific feature done upstream (e.g. Endless with the customizable app grid)
  • The design team coming up with something and convincing developers to make it happen (e.g. the Shell dialog redesign in 3.36)
  • A technological shift presenting a rare opportunity to get a long-desired feature in (e.g. the Libadwaita stylesheet refresh enabling recoloring)

For larger efforts, momentum is key: If people see exciting developments in an area they’ll want to get involved and help make it even better, resulting in a virtuous cycle. A recent example of this was GNOME 40, where lots of contributors who don’t usually do much GNOME Shell UI work pitched in during the last few weeks of the cycle to get it over the line.

If something touches more than a handful of modules (e.g. the app menu migration), the typical approach is to start a formal “Initiative”: This is basically a Gitlab issue with a checklist of all affected modules and information on how people can help. Any contributor can start an initiative, but it’s of course not guaranteed that others will be interested in helping with it and there are plenty of stalled or slow-moving ones alongside the success stories.

The How

If a new app or feature is user-facing, the first step towards making it happen is to figure out the user experience we’re aiming for. This means that at some point before starting implementation the designers need to work through the problem, formulate goals, look at relevant art, and propose a way forward (often in the form of mockups). This usually involves a bunch of iterations, conversations with various stakeholders, and depending on the scale of the initiative, user research.

If the feature is not user-facing but has non-trivial technical implications (e.g. new dependencies) it’s good to check with some experienced developers or the release team whether it fits into the GNOME stack from a technical point of view.

Once there is a more or less agreed-upon design direction, the implementation can start. Depending on the size and scope of the feature there are likely additional design or implementation questions that require input from different people throughout the process.

When the feature starts getting to the point where it can be tested by others it gets more thorough design reviews (if it’s user facing), before finally being submitted for code review by the module’s maintainers. Once the maintainers are happy with the code, they merge it into the project’s main branch.


In the next installment we’ll look at what this power structure and development process mean for individual contributors wanting to work towards a specific goal, such as getting their pet bug fixed or feature implemented.

Until then, happy hacking!

Molly de Blanc: Welcome Red Hat as a GUADEC Sponsor

https://blogs.gnome.org/engagement/2021/06/15/welcome-red-hat-as-a-guadec-sponsor/

Red Hat is a Gold Sponsor of GUADEC 2021! We’re pleased to welcome them back to GUADEC for another year. As a Gold Sponsor, they will be hosting office hours on Wednesday, July 21. This will provide an opportunity for attendees to talk directly with Red Hat, about a range of topics, including the many GNOME-related activities they have going on.

“As one of the many active contributors within the vibrant GNOME community, Red Hat is very pleased to also be among the sponsors of this year’s GUADAC event,” said a representative from Red Hat. “Community is about connections, and as we move into a world that is waking up from decreased social contact, those connections are more important than ever. GNOME remains an incredible part of the open source ecosystem, and the conversations made at GUADEC amongst users and contributors are a big reason why GNOME continues to be successful! We are thrilled to be a part of these conversations and look forward to participating in the GUADEC 2021 online event.”

Kristi Progri, lead organizer of GUADEC, says “On behalf of everyone at GUADEC organizing team, I would like to express our sincere gratitude for the generous sponsorship to GUADEC, We’re happy they’re joining us again at GUADEC to help build GNOME and show the community what they are working on.”

About Red Hat

Red Hat is the world’s leading provider of open source software solutions, using a community-powered approach to provide reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As a connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT.

About GUADEC

GUADEC is the GNOME community’s largest conference, bringing together hundreds of users, contributors, community members, and enthusiastic supporters together for a week of talks and workshops. It takes place July 21 – 25 and will be online. This year’s keynote speakers are Hong Phuc Dang and Shauna Gordon-McKeon. Registration for GUADEC 2021 is open, please visit guadec.org to sign up.

About GNOME

GNOME is a free and open-source software environment project supported by a non-profit foundation. Together, the community of contributors and the Foundation create a computing platform and software ecosystem, composed entirely of free software, that is designed to be elegant, efficient, and easy to use.

The GNOME Foundation is a non-profit organization that believes in a world where everyone is empowered by technology they can trust. We do this by building a diverse and sustainable free software personal computing ecosystem.

Thibault Martin: Sovereignty on a Federated System: problems we faced on GNOME’s Matrix instance

https://blog.ergaster.org/post/20210610-sovereignty-federated-system-gnome/

This post follows an introduction to Matrix with e-mails, where I explain that Matrix is a federated system.
Federation can be either public or private. A public server can communicate with any other server, except the ones which are explicitely avoided. Meanwhile, a private server can only communicate with a selected list of other servers.
Private federation is often deployed between entities that can trust each other, for example between universites.

Tobias Bernard: Community Power Part 1: Misconceptions

https://blogs.gnome.org/tbernard/2021/06/11/community-power-1/

People new to the GNOME community often have a hard time understanding how we set goals, make decisions, assume responsibility, prioritize tasks, and so on. In short: They wonder where the power is.

When you don’t know how something works it’s natural to come up with a plausible story based on the available information. For example, some people intuitively assume that since our product is similar in function and appearance to those made by the Apples and Microsofts of the world, we must also be organized in a similar way.

This leads them to think that GNOME is developed by a centralized company with a hierarchical structure, where developers are assigned tasks by their manager, based on a roadmap set by higher management, with a marketing department coordinating public-facing messaging, and so on. Basically, they think we’re a tech company.

This in turn leads to things like

  • People making customer service style complaints, like they would to a company whose product they bought
  • General confusion around how resources are allocated (“Why are they working on X when they don’t even have Y?”)
  • Blaming/praising the GNOME Foundation for specific things to do with the product

If you’ve been around the community for a while you know that this view of the project bears no resemblance to how things actually work. However, given how complex the reality is it’s not surprising that some people have these misconceptions.

To understand how things are really done we need to examine the various groups involved in making GNOME, and how they interact.

GNOME Foundation

The GNOME Foundation is a US-based non-profit that owns the GNOME trademark, hosts our Gitlab and other infrastructure, organizes conferences, and employs one full-time GTK developer. This means that beyond setting priorities for said GTK developer, it has little to no influence on development.

Update: As of June 14, the GNOME Foundation no longer employs any GTK developers.

Individual Developers

The people actually making the product are either volunteers (and thus answer to nobody), or work for one of about a dozen companies employing people to work on various parts of GNOME. All of these companies have different interests and areas of focus depending on how they use GNOME, and tend to contribute accordingly.

In practice the line between “employed” contributor and volunteer can be quite blurry, as many contributors are paid to work on some specific things but also additionally contribute to other parts of GNOME in their free time.

Maintainers

Each module (e.g. app, library, or system component) has one or more maintainers. They are responsible for reviewing proposed changes, making releases, and generally managing the project.

In theory the individual maintainers of each module have more or less absolute power over those modules. They can merge any changes to the code, add and remove features, change the user interface, etc.

However, in practice maintainers rarely make non-trivial changes without consulting/communicating with other stakeholders across the project, for example the design team on things related to the user experience, the maintainers of other modules affected by a change, or the release team if dependencies change.

Release Team

The release team is responsible for coordinating the release of the entire suite of GNOME software as a single coherent product.

In addition to getting out two major releases every year (plus various point releases) they also curate what is and isn’t part of the core set of GNOME software, take care of the GNOME Flatpak runtimes, manage dependencies, fix build failures, and other related tasks.

The Release Team has a lot of power in the sense that they literally decide what is and isn’t part of GNOME. They can add and remove apps from the core set, and set system-wide default settings. However, they do not actually develop or maintain most of the modules, so the degree to which they can concretely impact the product is limited.

Design Team

Perhaps somewhat unusually for a free software project GNOME has a very active and well-respected design team (If I do say so myself :P). Anything related to the user experience is their purview, and in theory they have final say.

This includes most major product initiatives, such as introducing new apps or features, redesigning existing ones, the visual design of apps and system, design patterns and guidelines, and more.

However: There is nothing forcing developers to follow design team guidance. The design team’s power lies primarily in people trusting them to make the right decisions, and working with them to implement their designs.

How do things get done then?

No one person or group ultimately has much power over the direction of the project by themselves. Any major initiative requires people from multiple groups to work together.

This collaboration requires, above all, mutual trust on a number of levels:

  • Trust in the abilities of people from other teams, especially when it’s not your area of expertise
  • Trust that other people also embody the project’s values
  • Trust that people care about GNOME first and foremost (as opposed to, say, their employer’s interests)
  • Trust that people are in it for the long run (rather than just trying to quickly land something and then disappear)

This atmosphere of trust across the project allows for surprisingly smooth and efficient collaboration across dozens of modules and hundreds of contributors, despite there being little direct communication between most participants.


This concludes the first part of the series. In part 2 we’ll look at the various stages of how a feature is developed from conception to shipping.

Until then, happy hacking!