[Task]: Systems Cleanup & Improvement Pass

Checklist

• I am using an up-to-date version.
• I have read the documentation.
• I have searched existing issues.

Description

This task tracks an ongoing systems cleanup pass I'm doing to go in and cleanup, fix, and add miscellaneous improvements to various TagStudio systems.

Over time much of the codebase has become out of alignment with its intended functionality and implementations - especially on the UI side. Anti-patterns have arisen to enforce early practices of mine that were never intended to be canonized, some systems have become neglected or bloated since being introduced, and some systems have fallen into complete disrepair.

I feel that it's very important that I myself take a look at these systems and set them back into alignment to what they should be and how they should operate, not only to fix and improve them for their sake but also to set a proper baseline for how these systems should function. Code should not be built on top of rough systems I added in the initial commit 2 years ago, nor on top of systems that have long outgrown their original purposes or have become a stack of band-aid fixes addressing problems that may not even be relevant anymore.

I'll be working on these at a steady pace over time, but not exclusively. I'll still be giving attention to new features and the ongoing core library changes in addition to what's listed here.

Ordered Tasks

• 0. UI MVC Refactor
  • Necessary to complete first for several items, as many of the ordered tasks touch the UI code which is either currently fragmented or using the older MVC pattern.
  • See #1458 + #1451 for implementation details
• 1. Media Type System
  • Create different mechanisms for file categories that are used for different purposes, such as searching vs. rendering (see comment: https://github.com/TagStudioDev/TagStudio/pull/1430#issuecomment-4898677986)
  • Create translated media type categories for improved searching capabilities
  • Focus on the usability of this system - do not over-complicate it but still provide the expanded functionality outlined above
• 2. Thumbnail/Preview Renderer
  • Split into separate classes and files for each renderer type (would replace #1217)
  • Offload decorative frame rendering and possibly default file icons to Qt instead of using PIL
  • Have previews and thumbnails use alpha channel for backgrounds to support differing window background colors (progress towards #671)
  • Respect current color scheme
  • Try to use Qt paint event to draw constant sized rounded masks for images in the preview panel, relative to the screen instead of the size of the image (e.g. a 12px corner radius will stay 12px when resizing the preview)
• 3. Cache Manager
  • Expand to support caching of large file previews such as RAW images and PDFs (see roadmap item)
  • Support audio waveform caching by storing computed data in text files (see roadmap item)
  • Possibly start using SQLite to store thumbnail locations, as this system is finally expanding beyond its current use
• 4. Resource Manager
  • Allow for arbitrary conversion between formats such as PIL images and QPixmaps
  • Ensure correct return types for resources
  • Move text file resources such as the ts_ignore template to the resource manager
  • Move last of the Qt resources not using this system to here (i.e. thumbnail badges)
• 5. Theming System
  • Complete theming overhaul, using Qt paint events instead of stylesheets or default fusion widgets.
  • Completion of #671

Any Order

• Refreshing/Relinking
  • Enforce a consistent policy for case sensitivity when relinking files
    • Case sensitivity when relinking files should defer to the filesystem that currently hosts the file(s) in question.
    • Edge cases need to be considered for future multi-root libraries that might span across multiple filesystems at once.
    • Resolves #1450
  • Establish and enforce Unicode normalization practices for TagStudio libraries
    • Filenames should be compared against each other normalized forms between the TagStudio database and on-disk files. Form D seems to be the best contender, despite NTFS drives using Form C. This would ensure accurate comparisons in libraries that contain files added across different filesystems, as well as protect against edge cases in future multi-root libraries that could span across different filesystems in a single library simultaneously.
    • Resolves the issues with #1242
• Duplicate File Management
  • Rebuild the duplicate file detection system to use a generic base that can have additional tools supported on top of it, such as dupeGuru, Czkawka, or even in-house solutions.
  • Fix #1196, #1197, #1331, and close #1198
• File Deletion/Trashing
  • Improve UI for deleting files with filenames and visual previews of the files affected while making the whole thing less scary and crusty looking
  • Clear distinction between deleting entries and deleting files, and possibly provide explicit options for either
• Translation Keys
  • Pass through and refactor translation keys to be more consistent