14 Sep 2024
Planet GNOME
Hans de Goede: Fedora plymouth boot splash not showing on systems with AMD GPUs
Recently there have been a number of reports (bug 2183743, bug 2276698, bug 2283839, bug 2312355) about the plymouth boot splash not showing properly on PCs using AMD GPUs.
The problem without plymouth and AMD GPUs is that the amdgpu driver is a really really big driver, which easily takes up to 10 seconds to load on older PCs. The delay caused by this may cause plymouth to timeout while waiting for the GPU to be initialized, causing it to fallback to the 3 dot text-mode boot splash.
There are 2 workaround for this depending on the PCs configuration:
1. With older AMD GPUs the radeon driver is actually used to drive the GPU but even though it is unused the amdgpu driver still loads slowing things down.
To check if this is the case for your PC start a terminal in a graphical login session and run: "lsmod | grep -E '^radeon|^amdgpu'" this will output something like this:
amdgpu 17829888 0
radeon 2371584 37
The second number after each is the usage count. As you can see in this example the amdgpu driver is not used. In this case you can disable the loading of the amdgpu driver by adding "modprobe.blacklist=amdgpu" to your kernel commandline:
sudo grubby --update-kernel=ALL --args="modprobe.blacklist=amdgpu"
2. If the amdgpu driver is actually used on your PC then plymouth not showing can be worked around by telling plymouth to use the simpledrm drm/kms device created from the EFI framebuffer early on boot, rather then waiting for the real GPU driver to load. Note this depends on your PC booting in EFI mode. To do this run:
sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm"
After using 1 of these workarounds plymouth should show normally again on boot (and booting should be a bit faster).
comments
14 Sep 2024 1:38pm GMT
13 Sep 2024
Planet GNOME
Juan Pablo Ugarte: Introducing Casilda – A Wayland compositor widget!
I am pleased to introduce the first stable release of Casilda!
A simple Wayland compositor widget for Gtk 4 which can be used to embed other processes windows in your Gtk 4 application.
It was originally created for Cambalache's workspace using wlroots, a modular library to create Wayland compositors.
Following Wayland tradition, this library is named after my hometown in Santa Fe, Argentina
License
Casilda is distributed under the GNU Lesser General Public License version 2.1 only.
Where to get it?
Source code lives on GNOME gitlab here
git clone https://gitlab.gnome.org/jpu/casilda.git
Manual installation
This is a regular meson package and can be installed the usual way.
# Configure project in _build directory meson setup --wipe --prefix=~/.local _build . # Build and install in ~/.local ninja -C _build install
How to use it
To add a Wayland compositor to your application all you have to do is create a CasildaCompositor widget. You can specify which UNIX socket the compositor will listen for clients connections or let it will choose one automatically.
compositor = casilda_compositor_new ("/tmp/casilda-example.sock"); gtk_window_set_child (GTK_WINDOW (window), GTK_WIDGET (compositor));
Once the compositor is running you can connect to it by specifying the socket in WAYLAND_DISPLAY environment variable.
export GDK_BACKEND=wayland export WAYLAND_DISPLAY=/tmp/casilda-example.sock gtk4-demo
API
The api is pretty simple CasildaCompositor has two properties, socket and bg-color.
- socket: The unix socket file to connect to this compositor (string)
- bg-color: Compositor background color (GdkRGBA)
Matrix channel
Have any question? come chat with us at #cambalache:gnome.org
Mastodon
Follow me in Mastodon @xjuan to get news related to Casilda and Cambalache development.
Happy coding!
13 Sep 2024 5:36pm GMT
Alice Mikhaylenko: Libadwaita 1.6
Well, it's time for another release.
Last cycle wasn't particularly exciting, only featuring the new dialogs and a few smaller changes, but this one should be more interesting. So let's look at what's new.
Bottom sheet
Last cycle libadwaita got new dialogs, which can be presented as bottom sheets on mobile, and I mentioned that they will also be available as a standalone widget in future - so AdwBottomSheet
exists and is public now.
As a standalone widget, bottom sheets work a bit differently from dialogs - they are persistent instead of being destroyed upon closing, more like the sidebar of AdwOverlaySplitView
.
They also have a few new features, such as a drag handle, or a bottom bar presentation. This is useful for apps like music players.
AdwHeaderBar
also integrates with bottom sheets - it hides the title when used in a bottom sheet with a drag handle.
Spinner
Libadwaita also has a new spinner widget - AdwSpinner
. It both refreshes visuals and addresses various problems with GtkSpinner
.
GtkSpinner
is a really simple widget. Both the spinner itself and the animation are set in CSS. The spinner is just a symbolic icon, and the animation is a CSS animation. This approach has a few problems, however.
First, the old spinner has a gradient. Symbolic icons don't actually support gradients, so it has to resort to dithering, as Jakub Steiner explained in his blog a few years ago. This works well if the spinner is small enough (16×16 - 32×32), but becomes very noticeable at larger sizes. This means that the spinner didn't work well for loading screens, or status pages.
Meanwhile, CSS animations are entirely disabled when system animations are off. Usually that makes sense, except here it means the spinner freezes, defeating the entire point of having it (indicating that the app isn't frozen during long operations).
And, while CSS animations are pretty sophisticated, you can only do so much with a single element - so it's literally a spinning icon. elementary OS does a more interesting thing - it spins it in steps, while the icon consists of 12 dashes, so it looks like they change color instead. Even then, more complex animations are impossible.
AdwSpinner
avoids all of these issues. Since it's in libadwaita and not in GTK, it can be more opinionated with regard to styling, so instead of using an icon and CSS, it's just custom drawing. And since it's not using CSS animations, it can keep spinning with animations off, and can animate in a more involved way than a simple spinning icon.
It still has a size limit - 64×64 pixels. While it can scale further, we don't really need larger sizes and capping the size makes it easier to use - to make a loading screen using GtkSpinner
, you have to set the :halign
and :valign
properties to CENTER
, as well as :width-request
and :height-request
properties to 32. If you fail to do these steps, the spinner will either be too large, or too small respectively:
Meanwhile if you just put an AdwSpinner
into a large bin, it will look right by default.
Oh, and GtkSpinner
is invisible by default and you have to set the :spinning
property to true as well. This made sense back in the age of foot and dinosaur spinners, where the spinner would stay in place when not animating, but that's not really a thing anymore.
(though Nautilus wasn't actually using GtkSpinner
)
It also didn't help that until this cycle, GtkSpinner
would continue to consume CPU cycles even when not visible if the :spinning
property is left enabled, so you had to start the spinner in the ::map
signal and stop it in ::unmap
. That is fixed now, but it was a major source of lag in, say, Epiphany in the past (which had a spinner in every tab, another spinner in every mobile tab switcher row and another one in the floating bar that shows URLs on hover, copied from Nautilus).
Spinner paintable
In addition to AdwSpinner
, there's also AdwSpinnerPaintable
. It can be used with GtkImage
, any other place that accepts paintables (such as status pages) or just manually drawn. It is a bit more awkward to use than the widget, as it needs to reference another widget so it can animate (since paintables cannot access the frame clock), but it allows to use spinners in contexts that wouldn't be possible otherwise.
AdwStatusPage
even has a special style for spinner paintable - similar to the .compact
style, but applied automatically.
Button row
Another widget we have now is AdwButtonRow
- a list row that looks more or less like a button. It has a label, optionally icons on either side, and can use destructive and suggested style classes.
This pattern isn't new - it has been used in mockups for a while (at least as early as 2021) - but it varied quite a bit between different mockups and implementation and so having a standard widget for it wasn't viable. This cycle Jamie Gravendeel and kramo took time to standardize the existing designs into a tangible proposal - so it exists as a standard widget now.
Most of the time these rows aren't meant to be linked together, so AdwPreferencesGroup
has a new property :separate-rows
. When enabled, the rows within will appear separately. This is mostly useful for button rows, but also e.g. entry rows. When not using AdwPreferencesGroup
, the same effect can be achieved by using the .boxed-list-separate
style class instead of .boxed-list
.
Multi-layout view
Libadwaita 1.4 introduced AdwBreakpoint
, which allowed to easily set properties on window size changes. However, a lot of apps need layout changes that can't be expressed via simple properties - say, switching between a sidebar and a bottom sheet. While it is possible to do it programmatically anyway, it's fairly involved and not a lot of apps went to those lengths.
Back then I also prototyped a widget for automatically reparenting children between different layouts via using a property mentioned a future widget for automatically reparenting children between different layouts, and now it's finished and available for use as AdwMultiLayoutView
.
It has changed somewhat since the prototype, e.g. it doesn't dynamically create or destroy layouts anymore, just parents/unparents them, but the gist is still the same:
- Put multiple
AdwLayout
s into a multi-layout view - Put one or more
AdwLayoutSlot
into each layout, give them IDs - Define children matching those IDs
Then those children will be placed into the slots for the current layout. When you switch the layout, they will be reparented into slots from that layout instead.
So now it's possible to define completely different layouts for desktop and mobile entirely via UI files.
CSS variables and colors
I've already talked about this in a lot of detail in my last blog post, but GTK has a lot of new CSS goodies, and libadwaita 1.6 makes full use of them.
To recap: GTK now supports CSS variables, as well as color-mix()
, relative colors, as well as new color spaces, most importantly Oklab and Oklch.
Libadwaita now provides CSS variables for all of its old named colors, with a docs page to go with it, as well as new variables: --dim-opacity
, --disabled-opacity
, --border-opacity
and --window-radius
.
This also allowed to have matching focus ring color on .destructive-action
buttons, as well as matching accent color for the .error
, .warning
and .success
style classes. And because overriding accent color for a specific widget is now possible, .opaque
button style class has been deprecated in favor of overriding accent colors on .suggested-action
. Meanwhile, the white accent color of .osd
is now more reliable and automatically works for custom widgets, instead of trying (and often failing) to manually override it for every standard widget.
I mentioned that it might be possible to generate standalone accent/error/etc colors from their respective background colors. However, the question was how to make that automatic, so at the time we didn't actually integrate that. Now it is integrated, though it's not completely automatic - only for :root
.
Specifically, there's a new variable: --standalone-color-oklab
, corresponding to the correct color transformation for the current style.
So, when overriding accent color for a specific widget, there is a bit of boilerplate to copy:
my-widget { --accent-bg-color: var(--accent-purple); --accent-color: oklab(from var(--accent-bg-color) var(--standalone-color-oklab)); }
It's still an improvement over calculating the color manually, both for light and dark styles (which a lot of apps didn't do at all, resulting in poor contrast), so still worth it. Maybe one day we'll be able to make it completely automatic - e.g. by ensuring that using variables with wildcards doesn't regress performance.
Meanwhile adw_rgba_to_standalone()
allows to do the same thing programmatically.
Accent colors
Another big feature is system accent color support. While it's not a strictly libadwaita change, this is the developer-facing part, so it makes sense to talk about it here.
Behind the scenes it's using the settings portal which provides a standardized key for the system accent color. Many other environments support it as well, so libadwaita apps will follow their accent color preferences too, while non-GNOME apps that follow the preference will follow it on GNOME too. Note that while the portal exposes arbitrary sRGB colors, libadwaita will pick the closest color from a list of nine colors, as visible on the screenshot above. This is done in the Oklch color space, mostly based on hue, so should work even for really dull colors.
Accent colors are also supported when running on Windows and macOS, and like with the color scheme and high contrast, the libadwaita page in GTK inspector allows to toggle the system accent color now.
Apps are still free to set their own accent color. CSS always takes priority over the system accent.
A lot of people helped push this over the finish line, with particular thanks to Jamie Murphy, kramo and Jamie Gravendeel.
API
AdwStyleManager
provides new properties for fetching the system color - :accent-color
and :accent-color-rgb
, as well as :system-supports-accent-colors
for querying whether the system has accent color preferences - same as for color scheme.
The :accent-color
property returns a color from the AdwAccentColor
enum, so that individual colors can be special cased (say, when using bitmap assets). This color can be converted both to background color RGBA (using adw_accent_color_to_rgba()
) and to standalone color (adw_accent_color_to_standalone_rgba()
).
All of these colors use white foreground color, so there's no API for fetching it, at least for now.
Note that :accent-color-rgba
will still return the system color even if the app overrides its accent color using CSS. It only exists for convenience and is equivalent to calling adw_accent_color_to_rgba()
on the :accent-color
value.
While we still don't have a general replacement for deprecated gtk_style_context_lookup_color()
, the new accent color API can replace at least some of its uses.
On CSS side, there are new variables corresponding to each accent color: --accent-blue
for blue and so on. Additionally, every system color, along with their standalone colors for both light and dark, is documented and can be used as a reference.
Destructive buttons
Having accent color that's not always blue means having to rethink other style choices. In particular, .destructive-action
buttons were just a red version of .suggested-action
, same as in GTK3. This was already questionable from accessibility perspective, but breaks entirely with accent colors, since suggested buttons would look exactly same as a destructive ones with red accent. And so .destructive-action
has a distinct style now, less prominent than suggested.
Alert dialogs
Another area that needed updates was AdwAlertDialog
- it was also using color for differentiating suggested and destructive buttons.
Coincidentally, the alert dialog style went almost unchanged from GTK3 days, and looked rather out of place with the rest of the platform. So kramo came up with an updated design.
AdwMessageDialog
and GtkAlertDialog
received the same style, or at least an approximation - it's not possible to replicate it entirely in GTK dialogs. Even though neither is recommended for use (when using libadwaita, anyway - nothing wrong with using GtkAlertDialog
in plain GTK), regressing apps that aren't fully up to date with the platform wouldn't be very good.
Adapting apps
Accent colors are supported automatically, and in most cases apps don't need any changes to make use of them. However, here's a checklist to ensure it works well:
- Make use of the accent color variables in custom CSS, like
--accent-bg-color
. Using the old named colors like@accent_bg_color
works as well. Don't assume accent color will be blue. - Conversely, don't use accent color when you mean blue. We have variables like
--blue-3
for that - or even--accent-blue
. - When using accent color in custom drawing (say, drawing a graph), make sure to redraw it when
AdwStyleManager:accent-color
value changes - same as for color scheme and high contrast. -
Deprecations
Last cycle we introduced new dialog widgets that are based on
AdwDialog
rather thanGtkWindow
. However, that happened right at the end of the cycle, without giving apps a lot of time to port their existing dialogs. Because of that, the old widgets (AdwMessageDialog
,AdwPreferencesWindow
,AdwAboutWindow
) weren't deprecated and I mentioned that they will be deprecated in future instead. So, they are now.If you haven't migrated to the new dialogs yet, see the migration guide for how to do so.
Other changes
As always, there are smaller changes that don't warrant their own sections, so let's look at those:
AdwWindow
andAdwApplicationWindow
now have a default minimum size (360×200 px), meaning you don't have to set it manually to use breakpoints or dialogs anymore. Apps can still override it if they need a different size, but it works out of the box now.AdwComboRow
now has the:header-factory
and:search-match-mode
properties, followingGtkDropDown
. So it's now possible to, say, have separators in the dropdown list.AdwEntryRow
got the:max-length
property, matchingGtkEntry
.AdwPreferencesPage
description now can be centered, using the:description-centered
property.- Documentation now lists available style classes for each widget, in addition to the centralized list of style classes.
- Markus Göllnitz made the
.navigation-sidebar
style class supportGtkFlowBox
andGtkGridView
, as seen in Papers. - Property rows now support the
.monospace
style class. GtkTextView
now supports the.inline
style class, removing its background and resetting its foreground color. This allows to use it in contexts like cards.
Future
As usual, there are changes that didn't make it this cycle and will land the next cycle instead. Most notably, the old toggle groups branch by Maximiliano is finally finished and will land early next cycle.
Big thanks to STF for funding a lot of this work (GTK CSS improvements, bottom sheets, finishing multi-layout view and toggle groups, general maintenance), as well as people organizing the initiative and all contributors who made this release happen.
13 Sep 2024 3:32pm GMT
GNOME Foundation News: GNOME Foundation Opens Search for New Executive Director
The GNOME Foundation is excited to announce that we have officially opened the search for a new Executive Director. This is an exciting time for our organization as we seek a dynamic leader to guide us into the future, continuing our mission to foster the growth of GNOME and the wider free software community.
As the cornerstone of our leadership team, the Executive Director will play a critical role in shaping the strategic direction of the Foundation, working closely with staff, community members, and partners to expand our reach and impact. The ideal candidate will have professional experience working with nonprofits, a strong passion for open-source software, a deep commitment to our community values, and the vision to drive the next phase of GNOME's growth and development.
The position offers a unique opportunity to lead a pivotal project in the open-source ecosystem, collaborating with a global network of contributors and partners. Interested candidates can find more details on the role and how to apply on our careers page.
We encourage qualified individuals who share our vision of promoting software freedom and innovation to apply. We are looking forward to finding the next Executive Director who will carry forward the mission of the GNOME Foundation, driving positive change within the tech world and beyond.
Applications are due by September 20th, 2024.
13 Sep 2024 1:00pm GMT
This Week in GNOME: #165 Signing Documents
Update on what happened across the GNOME project in the week from September 06 to September 13.
Sovereign Tech Fund
Thib says
This post is a digest of what happened in August in the STF team (a little late). You might have seen some updates from the team members directly earlier in TWIG! They say August is a productivity blackhole, but whoa look at this massive update!
I'm very grateful to the team for its dedication, and to the Sovereign Tech Fund who enables this work. The Foundation is preparing a crowdfunding platform to allow you to support this kind of work as well! More on this next month.
Encrypt user home directories individually
On Linux systems, users are traditionally managed in a specific file called
/etc/passwd
. It doesn't make a difference between technical and human accounts. It also only stores very basic information about users, and can only be modified by root. It's a very rigid users database.AccountsService is a "temporary" daemon (since 2010) bringing to manage users and store more extensive information about them: profile picture, parental control settings, preferred session to log into, languages, etc. It manages
/etc/passwd
and its own database.homed is a modern replacement for AccountsService. It provides encryption for user data, and paves the way for future exciting platform security and flexibility improvements.
Adrian worked with a user through some remote debugging about systemd-homed (systemd/systemd#33541 and following comments).
Modernize platform infrastructure
libadwaita
GTK is a popular development toolkit to create graphical apps in the free desktop. libadwaita is a library based on GTK providing the building blocks for modern GNOME applications.
Alice did libadwaita releases: 1.4.7, 1.5.3, 1.6.beta, and 1.6.rc. She also worked on Dialog fixes before beta (here and here), a CI fix as well as several reviews.
She shared thoughts on a common interface for platform libraries support in GTK in this issue.
Alice also worked on toggle groups
- She added crossfade support to the view stack so we can use it in contexts where you'd want an inline switcher
- She switched inline stack switcher to view stack, renamed to inline view switcher
- And she started reworking toggle group api. That work is still ongoing
- inline view switcher now supports needs-attention/badges.
- Alice also he gave the tests (including accessibility tests) some love to make sure libadwaita is as reliable as ever and implemented a new demo.
- She reworked documentation to make her work easier to use
- Finally she spent quite a bit of time on reviews for PRs have been merged (here, here, here, and here and quite a few more) and on PRs that have not.
Toggle groups should be ready, waiting for 47 to branch now.
Shell notifications
If you have followed Julian's GUADEC talk about notifications on the free desktop, you know that the current situation is suboptimal. Fortunately, the design team and Julian are coming to the rescue, and are also working on grouped notifications to make them less in your face.
Julian split out refactor part of of the notification grouping MR, so that it can be merged sooner. He also addressed comments and got his cleanup MR merged into GNOME Shell.
Julian rewrote glsl shader for fading notifications when a group is expanded. He looked into round clipping for mutter, which would be really nice for grouping. This will require a significant amount of non trivial work to do correctly.
Finally, he worked on notification grouping for GNOME Shell: after addressing the style suggestions he marked the notification grouping MR as ready.
Improve QA and development tooling
gjs bindings
Evan finished work on getting async support for GJS, compiling again and is debugging test failures.
He is working on updating async tests for the TypeScript bindings.
Finally, GLib async support needs additional work to fix Windows CI (hopefully the last roadblock 🤞).
systemd-sysupdated
systemd-sysupdate is an update system allowing immutable systems to apply lightweight delta updates. It helps image-based systems support immutability, auto-updates, adaptability, factory reset, uniformity and providing a trust chain from the bootloader all the way up.
sysupdate is a CLI tool. In order to be able to use systemd-sysupdate, sturdier services are needed. sysupdated is a service that provides a dbus API for sysupdate.
sysupdated got a final re-review, and got merged into systemd. Adrian followed-up fixes after merging.
He rebased the incomplete versions bugfix, and got it merged, worked on optional features, major os upgrades,
updatectl
(a user facing CLI for sysupdate) bugfixes and more.systemd-repart
systemd-repart is a tool that systemd runs on boot that non-destructively repartitions disks.
Adrian taught it to dynamically decide whether or not to create a separate boot partition. Depending on the existing layout of disk, repart will skip creating a dedicated boot partition if it can get away with it, which is one of the big missing features in repart before it can be an OS installer.
Improve the state and compatibility of accessibility
Joanie has been working on a metric tonne of updates in Orca. Most of the changes are rather technical and would be rather wordy in a TWIG update, but thanks Joanie for rejuvenating Orca!
Maintenance and modernization of security components
The free desktop standardises the storage and usage of secrets (such as passphrases or SSH keys) via the secrets specification. gnome-keyring was the backend implementation, and libsecret the client-side of said specification.
gnome-keyring and libsecret are written in C and lack maintenance. oo7 is a modern Rust client-side library that respects the secrets specification. Dhanuka is extending oo7 to implement the backend side of secrets management, and ultimately replace gnome-keyring, has been at it in August as well!
Secure APIs for Wayland/Flatpak
Flatpak
Georges handled Flatpak / Bubblewrap CVE-2024-42472, released xdg-dbus-proxy 0.1.6 with important fixes, coordinated more merges, and released Flatpak 1.16.0.
He also implemented a solution to the "impossible" Flatpak a11y issue (here, here and here). This accessibility issue revolved around the Flatpak sandbox preventing WebKit and Epiphany's accessibility trees from being connected.
USB Portal
Flatpak doesn't have USB permission. To access USB currently, the
device=all
permission must be used. This exposes all the devices on the machine.We want to provide a way to allow selective access to USB devices from inside a sandbox like flatpak. This is access to the actual USB, not the devices build on top, like audio, input or mass storage.
Hub rebased the xdg-desktop-portal PR for the USB portal, and rebased the flatpak PR for USB. Finally, https://github.com/flatpak/flatpak/pull/5855 landed.
Closing thoughts
Again, a massive massive thank you to the whole team who has been working on the STF grant, and our gratitude to the Sovereign Tech Fund who makes this possible. The team is working with all their heart to bring not only GNOME but also the free desktop as a whole forward.
GNOME Core Apps and Libraries
Libadwaita
Building blocks for modern GNOME apps using GTK4.
Alice (she/her) says
libadwaita 1.6.0 is out! see the blog post for details.
GNOME Incubating Apps
Pablo Correa Gomez reports
Thanks to Jan-Michael Brummer (Volkswagen), Papers now supports signing documents with digital certificates! If you have a digital certificate stored in your computer or in an Smart Card, as those stored in the national IDs of some states like Estonia or Spain, you no longer need an additional program to digitally sign your documents! See the Merge Request description for a walk-through of the UX!
Third Party Projects
Hari Rana | TheEvilSkeleton announces
Upscaler version 1.3.0 was just released! The release is pretty large and includes some nice features and visual improvements:
- Introduce queue system to allow users to upscale images right after the other
- Add branding colors
- Port to latest Adwaita widgets
- Allow dropping remote images
- Allow pasting images from clipboard
- Make window draggable from anywhere
- Delete temporary file when unused
- Switch to Upscayl-NCNN from Real-ESRGAN ncnn Vulkan
- Update and rework translation
- Add Bulgarian translation
Unfortunately, I completely forgot that the GNOME 47 runtime isn't released yet. The update will be available later once the GNOME 47 runtime is out. If you want to try it out, you can build it from source (roughly a few minutes) using GNOME Builder: https://gitlab.gnome.org/World/Upscaler#gnome-builder
Krafting says
Version 1.2.0 of SemantiK is out now. It is a word-guessing game.
This new version includes the ability to download language packs. The first language pack to be available is the English language pack, which you can download on Flathub through your software center of choice.
The UI is still in French, but I'll be adding a translated UI in the next version!
You can download SemantiK from Flathub
If people want to help build more language packs, feel free to contact me!
xjuan says
Introducing Casilda - A Wayland compositor widget!
A simple Wayland compositor widget for Gtk 4 which can be used to embed other processes windows in your Gtk 4 application. It was originally created for Cambalache's workspace using wlroots, a modular library to create Wayland compositors. Following Wayland tradition, this library is named after my hometown in Santa Fe, Argentina
Read more about it at https://blogs.gnome.org/xjuan/2024/09/13/introducing-casilda-wayland-compositor-widget/
Pipeline
Follow your favorite video creators.
schmiddi reports
Pipeline version 2.0.0 was released. Pipeline lets you follow your favorite video creators, both on YouTube and PeerTube. Version 2.0.0 is a complete rewrite of the application, in order allow for easier maintenance, more features (some included in this version, some in future versions) and improve the user experience in general.
The highlights of this version are the ability to search YouTube and PeerTube for videos and channels and playing videos inside the application using the Clapper video player (while the option to play with any other external player is still available). Besides those highlights, the application should have feature-parity with previous releases of Pipeline. This includes in particular:
- Displaying videos of your subscriptions in a single feed,
- Filtering out unwanted videos, for example Shorts or videos from a series you don't like,
- Managing videos you want to watch later,
- Importing your previous subscriptions from NewPipe or YouTube,
- Download videos you want to watch offline.
You can get the latest release on Flathub, and feel free to chat with us in our Matrix room.
Miscellaneous
Jan-Michael Brummer says
Software development without Linux is no longer possible within an automotive environment. Therefore Volkswagen Group IT created and maintains a Linux distribution for their developers and contributes to many upstream projects. Jan-Michael Brummer speaks at OpenSUSE 2024 (https://media.ccc.de/v/4486-linux-at-volkswagen/oembed) about the starting goal to integrate into the existing environment, and highlights their integration problems and solutions with contributing to upstream: libproxy, OneDrive (gvfs/goa), PKCS11 (Secrets / Web), Digital Signing (Papers), …
GNOME Foundation
Allan Day announces
The GNOME Foundation has announced that hiring is open for its next Executive Director. Details about the position can be found on the GNOME Foundation website, at OpenSource Job Hub, and fossjobs.net. Please share the post with your networks and reach out to any candidates you might know. In other Foundation news, the Board of Directors had its regular monthly meeting this week, where it focused on budget planning for the upcoming financial year. We are also pleased to announce that Richard Littauer, the Foundation's current interim executive director, will be continuing in his position until the end of November.
Rosanna reports
The big news this week from the Foundation is our opening up the search for a new Executive Director. Our current Interim Executive Director, Richard Littauer, is helping us with this search. More details about this job opening is available https://foundation.gnome.org/2024/09/13/search-for-new-executive-director/.
Earlier this week, I attended the monthly board meeting and went through a very rough, preliminary draft of a budget for the Board. Not intended to be a working budget, this draft is just a starting point to begin discussion. While it is up to the Finance Committee to hammer this draft into something usable, this exercise of going over it with the board at large was useful in showing our directors the format and structure of our yearly budget, and in explaining what the groupings and categories cover. I am looking forward with the rest of the Finance Committee on the next steps.
That's all for this week!
See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!
13 Sep 2024 12:00am GMT
12 Sep 2024
Planet GNOME
Jakub Steiner: Weyland
A couple of weeks ago, I went to see Alien: Romulus. While many of my friends were disappointed, I actually enjoyed it. In fact, it exceeded my expectations - mainly because I didn't expect much! :)
Fede Alvarez delivered exactly what producer Ridley Scott asked of him, leaning heavily on the nostalgia of the original masterpiece while skirting the edge of a reboot. The world of Prometheus wasn't ignored, but purposedly avoided referencing too deeply.
The dystopian world of corporate feudalism set a tone even darker than the original, to the point where the xenomorph didn't seem like the worst thing that could happen. I'm still holding out hope for 90-minute movies as the gold standard, but the two-hour runtime was manageable-though my aging buttocks may disagree. The slow-burn first act was actually the most enjoyable part, as that's where the fresh world-building took center stage. Even as the familiar plot unfolded, Alvarez delivered memorable suspense and action scenes.
Of course, it's never going to feel the same as seeing Alien or Aliens as a teenager. I can't fully dive into my minor criticisms without spoilers, but let's just say the movie understood that "less is more" - except in one area. Other than that, Alien: Romulus proved that going to the movies can still be a pretty great experience.
★★★★☆
12 Sep 2024 10:00pm GMT
GNOME Foundation News: GNOME Asia 2024 in Bengaluru, India
We are excited to announce that GNOME Asia 2024 will take place in Bengaluru, India, from December 6th-8th.
This year the summit will offer a hybrid experience allowing attendees to participate virtually or in person.
The Call for Participation is now open. We are accepting both in-person and remote talks and workshops. If you are interested in submitting a proposal make sure to apply on our event website by September 30th.
If you or your company are interested in sponsoring GNOME Asia 2024, please review our sponsorship brochure and get in touch with us at asia@gnome.org.
About Bengaluru
Bengaluru, often called the "Silicon Valley of India," is a dynamic city known for its thriving tech scene and vibrant open-source community. As a key hub for technology and innovation, Bengaluru is home to many Linux and GNOME contributors who play a vital role in the global open-source movement. The city has also become a focal point for startups and IT giants, contributing significantly to technological advancements and digital solutions.
Beyond its technological achievements, Bengaluru boasts a rich cultural heritage. Visitors can explore iconic landmarks such as the Bangalore Palace, Tipu Sultan's Summer Palace, and the historic Bull Temple. The city's spiritual side shines through at the ISKCON Temple, while the grandeur of Vidhana Soudha stands as a testament to its political significance. For those seeking tranquility, serene green spaces like Lalbagh Botanical Garden, Cubbon Park, and Ulsoor Lake offer a respite from the urban buzz.
Bengaluru enjoys a pleasant climate year-round, with moderate temperatures and a mix of sunny and rainy days, adding to its appeal as a city of innovation and tradition. This unique blend of a progressive tech hub and cultural richness makes Bengaluru a standout destination both for its technological prowess and its historical charm.
Image credit: "South Bengaluru Skyline as seen from ISKCON, Banashankari" by Raghavan2010 is licensed under CC BY 4.0
About GNOME.Asia
GNOME.Asia is a featured annual conference focused on the GNOME project and the GNOME desktop environment. The summit aims at bringing the GNOME community in Asia together to provide a forum for users, developers, foundation leaders, governments, and businesses to discuss current technology and future developments.
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.
12 Sep 2024 8:13pm GMT
11 Sep 2024
Planet GNOME
Jussi Pakkanen: On M and S Type Processes in Software Development
I wrote a post about so called "M type" and "S type" processes in software development. Unfortunately it discusses the concept of human sexuality. Now, just to be sure, it does not have any of the "good stuff" as the kids might say. Nonetheless this blog is syndicated in places where such topics might be considered controversial or even unacceptable.
Thus I can't really post the text here. Those of you who are of legal age (whatever that means in your jurisdiction) and out of their own free will want to read such material, can access the PDF version of the article via this link.
11 Sep 2024 9:33pm GMT
09 Sep 2024
Planet GNOME
Tamnjong Larry Tabeh: Usability Study Report for Loup, Showtime, And Decibels
📢The Usability Study Report for Loup, Showtime, and Decibels, conducted during the May to August Outreachy internship round, is now available!
🚀 Check it out here: https://lnkd.in/gRZs5VR4
09 Sep 2024 11:10am GMT
08 Sep 2024
Planet GNOME
Jakub Steiner: Autonomous Cameraman
It's been a while since I've annoyed you by mentioning drones, but here we are with DJI's latest creation-the Neo. DJI is a giant, soulless corporation, but they've made some clever design decisions with this drone. It's a flying camera that works without a phone or remote, and for about half the price of a GoPro, you get a self-sufficient, button-operated flying cameraman. Take it out, push a button, and off it goes, capturing footage like it knows what it's doing. It might also just simply be a response to the actually innovative HoverAir X1, just made extremely affordable.
The camera quality won't blow you away, but it's solid enough if you can overlook its overly-sharpened aesthetic. The Neo can even play the part of a lightweight cinewhoop or a poor man's DJI Mini, though that's only if you own DJI's latest goggles and remotes-so there's a bit of a catch. I bought it mainly for the fun shots you're watching here, and while I'm not interested in keeping up with DJI's endless upgrades, I must admit the little drone has charm and utility.
Neo's Follow
mode is a standout, tracking you accurately with just its camera feed and no fancy sensors. It tries to follow your path to avoid hitting anything. But beware the Direction Tracking
mode in crowded areas-it has a habit of misjudging where you're facing and wobbling about. The biggest hiccup I encountered? No gesture to make it return home, which left me standing under it after performing a Rocket
shot, until the battery ran out. Luckily the pain lasted only about 10 minutes. Overall, it's a great toy for hikes, casual outings, and occasional public embarrassment.
Soundtrack for the poorly edited video above comes from my 2024 weekly beats endeavors. Looks like I have enough material for a 2025 album. Stay tuned!
08 Sep 2024 10:00pm GMT
07 Sep 2024
Planet GNOME
Marcus Lundblad: Maps and GNOME 47
Switch to Vector-based Map
Light (default) theme variant of the map in 47 |
Dark theme variant of the map in 47 |
Redesigned Search Bar
Improved Public Transit Routing
Showing some travel itinerary options in Prague |
Showing a sample of an itinerary from Lund, Sweden to Hamburg, Germany |
Showing a sample of an itinerary in Denver, Colorado |
Updated Highway Shield Localizations
French departmental routes (D-roads) |
Turkish national D-roads |
Some changes had to be made to our internal shield rendering library (we couldn't use the OSM Americana implementation directly, as we had to implement ours using Cairo rendering and so on) to support the new convenience shortcut for a "pill" shield shape, and also being able to define hard-coded route references "ref" directly in the shield definition rather than getting from the tile data.
Rochester Inner Loop in Rochester, New York, using a fixed "LOOP" reference label |
Highway shields in New Zeeland |
It was a bit funny I discovered this bug when "browsing around" in New Zeeland considering Northern Hemisphere-centric jokes about people "Down-under" walking upside-down 😀. But this actually also affects some highways in the US…
07 Sep 2024 1:48pm GMT
Andy Wingo: conservative gc can be faster than precise gc
Should your garbage collector be precise or conservative? The prevailing wisdom is that precise is always better. Conservative GC can retain more objects than strictly necessary, making GC slow: GC has to more frequently, and it has to trace a larger heap on each collection. However the calculus is not as straightforward as most people think, and indeed there are some reasons to expect that conservative root-finding can result in faster systems.
(I have made / relayed some of these arguments before but I feel like a dedicated article can make a contribution here.)
problem precision
Let us assume that by conservative GC we mean conservative root-finding, in which the collector assumes that any integer on the stack that happens to be a heap address indicates a reference on the object containing that address. The address doesn't have to be at the start of the object. Assume that objects on the heap are traced precisely; contrast to BDW-GC which generally traces both the stack and the heap conservatively. Assume a collector that will pin referents of conservative roots, but in which objects not referred to by a conservative root can be moved, as in Conservative Immix or Whippet's stack-conservative-mmc collector.
With that out of the way, let's look at some reasons why conservative GC might be faster than precise GC.
smaller lifetimes
A compiler that does precise root-finding will typically output a side-table indicating which slots in a stack frame hold references to heap objects. These lifetimes aren't always precise, in the sense that although they precisely enumerate heap references, those heap references might actually not be used in the continuation of the stack frame. When GC occurs, it might mark more objects as live than are actually live, which is the imputed disadvantage of conservative collectors.
This is most obviously the case when you need to explicitly register roots with some kind of handle API: the handle will typically be kept live until the scope ends, but that might be an overapproximation of lifetime. A compiler that can assume conservative stack scanning may well exhibit more precision than it would if it needed to emit stack maps.
no run-time overhead
For generated code, stack maps are great. But if a compiler needs to call out to C++ or something, it needs to precisely track roots in a run-time data structure. This is overhead, and conservative collectors avoid it.
smaller stack frames
A compiler may partition spill space on a stack into a part that contains pointers to the heap and a part containing numbers or other unboxed data. This may lead to larger stack sizes than if you could just re-use a slot for two purposes, if the lifetimes don't overlap. A similar concern applies for compilers that partition registers.
no stack maps
The need to emit stack maps is annoying for a compiler and makes binaries bigger. Of course it's necessary for precise roots. But then there is additional overhead when tracing the stack: for each frame on the stack, you need to look up the stack map for the return continuation, which takes time. It may be faster to just test if words on the stack might be pointers to the heap.
unconstrained compiler
Having to make stack maps is a constraint imposed on the compiler. Maybe if you don't need them, the compiler could do a better job, or you could use a different compiler entirely. A conservative compiler can sometimes have better codegen, for example by the use of interior pointers.
anecdotal evidence
The Conservative Immix paper shows that conservative stack scanning can beat precise scanning in some cases. I have reproduced these results with parallel-stack-conservative-mmc compared to parallel-mmc. It's small-maybe a percent-but it was a surprising result to me and I thought others might want to know.
Also, Apple's JavaScriptCore uses conservative stack scanning, and V8 is looking at switching to it. Funny, right?
conclusion
When it comes to designing a system with GC, don't count out conservative stack scanning; the tradeoffs don't obviously go one way or the other, and conservative scanning might be the right engineering choice for your system.
07 Sep 2024 10:00am GMT
06 Sep 2024
Planet GNOME
Andy Wingo: on taking advantage of ragged stops
Many years ago I read one of those Cliff Click "here's what I learned" articles in which he was giving advice about garbage collector design, and one of the recommendations was that at a GC pause, running mutator threads should cooperate with the collector by identifying roots from their own stacks. You can read a similar assertion in their VEE2005 paper, The Pauseless GC Algorithm, though this wasn't the source of the information.
One motivation for the idea was locality: a thread's stack is already local to a thread. Then specifically in the context of a pauseless collector, you need to avoid races between the collector and the mutator for a thread's stack, and having the thread visit its own stack neatly handles this problem.
However, I am not so interested any more in (so-called) pauseless collectors; though I have not measured myself, I am convinced enough by the arguments in the Distilling the real costs of production garbage collectors paper, which finds that state of the art pause-minimizing collectors actually increase both average and p99 latency, relative to a well-engineered collector with a pause phase. So, the racing argument is not so relevant to me, because a pause is happening anyway.
There was one more argument that I thought was interesting, which was that having threads visit their own stacks is a kind of cheap parallelism: the mutator threads are already there, they might as well do some work; it could be that it saves time, if other threads haven't seen the safepoint yet. Mutators exhibit a ragged stop, in the sense that there is no clean cutoff time at which all mutators stop simultaneously, only a time after which no more mutators are running.
Visiting roots during a ragged stop introduces concurrency between the mutator and the collector, which is not exactly free; notably, it prevents objects marked while mutators are running from being evacuated. Still, it could be worth it in some cases.
Or so I thought! Let's try to look at the problem analytically. Consider that you have a system with N processors, a stop-the-world GC with N tracing threads, and M mutator threads. Let's assume that we want to minimize GC latency, as defined by the time between GC is triggered and the time that mutators resume. There will be one triggering thread that causes GC to begin, and then M-1 remote threads that need to reach a safepoint before the GC pause can begin.
The total amount of work that needs to be done during GC can be broken down into rootsi, the time needed to visit roots for mutator i, and then graph, the time to trace the transitive closure of live objects. We want to know whether it's better to perform rootsi during the ragged stop or in the GC pause itself.
Let's first look to the case where M is 1 (just one mutator thread). If we visit roots before the pause, we have
latencyragged,M=1 = roots0 + graphNWhich is to say, thread 0 triggers GC, visits its own roots, then enters the pause in which the whole graph is traced by all workers with maximum parallelism. It may be that graph tracing doesn't fully parallelize, for example if the graph has a long singly-linked list, but the parallelism with be maximal within the pause as there are N workers tracing the graph.
If instead we visit roots within the pause, we have:
latencypause,M=1= roots0+graphNThis is strictly better than the ragged-visit latency.
If we have two threads, then we will need to add in some delay, corresponding to the time it takes for remote threads to reach a safepoint. Let's assume that there is a maximum period (in terms of instructions) at which a mutator will check for safepoints. In that case the worst-case delay will be a constant, and we add it on to the latency. Let us assume also there are more than two threads available. The marking-roots-during-the-pause case it's easiest to analyze:
latencypause,M=2= delay + roots0+roots1+graphNIn this case, a ragged visit could win: while the triggering thread is waiting for the remote thread to stop, it could perform roots0, moving the work out of the pause, reducing pause time, and reducing latency, for free.
latencyragged,M=2= delay + roots1 + graphNHowever, we only have this win if the root-visiting time is smaller than the safepoint delay; otherwise we are just prolonging the pause. Thing is, you don't know in general. If indeed the root-visiting time is short, relative to the delay, we can assume the roots elements of our equation are 0, and so the choice to mark during ragged stop doesn't matter at all! If we assume instead that root-visiting time is long, then it is suboptimally parallelised: under-parallelised if we have more than M cores, oversubscribed if M is greater than N, and needlessly serializing before the pause while it waits for the last mutator to finish marking its roots. What's worse, root-visiting actually slows down delay, because the oversubscribed threads compete with visitation for CPU time.
So in summary, I plan to switch away from doing GC work during the ragged stop. It is complexity that doesn't pay. Onwards and upwards!
06 Sep 2024 12:15pm GMT
This Week in GNOME: #164 Updated Translations
Update on what happened across the GNOME project in the week from August 30 to September 06.
Philip Withnall says
Thank you to the translation teams for all the translation updates which happen in GNOME, particularly just before a release, like just now. It is really appreciated!
Third Party Projects
Emmanuele Bassi announces
A wild new stable release of Cairo appeared! It's super-effective at fixing build issues and bugs on a variety of platforms and toolchains. Thanks to Federico Mena, Cairo now generates static analysis and coverage reports as part of the CI pipeline; the coverage reports are published, so if you want to contribute to the Cairo project you can now find where your changes can be most effective.
Turtle
Manage git repositories in Nautilus.
Philipp reports
Turtle 0.10 has been released.
There have been a lot of fixes and refactoring, notable changes:
Credential changes
For SSH repos ssh-agent will now be used by default. This makes it easier to use different keys with or without password protection. You can still configure a predefined ssh key in the settings.
It is now possible to use HTTPS repos with username and password. A userpass dialog will prompt for your credentials which can be stored in the gnome keyring. I was not able to test this feature myself, because I do not have access to a repository which allows HTTPS with password. But it seems to work.
File-manager plugin changes
A huge bottleneck, which caused nautilus to freeze up and worst case to crash has been fixed.
Unfortunately I found another issue with the
update_file_info_full
function, which I can reproduce on multiple distros. For the time being the turtle plugin usesupdate_file_info
instead. This makes emblem calculation slower, but at least it runs stable again.There is now a turtle emblem which will be shown for the repo main folder by default. The status emblem can be activated again in the settings. It is also possible to show both or none of them. This change further speeds up emblem calculation in folders with many (100+) repos, especially with the workaround mentioned above, and also makes submodules more visible.
Parabolic
Download web video and audio.
Nick reports
Parabolic V2024.9.0-beta1 is here!
After a long awaited couple of months, Parabolic has been rewritten in C++ and features a redesigned user interface! Users should expect a faster and more reliable downloader.
We encourage all Parabolic users to give this beta a try and iron out all issues before the stable release (targeted for next week).
Here's the full changelog:
- Parabolic has been rewritten in C++ for faster performance
- The length of the kept download history can now be changed in the app's preferences
- Cookies can now be fetched from a selected browser in Preferences instead of selecting a TXT cookies file
- Parabolic's Keyring module was rewritten. As a result, all keyrings have been reset and will need to be reconfigured
- Fixed validation issues with various sites
- Fixed an issue where a specified video password was not being used
- Redesigned user interface
- Updated yt-dlp
Shell Extensions
Cleo Menezes Jr. says
Is it hot in the Northern Hemisphere and cold in the Southern Hemisphere? Weather O'Clock has been ported to GNOME Shell 47! With this new version, it is possible to customize the display of weather information, choosing whether it appears before or after the clock.
Arca says
New updates for the Day Progress extension - circular indicators and GNOME 47!
Day Progress, the extension that lets you visualise how much time is left of your day has now been ported to support GNOME 47! There is now an (experimental) option to display the time elapsed/remaining as a circular ("pie") indicator too. I haven't run into any bugs with the new indicator style in my few days of testing but I'm still hesitant to call it stable, that's why I have labelled it as 'experimental'. You can download the extension at https://extensions.gnome.org/extension/7042/day-progress/ and the repository is available at https://github.com/ArcaEge/day-progress where you can also report any issues you find.
That's all for this week!
See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!
06 Sep 2024 12:00am GMT
04 Sep 2024
Planet GNOME
Arun Raghavan: GStreamer and WebRTC HTTP signalling
The WebRTC nerds among us will remember the first thing we learn about WebRTC, which is that it is a specification for peer-to-peer communication of media and data, but it does not specify how signalling is done.
Or put more simply, if you want call someone on the web, WebRTC tells you how you can transfer audio, video and data, but it leaves out the bit about how you make the call itself: how do you locate the person you're calling, let them know you'd like to call them, and a few following steps before you can see and talk to each other.
While this allows services to provide their own mechanisms to manage how WebRTC calls work, the lack of a standard mechanism means that general-purpose applications need to individually integrate each service that they want to support. For example, GStreamer's webrtcsrc
and webrtcsink
elements support various signalling protocols, including Janus Video Rooms, LiveKit, and Amazon Kinesis Video Streams.
However, having a standard way for clients to do signalling would help developers focus on their application and worry less about interoperability with different services.
Standardising Signalling
With this motivation, the IETF WebRTC Ingest Signalling over HTTPS (WISH) workgroup has been working on two specifications:
- WebRTC-HTTP Ingestion protocol (WHIP)
- WebRTC-HTTP Egress Protocol (WHEP)
(author's note: the puns really do write themselves :))
As the names suggest, the specifications provide a way to perform signalling using HTTP. WHIP gives us a way to send media to a server, to ingest into a WebRTC call or live stream, for example.
Conversely, WHEP gives us a way for a client to use HTTP signalling to consume a WebRTC stream - for example to create a simple web-based consumer of a WebRTC call, or tap into a live streaming pipeline.
With this view of the world, WHIP and WHEP can be used both for calling applications, but also as an alternative way to ingest or play back live streams, with lower latency and a near-ubiquitous real-time communication API.
In fact, several services already support this including Dolby Millicast, LiveKit and Cloudflare Stream.
WHIP and WHEP with GStreamer
We know GStreamer already provides developers two ways to work with WebRTC streams:
-
webrtcbin
: provides a low-level API, akin to thePeerConnection
API that browser-based users of WebRTC will be familiar with -
webrtcsrc
andwebrtcsink
: provide high-level elements that can respectively produce/consume media from/to a WebRTC endpoint
At Asymptotic, my colleagues Tarun and Sanchayan have been using these building blocks to implement GStreamer elements for both the WHIP and WHEP specifications. You can find these in the GStreamer Rust plugins repository.
Our initial implementations were based on webrtcbin
, but have since been moved over to the higher-level APIs to reuse common functionality (such as automatic encoding/decoding and congestion control). Tarun covered our work in a talk at last year's GStreamer Conference.
Today, we have 4 elements implementing WHIP and WHEP.
Clients
whipclientsink
: This is awebrtcsink
-based implementation of a WHIP client, using which you can send media to a WHIP server. For example, streaming your camera to a WHIP server is as simple as:
gst-launch-1.0 -e \ v4l2src ! video/x-raw ! queue ! \ whipclientsink signaller::whip-endpoint="https://my.webrtc/whip/room1"
whepclientsrc
: This is work in progress and allows us to build player applications to connect to a WHEP server and consume media from it. The goal is to make playing a WHEP stream as simple as:
gst-launch-1.0 -e \ whepclientsrc signaller:whep-endpoint="https://my.webrtc/whep/room1" ! \ decodebin ! autovideosink
The client elements fit quite neatly into how we might imagine GStreamer-based clients could work. You could stream arbitrary stored or live media to a WHIP server, and play back any media a WHEP server provides. Both pipelines implicitly benefit from GStreamer's ability to use hardware-acceleration capabilities of the platform they are running on.
Servers
-
whipserversrc
: Allows us to create a WHIP server to which clients can connect and provide media, each of which will be exposed as GStreamer pads that can be arbitrarily routed and combined as required. We have an example server that can play all the streams being sent to it. -
whepserversink
: Finally we have ongoing work to publish arbitrary streams over WHEP for web-based clients to consume this media.
The two server elements open up a number of interesting possibilities. We can ingest arbitrary media with WHIP, and then decode and process, or forward it, depending on what the application requires. We expect that the server API will grow over time, based on the different kinds of use-cases we wish to support.
This is all pretty exciting, as we have all the pieces to create flexible pipelines for routing media between WebRTC-based endpoints without having to worry about service-specific signalling.
If you're looking for help realising WHIP/WHEP based endpoints, or other media streaming pipelines, don't hesitate to reach out to us!
04 Sep 2024 4:35pm GMT
03 Sep 2024
Planet GNOME
Felipe Borges: Looking for more internship project ideas for Outreachy (December-March cohort)
GNOME is interested in participating in the Outreachy December-March cohort, and while we already have a few great projects, we are looking for experienced mentors with a couple more project ideas. Hurry up, we have until September 11 to conclude our list of ideas.
Please, submit project ideas on https://gitlab.gnome.org/Teams/internship/project-ideas
Feel free to message us on #internships:gnome.org (matrix) if you have any doubts.
03 Sep 2024 8:33am GMT