I cannot express how cool this is. This is the first time I’m running Graphs on a mobile phone, and it just works. Quite nicely as well.
#GNOME and #libadwaita has really made it very easy to make your apps adaptive and behave nice on mobile phones. This is really powerful stuff. So many applications work really nicely on #PostMarketOS.
If there is one thing LLMs with tool calling are excellent at, it's updating dependencies/fixing deprecations. Moved Senbara from the old #GTK shortcuts dialog to the new one in like 60s with a single prompt; despite the training data being from before that was even a #libadwaita component, and it even managed to use the new automatic resource loader properly.
Over November 2025, I've been able to contribute to
@gnome, and it was a pleasure!
I focused on GNOME Clocks, with the goal of making it as good as possible for GNOME 50. I focused on #accessibility, #linuxmobile and all sorts of bug fixes and features, as well as issue and MR triaging.
I also fixed some tiny issues in #GTK and #libadwaita, and helped make gettext-pseudolocale as good as possible.
I hope to find more free time to make GNOME Clocks 50 dependable as a mobile clocks app.
Finally got momentum on the redesigned I planned for Maps for GNOME 50, redesigning the sidebar a bit (taking a bit inspiration from Nucleus) with the aim of ultimatly it use an AdwMultiLayoutView using a bottom sheet in narrow/mobile mode. And showing place info in there as well…
Right now in a state of a bit "first break it, then fix it"… 😄
#Phosh's file selector (pfs) picked up existing 👍-nails of files since some time but didn't create missing ones. @arunmanij fixed that by creating a thumbnailing service. The file chooser calls into this service to request the creation of the missing thumbnails.
Having things in an extra service allows us to experiment with different implementations (it currently uses GnomeDesktopThumbnail under the hood) and also to sandbox things further if desired. Since pfs is used by our portal implementation all apps using it (including #flatpak s) will leverage that automatically.
It's one the historical GNOME games, but thanks to Mat's modernization work over the past few cycles it looks very fresh and clean nowadays. Welcome :)
Sharepic with the Mahjongg app icon on green background and the GNOME Circle logo in the bottom right. The app icon consists of three Mahjongg tiles with different symbols on them, stacked in a pyramid shape.
I've been running #Linux for almost as long as I've been using computers, and I've tried and customized many different things, but nowhere else have I felt that excitement that stock #GNOME can give nowadays.
Screenshot of a stock GNOME desktop on Fedora, featuring the light styled top bar and one of the Pride Month wallpapers. On top of it there is a route plan in the Maps app, a website showing beautiful public domain images, and a song with a colorful album cover playing in the Amberol music player.
As part of our volunteer-driven accessibility initiative in GNOME Calendar, and for the first time in the 10+ years of Calendar's existence, we finally completed and merged the first step needed to have a working calendar app for people who rely on keyboard navigation. This merge request in particular makes the event widgets focusable with navigation keys (arrow left/up/right/down) and activatable with space/enter. This will be available in GNOME 49.
Most of GNOME Calendar's layout and widgets consist of custom widgets and complex calculations, both independently and according to other factors (window size, height and width of each cell, number of events, positioning, etc.), so these widgets need to be minimal to have as little overhead as possible. This means that these widgets also need to have the necessary accessibility features reimplemented or even rethought, including and starting with the event widgets.
During the past few weeks, there's been an overwhelming amount of progress with accessibility on GNOME Calendar:
• Event widgets/popovers will convey to screen readers that they are toggle buttons. They will also convey of their states (whether they're pressed or not) and that they have a popover. (See !587)
• Calendar rows will convey to screen readers that they are check boxes, along with their states (whether they're checked or not). Additionally, they will no longer require a second press of a tab to get to the next row; one tab will be sufficient. (See !588)
• Month and year spin buttons are now capable of being interacted with using arrow up/down buttons. They will also convey to screen readers that they are spin buttons, along with their properties (current, minimum, and maximum values). The month spin button will also wrap, where going back a month from January will jump to December, and going to the next month from December will jump to January. (See !603)
• Events in the agenda view will convey to screen readers of their respective titles and descriptions. (See !606)
Accessibility on Calendar has progressed to the point where I believe it's safe to say that, as of GNOME 49, Calendar will be usable exclusively with a keyboard, without significant usability friction!
There's still a lot of work to be done in regards to screen readers, for example conveying time appropriately and event descriptions. But really, just 6 months ago, we went from having absolutely no idea where to even begin with accessibility in Calendar — which has been an ongoing issue for literally a decade — to having something workable exclusively with a keyboard and screen reader! :3
Huge thanks to
@nekohayo for coordinating the accessibility initiative, especially with keeping the accessibility meta issue updated; Georges Stavracas for single-handedly maintaining GNOME Calendar and reviewing all my merge requests; and @tyrylu for sharing feedback in regards to usability.
All my work so far has been unpaid and voluntary; hundreds of hours were put into developing and testing all the accessibility-related merge requests. I would really appreciate if you could spare a little bit of money to support my work, thank you 🩷
After two weeks of writing, revising, and trying to make everything as digestible as possible, I finally published "GNOME Calendar: A New Era of Accessibility Achieved in 90 Days", where I explain in detail the steps we took to turn GNOME Calendar from an app that was literally unusable with a keyboard and screen reader to an app that is (finally) accessible to keyboard and screen reader users as of GNOME 49!
After two long and painful years, several design iterations, and more than 50 rebases later, we finally merged the infamous, trauma-inducing merge request !362 on GNOME Calendar.
The calendars list in the quick-add popover has undergone accessibility improvements, providing a better experience for assistive technologies and keyboard users (to a limited extent). Specifically: tabbing from outside the list will focus the selected calendar in the list; tabbing from inside the list will skip the entire list; arrow keys automatically select the focused calendar; and finally, assistive technologies now inform the user of the checked/selected state.
Admittedly, the quick-add popover is currently unreachable via keyboard because we lack the resources to implement keyboard focus for month and week cells. We are currently trying to address this issue in merge request !564, and hope to get it merged for GNOME 50, but it's a significant undertaking for a single unpaid developer. If it is not too much trouble, I would really appreciate some donations, to keep me motivated to improve accessibility throughout GNOME and sustain myself: https://tesk.page/#donate
Do note that the screen recording attached won't have any alt text, to avoid redundancy. Everything written below is a detailed explanation of the experience, and the recording is essentially a visual demonstration:
When entering the month view with Tab, focus is set to the first event widget, and pressing Tab will focus the next event widget horizontally.
Ctrl+Tab will move focus to the month cell located at the focused event widget. Ctrl+Arrow will move focus to the edges of the view.
When out of boundaries horizontally, the focus moves onto the other side of the view.
When out of boundaries vertically, the view will automatically scroll to that direction.
Shift+Arrow will move focus and initiate selection; pressing arrow keys will select ranges of cells, and letting go of Shift will display the new event popover.
When a month cell has overflowing events (as in, there are not enough event widgets that can fit inside the month cell), pressing tab will focus the overflow button, and activating it will show a list of events.
Since Upscaler has just reached 150,000 installs on Flathub, I'm releasing Upscaler 1.5.0! Upscaler is an app that allows you to upscale images locally, securely, and completely offline.
Thanks to
@zoeyTheWitch's wonderful contribution, this release introduces the long overdue functionality to load multiple images at once and add them to the queue. This avoids having to load and add each image to the queue, which will significantly speed up the process of adding images to the queue.
The entire async and threading model was ported to the asyncio and threading modules, thanks to the long awaited (pun very much intended) asyncio integration in PyGObject that was made available recently.
Loading images has become much faster and smoother, while using less memory as a direct result of the asyncio and threading port.
This release also makes saving the resulting images completely optional. Additionally, there is now a copy button to copy images without saving them. As such, the process to upscale images has gotten more straightforward than ever – just load the image, set the desired scaling factor and the image type.
The progress rows have gotten a redesign to make them more reminiscent to typical rows with progress bars.
Praca nad apką idzie dalej, oto drobne demko tego, co mam zrobione do tej pory. Mam sporo rozmaitych bugów, w oczy rzucają się brakujące ikony (podejrzewam, że może to kwestia uprawnień flatpaka?) czy muszę coś zrobić z pobieraniem filmów, bo o ile na tym filmiku wszystko ładnie działa, to filmy z różnych instancji działają... Różnie. Nie pokazuję też tutaj tube.pol.social z tego względu, że API nie zwraca mi streamingPlaylists z listą streamków .m3u8 w różnej rozdzielczości, żebym mógł ładnie odtwarzać dany film, gdzie jak testuję API w przeglądarce, to wszystko działa, zatem nie wiem, dlaczego mojemu klientowi tego nie zwraca. Jeżeli uda mi się skończyć pierwszą działającą wersję apki z pobieraniem feeda, prostym wyszukiwaniem i odtwarzaniem filmów z wybranej przez użytkownika instancji, to udostępniam apkę i jej kodzik do testowania oraz wrzucam filmik z jej pokazówką (może się przy okazji otworzę i zamienię z dwa słowa :P) #linux#development#python#gnome#gtk#libadwaita#peertube
Finally managed to get #OIDC post-login redirects to specific "URLs" (well, #libadwaitaNavigationView tags, to be precise) to work. That was quite a bit more complex than I expected it to be!
Stworzenie własnej apki GNOME na Linuxie jest prostsze niż myślałem. Pobrałem sobie przedwczoraj GNOME Buildera, parę kliknięć i mam gotowe środowisko do pisania apki w Pythonie i budowania Flatpaka i od wczoraj robię własnego klienta PeerTuba. Kiedyś dłubałem w Gtk3 w C, jak chodzi o Pythona, Gtk4 i Libadwaitę to jestem zielony i robię to na czuja, ale jest taka apka, jak Workbench z masą gotowców, z których mogę sobie czerpać (bo niestety na ChacieGPT nie mogę zbytnio polegać, bo jest głupiutki xD). Teraz mam zrobione okienko z dynamicznym wczytywaniem filmów z infinite scrollem. Nie wiem, jak uda mi się ze zrobieniem odtwarzacza filmów, będę kombinował dalej :P #libadwaita#python#linux#peertube#gnome#gtk#gtk4
Zrzut ekranu przedstawiający prototyp aplikacji klienckiej dla platformy PeerTube, widoczne małe okno z siatką filmów oraz pod nią ikonka wczytywania kolejnych filmów.
@dansup@vidzy hmm I've been learning #Rust & want to start a project I can list on my resume before applying to Rust jobs.
Was thinking a #Fediverse#GTK / #Libadwaita client would be perfect. Was leaning toward #Lemmy since the backend is also Rust, but the UI for that would be more complex & is daunting for my zero exp w/ UI (outside of React)
#Loops would probably need a lot less UI complexity, so maybe I'll make that instead.
Introducing Refine, an app to tweak advanced and experimental settings in GNOME. It is an alternative to GNOME Tweaks, and is a pet project I'm currently working to experiment with PyGObject and dconf, while following the data-driven, object-oriented, and composition paradigms.
The entire codebase is made up of widgets that provide all the functionality needed to add an option. For example, instead of adding each option programmatically in Refine, the ultimate goal is to have it all done in the UI file.
For example, if we want to add an option to enable or disable middle click paste, all we need is the following code in the UI file:
That's it. The RefineSwitchRow widget will do whatever it needs to do to ensure the option is available, grab the setting if it's available, and display it to the user. Many of these widgets provide extra functionality, such as a Reset button.
Introducing Refine 0.5.0, the GNOME Tweaks alternative leveraging the data-driven and composition paradigms. This version re-adds the Document font option, and renames "Middle Click Paste" to "Middle Click to Paste Text" with an accompanying subtitle.
Thanks to @CodedOre, 0.5.0 also adds the capability to rearrange the titlebar's window buttons. This new feature also lets you add the minimize and maximize buttons.
While we thoroughly tested right-to-left (RTL) direction and keyboard navigation with a screen reader, it's worth noting that we're no experts. We welcome feedback from those who use Refine in RTL and/or with a keyboard and screen reader.
"Linux Mint Theme Updates Theming and Reconsiders libAdwaita"
https://scribe.disroot.org/pictrs/image/7067557b-4760-4e59-ab68-a765003d2fdf.jpeg ...