Items tagged with: freedesktop

Search

Items tagged with: freedesktop


Now that the storm has passed — I can share an update on screen reader support under Wayland.

As part of STF; GNOME has been working since the end of last year on resolving the matter.

The main issue is that we currently lack a way to “snoop on” or “grab” key events from the compositor.

We now have a draft protocol and implementation in Orca and Mutter thanks to @matt

We are doing our best to get it ready for GNOME 47.

#GNOME #a11y #Linux #freedesktop #Wayland


If you are a #GNOME / #freedesktop module maintainer and would like your module to join the pilot program; please get in touch.


Here's my latest update on Newton, the #Wayland-native, #Flatpak-friendly #accessibility project for the modern #FreeDesktop ecosystem, developed as part of @gnome and funded by @sovtechfund. It's not ready for production yet, but this blog post includes a demo video and links to GNOME OS and Flatpak runtime builds you can try. As a bonus, because I'm integrating #AccessKit into #GTK, GTK apps will finally have #a11y on Windows and macOS. blogs.gnome.org/a11y/2024/06/1…


Interested in tooling for development and QA on immutable / image based Linux?

Checkout discourse.gnome.org/t/towards-… by @tchx84

Feedback welcome ! This is a collaboration between @gnome @codethink and @sovtechfund ❤️

#Linux #systemd #Silverblue #GNOME #freedesktop #KDE #Ubuntu #SUSE #Fedora #NixOS #postmarketOS







Version 1.2.0 of the xdg-utils is out! :drgn_box:

Please test them! (But don't deploy yet)

Thank you to everyone else who contributed and thanks to Simon for the trust and maintainer work! :drgn_heart:


We need more eyes on that code! :drgn_notice:

The xdg-utils are children of their time, shellscripts that by large don’t follow a “modern” scripting style …

… which means that there is a lot of work to catch up on and any changes should be reviewed by more people than they currently are.
In case you want to help:
Just pick something that seems interesting and doable for you and open an issue/merge request.

Things that need to be done:

  • Read the code and try to find mistakes (Usage of external tools, escaping, …)
  • Find mistakes in open merge requests.
  • Review, research and fix issues.
  • Improve tests
  • Improve documentation
  • Rebase old merge requests
  • Improve Cygwin and MacOS support
  • etc.

:neofox_solder: :neocat_science: :drgn_wrench:

#freedesktop #xdg #xdgUtils #xdg_utils #linux

And while I’m at it i might also hijack #fosdem for this. :drgn_dark_mlem:




Building and coordinating a team to support the GNOME project is one of the most fulfilling job I've had.

I find these are some of the biggest challenges

• Lots of people and organizations to coordinate with 🗺️
• Some projects are cans of worms 🥫🐛
• So many things to do 🏃

But it's very rewarding and everyone is brilliant and passionate.

I think I'll start sharing more personal updates on our efforts

Context foundation.gnome.org/2023/11/0…

#Linux #GNOME #accessibility #freedesktop #a11y




Tl'dr #rustlang is a great collaboration opportunity for @gnome and @kde.

A long long time ago, #freedesktop initiative was created for precisely this goal. While in many ways it was a success story (especially in terms of establishing standards), it came short in one specific aspect: code collaboration.

Most freedesktop (all?) projects were and are almost exclusively developed and maintained by GNOME folks. That's not very surprising, given that C (being that lowest common denominator) had to be the programming language of choice. Just like most GNOME folks wouldn't want to touch C++, KDE folks don't particularly enjoy coding in C either. I know both have their reasons and the point here is not to play the blame game here.

There is not much point in dwelling in the past here but if we decide to write all future infrastructure/non-UI projects (that would have otherwise been written in C or C++) in Rust, there's a great potential for collaboration, I believe.

Talk is cheap, you could say and I agree. Hence why I've taken some steps in this direction already: github.com/dbus2/