Apparently, Prism Launcher chose to adhere to the idiotic principle of the hidden “trashbin”, .Trash-$(uid), invented by Ubuntu. Even though it’s based on QT. This can’t be disabled. It accumulated 139 GB of literal Trash, fully replaceable, over time. Just … why? There’s even an open issue about this, for over a year, referenced multiple times. I guess I have another point on my agenda.

  • d_k_bo@feddit.org
    1·
    1 month ago

    the hidden “trashbin”, .Trash-$(uid), invented by Ubuntu

    This isn’t some “idiotic principle invented by Ubuntu”, it just follows the freedesktop.org Trash specification. For many users, it can be really beneficial, see also the spec’s introduction:

    An ability to recover accidentally deleted files has become the de facto standard for today’s desktop user experience.

    Users do not expect that anything they delete is permanently gone. Instead, they are used to a “Trash can” metaphor. A deleted document ends up in a “Trash can”, and stays there at least for some time — until the can is manually or automatically cleaned.

    Whether an application like Prism Launcher should use the trash can or delete the files directly is an entirely different question.

    • theshatterstone54@feddit.uk
      1·
      1 month ago

      But why wouldn’t they use .local/share/Trash instead? Isn’t that supposed to be a unified directory for that very purpose?

      • cmnybo@discuss.tchncs.deEnglish
        0·
        1 month ago

        Because that would take a long time if you deleted a large file in another partition or drive. You could also end up not having enough space to move the file to trash and if the trash directory is on an SSD, it would add a lot of unnecessary wear to it.

        • d_k_bo@feddit.org
          1·
          1 month ago

          To explain it a bit further: when you move a file/directory on the same mount point, moving the file/directory is essentially just a rename operation, which doesn’t involve copying the data itself and is a very cheap operation. If you move a file/directory across mount points, you need to (recursively) copy the file/directory, copy file metadata and (recursively) delete the old file/directory, which is slow and error-prone.