0% found this document useful (0 votes)
4 views21 pages

Python Report Wasfa

The document details the design and implementation of the Smart Storage Manager, a multilingual desktop application aimed at analyzing and organizing files on Windows systems. It addresses common file management issues by integrating features such as recursive file analysis, duplicate detection, and user-friendly visualization in multiple languages. The application is built using Python and CustomTkinter, ensuring responsiveness and safe file operations while allowing for easy deployment as a Windows executable.

Uploaded by

wasfa0011
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views21 pages

Python Report Wasfa

The document details the design and implementation of the Smart Storage Manager, a multilingual desktop application aimed at analyzing and organizing files on Windows systems. It addresses common file management issues by integrating features such as recursive file analysis, duplicate detection, and user-friendly visualization in multiple languages. The application is built using Python and CustomTkinter, ensuring responsiveness and safe file operations while allowing for easy deployment as a Windows executable.

Uploaded by

wasfa0011
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Design and Implementation of a Multilingual​

Smart Storage Manager for Desktop File Analysis​


and Safe File Organization

Report

Student Name: Wasfa Zulfiqar


Student ID: P20252733
Major: Instrument Science and Technology
College: Metrology Measurement and Instrument

Instructor: 沈超 (Charles)
Course: Python Programming
Submission Date: July 6, 2026
Table of Contents

Abstract 1

1. Introduction 2

2. Related Technologies and Design Basis 3

3. Research Methodology and System 5


Requirements

4. System Architecture and Data Flow 7

5. Algorithm Design and Implementation 9

6. Interface Design, Visualization, and 12


Internationalization

7. Experimental Evaluation and Results 14

8. Discussion 16

9. Conclusion and Future Work 17

References 18

Appendix A. Codebase Structure and Metrics 19


Abstract

This paper presents the design, implementation, and evaluation of Smart Storage Manager, a
multilingual Windows desktop application developed to analyze local storage and safely organize files.
The work addresses a common practical problem: folders accumulate mixed documents, images,
media, source code, archives, programs, duplicates, and empty files, while ordinary users often lack a
clear view of what occupies storage or how files can be reorganized without accidental loss. The
proposed application integrates recursive file-system analysis, extension-based classification, large-file
ranking, zero-byte-file detection, content-hash duplicate identification, organization preview,
reversible file movement, report generation, activity logging, search, sorting, pagination, data
visualization, and persistent settings in one graphical environment. The interface was implemented in
Python using CustomTkinter and ttk, with Matplotlib embedded for graphical storage summaries.
Long-running file operations are executed in background threads, while a synchronized queue returns
results to the Tk event loop to preserve responsiveness and safe widget updates. The interface supports
English, Chinese, Urdu, and Russian, including right-to-left alignment for Urdu, together with Day,
Night, and Cute appearance modes. Functional testing confirmed successful operation of analysis,
detection, preview, organization, undo, reporting, localization, and folder-based Windows executable
deployment. The project demonstrates that a modular Python desktop system can combine file
analysis, visualization, internationalization, and cautious file management within a practical
user-oriented tool.
Keywords: Python; desktop application; file-system analysis; duplicate detection; file organization;
CustomTkinter; internationalization; PyInstaller

1
1. Introduction
1.1 Background
Personal computers increasingly store academic materials, downloaded files, images,
videos, programming projects, compressed archives, installation packages, and temporary
content in the same folders. As the number of files grows, users may not know which file
types consume the most space, whether duplicate copies exist, which files are empty, or how
the folder can be reorganized. Manual inspection is slow and error-prone because file size,
type, modification date, and content identity must be considered separately.

Operating systems provide general file browsing and storage settings, but they do not
always offer an integrated, transparent workflow that combines local folder analysis, visual
summaries, duplicate comparison, safe organization preview, undo, report generation, and
multilingual interaction. This creates a need for a focused desktop application that presents
file-system information in a form that is understandable to non-specialist users.

1.2 Problem Statement


The research problem is how to design a desktop file-management application that can
inspect a user-selected folder, summarize its contents, identify potentially important files, and
organize top-level files while maintaining responsiveness, reversibility, and usability. The
solution must avoid permanent deletion, provide feedback during lengthy operations, support
users with different language preferences, and operate as a Windows executable outside the
development environment.

1.3 Research Questions


1.​Can recursive file analysis, duplicate detection, visualization, and organization be
integrated into one coherent desktop workflow?
2.​How can time-consuming file operations be performed without freezing the graphical
interface?
3.​How can multilingual and right-to-left interface behavior be incorporated without
duplicating the application logic?
4.​Can the resulting Python program be packaged as a deployable Windows application
while preserving required resources?
1.4 Objectives and Contributions
The project was developed with the following objectives:

●​Analyze total file count, total storage usage, category distribution, and detailed metadata.
●​Identify large files, duplicate files, and empty files using transparent algorithms.

2
●​Provide a preview-before-action organization model and an undo mechanism.
●​Visualize storage results with dashboard cards, charts, tables, and activity history.
●​Support English, Chinese, Urdu, and Russian interfaces, including Urdu right-to-left
alignment.
●​Preserve application responsiveness through background tasks and safe main-thread
updates.
●​Package the completed program as a Windows executable using PyInstaller.
The principal contribution is an integrated, modular desktop system that treats storage
analysis and file organization as a controlled sequence: inspect, explain, preview, act, and
record. Unlike a simple file mover, the application combines analysis and user feedback with
reversible operations and persistent state.

2. Related Technologies and Design Basis


2.1 Python Desktop Interface Technologies
Tkinter is Python's standard interface to the Tcl/Tk graphical toolkit [1]. It provides the
event loop, geometry management, dialogs, themed widgets, and message boxes required by a
desktop application. CustomTkinter extends this foundation with modern, customizable
widgets and appearance modes [2]. In Smart Storage Manager, CustomTkinter is used for the
main window, frames, labels, buttons, menus, progress indicators, text boxes, and secondary
windows, while [Link] is used for the interactive Top Files table.

The interface follows a single-main-window model. One CTk root window owns the
application and runs one mainloop, while secondary dialogs such as Settings and Activity
History are implemented as child windows. This arrangement simplifies event handling and
prevents competing GUI loops.

2.2 File-System Operations


Python's os module provides portable operating-system interfaces and path operations [3].
The application uses [Link] to traverse subfolders recursively, [Link] functions to inspect
size and modification time, and [Link] to process top-level files during organization. The
shutil module supplies high-level movement operations; [Link] is used both for
organization and for reversing the most recent operation [4].

The design separates recursive analysis from top-level organization. Recursive scanning
gives a complete picture of folder contents, whereas top-level organization avoids
unexpectedly moving files from deeply nested project structures. This distinction reduces risk
and keeps the action easy to explain.

3
2.3 Hash-Based Duplicate Detection
Duplicate detection is based on content hashes. Python's hashlib module provides a
common interface to message-digest algorithms, including MD5 [5]. Each non-empty file is
read in 4096-byte blocks and the resulting digest is used as a dictionary key. When a digest
already exists, the later file is recorded as a duplicate of the first file. MD5 is used here only
as a practical content-comparison identifier; it is not presented as a security or integrity
mechanism.

2.4 Visualization, Threads, and Packaging


Matplotlib can be embedded directly in Tk interfaces through the TkAgg backend [8].
The application uses this capability to render category summaries and detailed charts inside
the dashboard. Python threads are used for I/O-bound tasks such as scanning and hashing [6].
A synchronized queue transfers completed work back to the main UI thread [7], ensuring that
Tk widgets are updated only from the event loop.

PyInstaller analyzes a Python entry script and collects the modules and runtime files
needed to execute the application [9]. Folder-based and one-file packaging modes are
available [10]. The project used a folder-based build first because it is easier to diagnose and
because the executable depends on its accompanying internal runtime files.

Table 1. Technology stack and purpose.

Technology Role in the project Reason for selection

Readable syntax, standard-library


Python Application logic and file processing
support, rapid development

Consistent dashboard appearance and


CustomTkinter Modern GUI widgets and themes
theme control

Tkinter/ttk Event loop, dialogs, Treeview table Standard Python GUI foundation

Direct Tk integration and flexible


Matplotlib Embedded storage charts
plotting

os / pathlib Folder traversal and metadata Portable file-system access

shutil Move and restore files High-level movement operations

hashlib Duplicate-file fingerprints Block-based content hashing

Responsive processing and safe UI


threading / queue Suitable for I/O-bound scanning
transfer

json / text logs Persistent settings and activity history Simple, transparent local storage

4
Technology Role in the project Reason for selection

Bundles Python application and


PyInstaller Windows executable packaging
dependencies

3. Research Methodology and System Requirements


3.1 Development Method
An iterative engineering methodology was adopted. The project began with a functional
file-analysis backend, followed by a basic Tkinter interface. Features were then added and
tested in small stages: dashboard cards, charts, Top Files, status feedback, recent activity,
quick actions, sidebar storage information, settings, multilingual support, Urdu right-to-left
behavior, search, pagination, interactive file opening, compact advanced details, robust
background tasks, shutdown management, and executable packaging. This incremental
process reduced the number of simultaneous changes and made errors easier to isolate.

Each development cycle followed five steps: define a user-visible requirement,


implement the supporting backend or interface component, run the program in the Anaconda
environment, verify the feature with a small folder, and correct integration or deployment
problems before proceeding.

3.2 Functional Requirements


Table 2. Functional requirements.

ID Requirement Implemented behavior

User selects a local folder through a


FR1 Folder selection
standard dialog.

Counts files and totals sizes by category


FR2 Storage analysis
recursively.

FR3 Large-file detection Ranks non-empty files by size.

Compares content hashes and returns


FR4 Duplicate detection
duplicate pairs.

FR5 Empty-file detection Finds zero-byte files.

Shows source and destination before any


FR6 Organization preview
movement.

Moves top-level files by category and


FR7 Organization and undo
restores the latest move set.

5
ID Requirement Implemented behavior

Displays cards, category overview,


FR8 Visualization
detailed charts, and Top Files.

Filters table data and supports sortable


FR9 Search and sorting
columns and pagination.

Writes a structured storage_report.txt


FR10 Reporting
file.

Supports English, Chinese, Urdu, and


FR11 Internationalization
Russian.

Builds a Windows executable with


FR12 Deployment
required dependencies.

3.3 Non-Functional Requirements


Table 3. Non-functional requirements.

Requirement Design response

Dashboard layout, clear grouping, immediate status


Usability
feedback, and disabled controls until valid.

No permanent deletion; preview-before-move; undo for the


Safety
latest organization action.

Background threads for long I/O tasks and a queue for safe
Responsiveness
UI completion callbacks.

Exception handling for missing, protected, and inaccessible


Reliability
files.

Separate modules for GUI, backend tools, translations,


Maintainability
paths, and program entry.

Python standard-library file operations and


Portability
PyInstaller-based Windows deployment.

Central translation dictionary and language-aware layout


Internationalization
functions.

Settings and activity logs stored in a writable AppData


Persistence
folder.

3.4 Evaluation Method


Evaluation focused on functional correctness, interface responsiveness, reversibility,
localization, and deployment. A controlled folder was used to verify categories, file sizes,

6
empty files, duplicate pairs, preview destinations, moved files, and restoration. Interface
features were checked across the three themes and four languages. The executable build
process was verified by successfully producing a Windows folder-based application. Failures
encountered during development were treated as test evidence and led to corrective changes in
imports, environment selection, thread-to-UI communication, and PyInstaller module
exclusions.

4. System Architecture and Data Flow


4.1 Layered Architecture
The application is divided into four logical layers. The presentation layer contains the
dashboard and receives user commands. The processing layer performs scanning,
classification, hashing, organization, and report generation. The data-and-state layer stores
selected-folder information, analysis results, settings, activity records, and undo history. The
deployment layer provides the entry point and packaged Windows runtime.

Figure 1. Layered architecture of Smart Storage Manager.

4.2 Module Responsibilities


Table 4. Principal modules and responsibilities.

Module Main responsibility

Creates the CTk root window, constructs the GUI object,


[Link]
runs the event loop, and performs final cleanup.

7
Module Main responsibility

Implements the dashboard, themes, translations, event


[Link] handlers, charts, tables, settings, threads, and lifecycle
management.

Implements categorization, analysis, large-file ranking,


file_tools.py hashing, duplicate and empty-file detection, organization,
undo, reporting, and logging.

Stores translated labels and messages for English, Chinese,


[Link]
Urdu, and Russian.

Returns writable AppData paths for settings and activity


app_paths.py
history in source and packaged execution.

4.3 Operational Workflow


The end-to-end workflow begins with folder selection. Recursive scanning produces
category and metadata records. Analysis results are visualized and stored in memory. The user
may then inspect large, duplicate, or empty files; preview organization; move files; undo; or
generate a report. Settings and activity entries are saved outside the executable's installation
directory so that they remain writable after packaging.

Figure 2. Operational workflow from folder selection to persistent results.

4.4 State and Control Model


The GUI maintains the selected folder, analysis data, large-file list, duplicate pairs, empty
files, preview list, moved-file history, report path, table rows, sort mode, search text, page
number, language, theme, and busy/closing flags. Buttons are enabled or disabled according

8
to this state. For example, analysis-dependent controls remain disabled before folder
selection, and Undo remains disabled until files have actually been moved.

A centralized state-update method applies these rules consistently. This prevents


conflicting commands, such as starting a new scan while another background operation is
active.

5. Algorithm Design and Implementation


5.1 Recursive Storage Analysis and Classification
The function analyze_storage(folder_path) initializes counters for Images, Videos,
Documents, Music, Archives, Programs, Code, and Others. [Link] recursively visits every
accessible file. The extension determines the category, while [Link] provides the byte
count. Category counts and sizes are accumulated together with global totals. Generated
report files are skipped to prevent the application from repeatedly analyzing its own output.

Algorithm 1. Recursive storage analysis.

initialize count and size for each category​


for each file found by recursive traversal:​
skip application-generated report files​
read file size and determine category from extension​
increment category count and category size​
increment total file count and total size​
return category data, total files, total size

5.2 Large Files, Empty Files, and Top Files


Large-file detection collects non-empty file paths and sizes, sorts them in descending
order, and returns the configured limit. Empty-file detection tests whether the size is zero and
stores the path separately. The Top Files table uses a richer metadata structure containing
name, category, size in bytes, formatted size, folder, modification timestamp, formatted date,
and full path.

The table supports text search across names, categories, folders, dates, and formatted
sizes. Sorting can be performed through an option menu or by clicking a column heading.
Pagination limits the number of displayed rows and reduces visual overload.

5.3 Duplicate Detection


The duplicate detector reads each non-empty file in 4096-byte blocks and updates an
MD5 digest. A dictionary maps each digest to the first file that produced it. If the same digest

9
appears again, the original path and the later path are returned as a duplicate pair. Empty files
are excluded because they are reported separately and would otherwise all share the same
digest.

Algorithm 2. Hash-based duplicate detection.

hashes = empty dictionary​


duplicates = empty list​
for each non-empty file:​
digest = MD5(file content read in 4096-byte blocks)​
if digest already exists:​
append (first path, current path) to duplicates​
else:​
store current path under digest​
return duplicates

The approach is practical because equal content produces the same digest under normal
operation. However, MD5 is not collision-resistant for security applications. A future version
could first group files by size and then use SHA-256 for stronger verification.

5.4 Preview, Organization, and Undo


preview_organization inspects top-level files and calculates the category folder that
would receive each file. It performs no movement. organize_files creates missing category
folders and moves a file only when the destination path does not already exist. Each
successful move is recorded as an (old_path, new_path) pair. undo_organization processes
this list in reverse order and restores files when the new path exists and the original path is
free.

Algorithm 3. Reversible organization.

preview: map each top-level file to its category folder​


after user confirmation:​
create category folder when necessary​
move file only if destination does not already exist​
record original and destination paths​
undo: traverse recorded moves in reverse and restore each file

This design emphasizes reversible file management. The application does not
permanently delete files. Reversal is limited to the latest in-memory move set, which is
sufficient for the current session but remains a limitation for long-term recovery.

10
5.5 Background Processing and Thread-Safe UI Updates
Folder scanning, hashing, and report preparation may take noticeable time. If they run
directly in the Tk event loop, the interface stops repainting and appears frozen. The
application therefore starts these tasks in daemon worker threads. Workers never modify
widgets directly. Instead, they place completion functions in a queue. A short, tracked after
callback running on the main thread removes queued functions and applies results safely.

The lifecycle design also tracks pending after identifiers. During shutdown, pending
callbacks are cancelled, the progress animation is stopped, child windows and chart canvases
are destroyed, and the root window is closed. This corrected the invalid-command errors that
occurred when Spyder destroyed a window while delayed callbacks were still scheduled.

5.6 Report Generation and Persistent Application Data


generate_report writes a text report containing the selected path, date, total file count,
total size, duplicate count, empty-file count, category statistics, large files, duplicate pairs, and
empty-file paths. write_log appends timestamped activity entries. [Link] stores interface
preferences such as language, theme, row limits, and confirmation behavior. app_paths.py
places these writable files in the user's local application-data directory, which remains valid
after PyInstaller packaging.

Table 5. Algorithmic complexity.

Operation Approximate complexity Main cost

Storage analysis O(N) Metadata access for N files

Large-file ranking O(N log N) Sorting file-size records

Empty-file detection O(N) Size checks

Reading B total bytes plus dictionary


Duplicate detection O(B)
lookup

Table search O(K) Filtering K loaded metadata records

Table sorting O(K log K) Sorting filtered rows

Organization O(M) Moving M top-level files

Undo O(M) Restoring the recorded move set

11
6. Interface Design, Visualization, and Internationalization
6.1 Dashboard Structure
The interface uses a left sidebar for folder selection and task groups, together with a
scrollable main dashboard. Five summary cards show total files, total size, duplicates, empty
files, and large files. A scan-status panel presents current state, progress, files scanned,
elapsed time, and a Scan Again control. The central area contains storage-by-category
visualization and Recent Activity. Advanced Details contains text results and a zoomable
chart, while the Top Files section provides search, sorting, pagination, file opening, folder
opening, and refresh controls.

Figure 3. Final Smart Storage Manager dashboard in Day mode.

6.2 Feedback and Interaction Safety


The status area uses explicit states such as Ready, Folder Selected, Analyzing,
Completed, and Failed. Button state is tied to application state: folder-dependent buttons
remain unavailable before selection; most controls are disabled while the program is busy;
and Undo is enabled only when a reversible move history exists. Error dialogs explain
inaccessible files, missing selections, or failed operations without terminating the application.

6.3 Theme System


Day, Night, and Cute themes are implemented through theme dictionaries that define
background, panel, text, border, primary, secondary, warning, and success values. The same

12
structural widgets are reused; only their appearance is reconfigured. The selected theme is
stored in [Link] and restored at startup.

Figure 4. Comparison of the three supported interface themes in grayscale.

6.4 Multilingual and Right-to-Left Support


A centralized translation dictionary maps interface keys to English, Chinese, Urdu, and
Russian. Language changes refresh headings, buttons, status messages, table columns, activity
descriptions, settings labels, search placeholders, and theme names. This key-based approach
prevents business logic from being duplicated for each language.

Urdu required layout behavior in addition to translation. Text alignment is changed to the
right, the header and Top Files controls are mirrored, result and activity text use right-justified
tags, and optional arabic-reshaper and python-bidi processing improves connected Urdu glyph
display. The design therefore treats internationalization as both linguistic and spatial.

Figure 5. Multilingual interface

7. Experimental Evaluation and Results


7.1 Test Environment
Development and source-code testing were performed in an Anaconda Python
environment using Spyder on Windows. The application was also run from Anaconda Prompt
to verify that the intended Python interpreter and installed packages were used. Deployment
testing used PyInstaller to create a folder-based Windows executable containing the Python
runtime, CustomTkinter resources, Matplotlib TkAgg backend, and application modules.

13
7.2 Functional Test Results
Table 6. Functional validation results.
Test Expected result Result

Selected path appears and dependent


Folder selection Pass
controls become available.

File count, total size, and categories are


Recursive analysis Pass
calculated.

Large files Files are ranked in descending size order. Pass

Copied files are returned as


Duplicate files Pass
original/duplicate pairs.

Empty files Zero-byte files are listed separately. Pass

Planned source and destination paths are


Preview organization Pass
displayed without movement.

Top-level files move into category folders


Organize files Pass
after confirmation.

The latest move set is restored in reverse


Undo Pass
order.

storage_report.txt contains summary and


Report generation Pass
detailed results.

Search, sorting, pagination, open file, and


Table interaction Pass
open folder operate correctly.

Day, Night, and Cute appearances update


Theme switching Pass
immediately.

English, Chinese, Urdu, and Russian labels


Language switching Pass
refresh.

Actions appear with translated descriptions


Activity history Pass
and timestamps.

Folder-based Windows application is


Executable build Pass
produced successfully.

7.3 Responsiveness and Reliability Observations


The background-task model prevented the interface from becoming permanently
unresponsive during scanning and hashing. Busy-state controls prevented overlapping actions.
Missing or inaccessible files were skipped through PermissionError, FileNotFoundError, and
selected OSError handling. When GUI completion logic raised an error, the improved task
runner returned the application to a non-busy state and displayed an error dialog instead of
leaving all buttons disabled.

14
A missing math import initially caused pagination failure during interface construction. A
separate environment mismatch occurred when Spyder used its private runtime instead of
Anaconda's Python, making CustomTkinter unavailable. These issues were resolved by
importing the required module and running the project with the correct interpreter. Later,
pending Tk callbacks caused invalid-command errors after window destruction; tracked
callbacks and queue-based main-thread updates eliminated this shutdown problem.

7.4 Deployment Evaluation


The PyInstaller build initially attempted to collect multiple Qt binding packages through
optional Matplotlib backends. Because the application uses Tk rather than Qt, PyQt and
PySide modules were excluded and only the TkAgg backend and required Matplotlib data
were collected. The corrected build completed successfully.

Figure 6. Successful creation of the folder-based Windows executable.


The evaluation also showed an important distribution distinction. The executable from an
onedir build cannot be shared alone because it depends on the accompanying _internal
runtime directory. The complete output folder must be compressed and distributed, or a
separate one-file build must be created. This result demonstrates that deployment correctness
includes both compilation and proper distribution of runtime resources.

8. Discussion
8.1 Strengths of the Proposed System
Smart Storage Manager integrates analysis, visualization, organization, localization, and
deployment within one coherent program. Its main strength is controlled file handling. Users
inspect results before acting, files are moved rather than deleted, and the most recent
movement can be reversed. The dashboard translates technical metadata into visible
summaries, while search and sorting support more detailed investigation.

The modular architecture separates interface concerns from file-system algorithms and
persistent paths. This separation improved maintainability during repeated redesign. The final
codebase contains 143 primary functions and methods plus 18 internal worker or callback

15
functions across the principal Python modules. Including the translation dictionary, the final
source set contains approximately 7,256 lines. The scale reflects the breadth of interface
behavior, localization, lifecycle handling, and deployment support rather than only the
file-analysis algorithms.

8.2 Limitations
●​Duplicate detection reads file contents and can therefore take substantial time in very
large folders.
●​MD5 is suitable for practical duplicate comparison but should not be treated as a
security-grade integrity proof.
●​Analysis is recursive, whereas organization currently moves only top-level files.
●​Undo history is held for the latest session and is not a complete transactional journal.
●​Reports are plain-text files rather than PDF or spreadsheet documents.
●​The folder-based executable must be distributed with its supporting runtime directory.
●​Unsigned executables may trigger Windows SmartScreen warnings on another computer.
8.3 Data Safety and Ethical Considerations
The program operates only on folders explicitly selected by the user. It does not upload
file names or file contents, and analysis remains local. Nevertheless, file-management
software can cause harm if actions are unclear. The design therefore avoids automatic
deletion, requests confirmation before organization, prevents overwriting an existing
destination, records actions, and provides undo. Future versions should add a persistent
transaction journal and optional recycle-bin integration.

8.4 Comparison with a Simple File Organizer


A basic organizer typically examines file extensions and moves files into folders. Smart
Storage Manager extends this model in several directions: recursive analysis, summary
statistics, hash-based duplicate discovery, empty-file detection, interactive metadata table,
visualization, activity history, multiple languages, persistent preferences, background
processing, and packaged execution. The project is therefore better described as a
storage-analysis dashboard with controlled organization functions rather than as a
single-purpose sorting script.

9. Conclusion and Future Work


9.1 Conclusion
This research designed and implemented a multilingual Smart Storage Manager for
Windows. The system successfully combines recursive analysis, category summaries,

16
large-file ranking, duplicate detection, empty-file detection, searchable metadata,
visualization, preview-based organization, undo, report generation, persistent settings, activity
history, and executable deployment. The use of background threads and a synchronized queue
preserved interface responsiveness, while lifecycle cleanup corrected shutdown errors.
Centralized translation keys and language-aware layout functions enabled four languages,
including Urdu right-to-left presentation.

Functional validation confirmed that the major user workflows operate as intended. The
successful folder-based PyInstaller build further demonstrated that the application can operate
outside the source development environment. The project therefore meets its principal
objective: providing a practical, understandable, and comparatively safe desktop tool for
examining and organizing local folders.

9.2 Future Work


●​Group files by size before hashing and optionally verify matches with SHA-256.
●​Add a persistent transaction journal, recycle-bin support, and multi-step undo.
●​Generate PDF and spreadsheet reports with charts and summary statistics.
●​Add file-age analysis, unused-file recommendations, and estimated storage savings.
●​Support scheduled scans and drag-and-drop folder selection.
●​Create a signed installer with icon, version metadata, shortcuts, and uninstall support.
●​Develop automated unit tests and performance benchmarks for very large datasets.
●​Expand accessibility features, scalable text, and additional interface languages.

17
References
[1] Python Software Foundation, “tkinter — Python interface to Tcl/Tk,” Python
Documentation. Available: [Link] Accessed: Jul. 6,
2026.
[2] T. Schimansky, “CustomTkinter Documentation,” CustomTkinter. Available:
[Link] Accessed: Jul. 6, 2026.
[3] Python Software Foundation, “os — Miscellaneous operating system interfaces,” Python
Documentation. Available: [Link] Accessed: Jul. 6,
2026.
[4] Python Software Foundation, “shutil — High-level file operations,” Python
Documentation. Available: [Link] Accessed: Jul. 6,
2026.
[5] Python Software Foundation, “hashlib — Secure hashes and message digests,” Python
Documentation. Available: [Link] Accessed: Jul.
6, 2026.
[6] Python Software Foundation, “threading — Thread-based parallelism,” Python
Documentation. Available: [Link] Accessed: Jul.
6, 2026.
[7] Python Software Foundation, “queue — A synchronized queue class,” Python
Documentation. Available: [Link] Accessed: Jul. 6,
2026.
[8] Matplotlib Development Team, “Embed in Tk,” Matplotlib Documentation. Available:
[Link]
Accessed: Jul. 6, 2026.
[9] PyInstaller Development Team, “What PyInstaller Does and How It Does It,” PyInstaller
Documentation. Available: [Link]
Accessed: Jul. 6, 2026.
[10] PyInstaller Development Team, “Using PyInstaller,” PyInstaller Documentation.
Available: [Link] Accessed: Jul. 6, 2026.

18
Appendix A. Codebase Structure and Metrics
The final EXE-ready codebase is organized into five principal source files. The metrics
below were calculated directly from the final source versions used for packaging. Translation
entries contribute substantially to the total line count because every major label and status
message is represented in four languages.

Table A1. Final codebase metrics.

Source file Lines Functions or role

gui_exe_ready.py 5,779 125 primary; 18 nested

file_tools_exe_import_fixed.py 373 14 primary; 0 nested

main_exe_ready.py 22 1 primary; 0 nested

app_paths_exe_ready.py 29 3 primary; 0 nested

translations_translation_refresh_fixed.
1,053 Translation dictionary
py

Total 7,256 143 primary; 18 nested

A.1 Principal Backend Functions


The backend module contains fourteen principal functions: should_skip_file,
get_file_category, format_size, analyze_storage, find_large_files, get_file_details,
calculate_file_hash, find_duplicates, find_empty_files, preview_organization, organize_files,
undo_organization, generate_report, and write_log. Together, these functions implement the
complete analytical and reversible file-management workflow used by the graphical interface.

19

You might also like