#gnomedesktop — Public Fediverse posts on home.social

René's old blog @[email protected] · 2026-05-05 · 07:46 UTC

Atlantis KD3116 keyboard

Full post here. https://rene.seindal.dk/2026/05/05/atlantis-kd3116-keyboard/

Looking for a compact keyboard with an integrated touchpad, I found the Atlantis KD3616 keyboard.

It is an Italian brand, and I'm not sure if this keyboard is available outside Italy.

What sold it to me, was the promise of three finger gestures on the touchpad, which I use a lot in Gnome, to switch between desktops and open and close the overview.

It does, kind of, but it also doesn't.

#GnomeDesktop #Keyboards #Linux

#gnomedesktop #keyboards #linux

René's old blog @[email protected] · 2025-12-08 · 08:25 UTC

External disk with ext4 doesn’t auto-mount

Full post here. https://rene.seindal.dk/2025/12/08/external-disk-with-ext4-doesnt-auto-mount/

I have an external SSD in a NVME USB enclosure, with an EXT4 file-system. When I plug it in, it doesn't auto-mount, and haven't done so for a while.

Most other external disks do auto-mount.

I finally figured out why, and how to fix it.

#Ext4 #ExternalDisks #GnomeDesktop #Linux #udevRules

#ext4 #externaldisks #gnomedesktop #linux #udevrules

Superdave! @[email protected] · 2025-07-13 · 07:40 UTC

Giving the Tuba fediverse client another go. It's been a while, and I did this in #MateDesktop last time. Let's see how it behaves in #GNOMEDesktop and #OrcaScreenReader V. 4i8.

#matedesktop #gnomedesktop #orcascreenreader

Aptivi @[email protected] · 2025-06-21 · 14:34 UTC

GNOME fixes the Trash bug from 2009!

GNOME Desktop had a bug in the Trash function where the leftover files from the user-wide expunged trash directory, found in ~/.local/share/Trash/expunged, were not being deleted properly, and that the Nautilus file manager, which GNOME uses, inaccurately reported that the trash was empty. This bug was originally reported in Ubuntu’s Launchpad under the title of “Emptying the trash can lead to have files still on disk in expunged.”

This caused problems with the free disk space, since the bug reporter had stated that they had about 70 GB of files in the expunged directory, which were handled incorrectly when emptying the trash. Furthermore, said directory was found in the hidden .local folder underneath your home directory, which was not obvious to the average user. This was said to be due to wrong permissions being applied to the offending files, and a reproducer was found:

mkdir -p test/roottouch test/root/filesudo chown root:root test/root

This followed the two chained rules, first for trashing and second for emptying, where, ipsis verbis:

when a directory A is in a directory owned by you and it’s owned by you, you can obviously move it.
when a directory B is in a directory A owned by you but you don’t own it, and it’s not empty, you can’t delete it.

So, essentially, this boils down to:

The test directory is made by the current user (assume that the current user is aptivi)
The root directory inside the user-owned test directory is made by aptivi
A file, file, which aptivi owned, was created inside the root directory
The root directory’s owner had changed to the root user
The test directory can be moved to aptivi‘s trash, since the first chained rule has been followed
- Explanation: test was owned by aptivi and had a parent directory that was also owned by aptivi
The root directory can’t be deleted from aptivi‘s trash, since the second chained rule has been followed
- Explanation: root, a non-empty directory owned by root, was inside test, owned by aptivi, and the root directory can’t be removed
The root directory can now be found underneath the expunged folder under aptivi‘s .local folder

The appropriate GNOME bug tracker ticket was brought to the upstream developers six years ago from writing who confirmed that the issue was happening. According to this blog post, the merge request was submitted to the GNOME project, which was approved. The fix is now at the upstream GLib code.

An internal function was added to the I/O part of the GLib library, called check_removing_recursively(), that checked whether “subsequently deleting the original file from the trash (in the gvfsd-trash process) will succeed.” It also checked the ownership of the files before deletion and automatically assigned the file mode (chmod) to allow deletion.

That filled one of the TODO tasks in the I/O code that handled emptying the trash in the internal function, g_local_file_trash(). It said “Maybe we should verify that you can delete the file from the trash before moving it? OTOH, that is hard, as it needs a recursive scan.”

Now, you can empty the trash without worrying about the free disk space, but only if your Linux distribution uses a version of GNOME that contains this fix. We expect that this fix will land to several distributions in the coming days or weeks.

Pro tip: to eliminate the remaining expunged files after installing the fixed version of GNOME, use this trick to free up disk space.

#GNOME #GNOMEDesktop #Linux #LinuxDesktop #news #Tech #Technology #Trash #TrashBin #update

#gnome #gnomedesktop #linux #linuxdesktop #news #tech

Syd @[email protected] · 2025-01-01 · 13:52 UTC

between space time I worked on my folder icon thumbnailer for nemo and nautilus file roller (and I think thunar can read it too) #GnomeDesktop #XFCE #MATEDesktop

( I have yet to submit it. Old version is till here: https://github.com/Sythelux/thumbnailers/ )

#gnomedesktop #xfce #matedesktop

Wizards Anonymous @[email protected] · 2024-12-04 · 21:46 UTC

A new #cat #video on #PureOS 10.3 with the #GnomeDesktopEnvironment https://youtu.be/AUv2gRbixUo developed by Purism has been #performance #benchmarked on https://everybytecounts.org. While it performs better than #Zorin with #Gnome, it does not perform as well as #AlpineLinux with #GnomeDesktop. PureOS 10.3 was released in June #2023 and bundled with Gnome Desktop Environment from #2021, #Mutter from 2021, and #GDM from #2020, which is not recommended.