I am a backend developer with a passion for programming, a fascination with Linux-related topics
and open-source projects. I like drawing and reading books when I find time to spare, and I love
watching movies the most. My favorite genres are thriller, horror, and mystery. 🧛🏻

Follow me [on Instagram](https://instagram.com/mustapha_sz) or [on LinkedIn](https://www.linkedin.com/in/mustapha-alioglou/).


Mustapha Alioglou


If you have ever used a Mac, you know the move. You select a file in Finder, press **Space**, and
the file opens right there in a floating panel. You look at it, press Space again, and it's gone.
No app launches, nothing gets a window in your taskbar, and you never lose your place in the folder.

I use KDE Plasma, and this is the one thing I kept missing. Dolphin has a preview pane and tooltips,
but neither one lets me read page 12 of a PDF or check what's inside a zip before I extract it. So I
built it. It is called **QuickView**: select a file in Dolphin, press Space, and a dark preview panel
appears. Press Space (or Esc) again and it goes away.

![A PDF previewed by QuickView](/images/blog/quickview/pdf.png)

### Fast enough to feel like a key press

A previewer only works if it is instant. If you have to wait a second, you might as well open the file.

The trouble is that QuickView is written in Python with Qt, and starting Qt from nothing takes about a
second. So QuickView keeps a small **daemon** running in the background with Qt already loaded. Pressing
Space runs a tiny client, written in Rust, that does nothing except pass the file path over a socket.
That takes about 4 ms, and the panel is on screen about **20 ms** after the key press.

Previews are also cached, in memory and on disk, so opening a file again is close to free. While you
look at one image, the next ones in the folder are already being decoded in the background.

### What it can preview

Pretty much everything I come across in a normal week:

<div class="table-responsive">

| Type | How |
|---|---|
| Images (PNG, JPG, WebP, SVG, …) | Scaled to fit, with the dimensions in the titlebar |
| Photoshop, Krita, Illustrator | The flattened image the file already stores, no layers parsed |
| PDFs | Scrollable pages, Ctrl+F search and a bookmarks sidebar |
| EPUB books | Laid out as real pages, with a chapter sidebar and search |
| Markdown | Rendered pages, with a button to flip to the source |
| Code and text | Syntax highlighted |
| Word, LibreOffice, PowerPoint | Laid out as pages, like a PDF |
| Spreadsheets | A real grid with a tab per sheet |
| Video and audio | Plays inline with a seek bar |
| Archives (zip, rar, 7z, tar…) | A listing of what's inside, nothing extracted |
| HTML | Rendered with JavaScript off and the network blocked |
| Everything else | A card with the icon, type, size and date |

</div>

That last row matters more than it looks. Space is never a dead key. Even a file QuickView can't
open gets a card that tells you what it is.

![An image preview, with its dimensions in the titlebar](/images/blog/quickview/image.png)

You can also select **several files** and press Space, and then **←** and **→** step through them,
with the titlebar showing `2/5` like Quick Look does. With a single file the arrows walk the folder
instead. **Enter** opens the file in its real app when the preview is not enough.

### The details I enjoyed the most

Some of the formats turned out to be much more fun than I expected.

**Books are read, not listed.** An EPUB is basically a zip of web pages with a reading order, which is
close enough to what Qt already knows how to lay out. So QuickView lays the book out as pages, each
chapter starts on a new page, and the book's own table of contents becomes a sidebar with page numbers.
The page colours are a setting too, so you can read in sepia or gruvbox if you like.

**Ctrl+F works in PDFs and books.** Matches are highlighted right on the page, Enter jumps to the next
one, and phrases work even when they wrap onto the next line.

**Spreadsheets look like spreadsheets.** An `.xlsx` stores every number bare, with a separate format
code that says how to show it. If you ignore the format codes, €1,234.50 shows up as `1234.5` and every
date shows up as a five digit number. QuickView reads the codes and applies them, so you see currency,
percentages, thousands separators and negatives in brackets, the way the person who made the workbook
saw them.

**Archives are never extracted.** QuickView only reads the list of files, so an archive that expands to
a terabyte costs nothing to look at.

**Shebangs count.** Syntax highlighting goes by the file extension, but a script like `~/bin/deploy`
has none. In that case QuickView reads the `#!` line, so `#!/usr/bin/env python3` is highlighted as
Python anyway.

![A source file preview](/images/blog/quickview/code.png)

### Every file is opened inside a sandbox

This is the part I care about the most, and it is the part you hopefully never notice.

A previewer is a scary piece of software when you think about it. Its whole job is to open files you
just downloaded and haven't looked at yet, and image, PDF and video decoders have a long history of
security bugs. One bad file could do anything your user account can do.

So QuickView never parses a file in the main program. Every image, PDF, book, office document,
spreadsheet, video and even the syntax highlighter runs inside a **bubblewrap** sandbox with:

- **no network**
- **no permission to write anything**
- **no access to your files at all**

That last one is the important bit. The file is handed to the sandbox already opened, as a file
descriptor, so the code inside never needs a path and has nothing else to look at. If a malicious file
manages to crash or take over the decoder, all it gets is a throwaway process that can't read your
home folder and can't phone home. Then it exits, because each sandboxed worker handles exactly one file.

You would expect all this to make it slower, but it actually made it faster. Entering the sandbox
costs about 3 ms. What used to be slow was starting Qt for every preview, so now QuickView starts a
spare worker *before* you need it and parks it. Opening a one page PDF went from 583 ms to about
120 ms, and a cached preview takes around 2 ms.

### It can look like Plasma, too

By default the panel is a Quick Look impression: dark, rounded, with the close button on the left.
That's what I set out to build and it stays the default. But if you'd rather it fit in with the rest of
your desktop, one line in the config switches to a **Breeze** theme that follows your Plasma colour
scheme, accent colour included, and moves the close button to the right.

```ini
# ~/.config/quickview/quickview.conf
[appearance]
panel_theme = breeze
```

![The breeze panel theme on a dark Plasma colour scheme](/images/blog/quickview/breeze.png)

### Installing it

You need KDE Plasma with Dolphin, Python 3.10 or newer and `bubblewrap`. The sandbox isn't optional,
so QuickView won't run without it.

```shell
git clone https://github.com/MustaphaAlioglou/QuickView.git
cd QuickView
./install.sh
```

The installer builds its own virtualenv and never touches your system packages. It uses your distro's
PySide6 when there is one, adds the Dolphin menu entry and starts the daemon as a systemd user service.
If `rustc` is installed it also builds the fast client. Without it, a Python client does the same job
about 15 ms slower. `./uninstall.sh` removes all of it again.

The last step is binding Space in Dolphin, once:
**Menu → Configure → Configure Keyboard Shortcuts… → search "Quick Look" → Custom → Space**

If you want slide decks and old `.doc`, `.xls` and `.ppt` files too, install LibreOffice. QuickView
then uses it, still inside the sandbox, to lay those files out exactly as they look in an office suite.

### Is it free?

Yes, it's licensed under GPL-3.0-or-later, and the code is on [GitHub](https://github.com/MustaphaAlioglou/QuickView). If you
find a file it previews badly, open an issue and attach the file if you can. That is the fastest way
for me to fix it.

Thanks for reading, and enjoy pressing Space.


Meet QuickView, a Quick Look style previewer for Dolphin. Select a file, press Space, and a preview panel opens in about 20 ms. PDFs, books, office files, spreadsheets, video, archives and code all open in place, and every file is parsed inside a sandbox.

QuickView - macOS Quick Look for KDE Plasma


Be honest, when was the last time you opened your Downloads folder and actually liked what you saw?
Mine is the usual mix: three copies of the same photo called `photo (1).jpg` and `photo (2).jpg`,
an `.AppImage` I installed months ago, a half-finished `.part` download, a `.zip` sitting right next to
the folder I already extracted it to, and somewhere in there the one PDF I actually need.

So I built a small app for it. It is called **Tidy**, and the whole idea fits in one sentence:
point it at a messy folder, it shows you a plan to tidy it, you approve the plan, it runs, and you can undo it.

### Why not just use a script?

There are already good tools for this on Linux: `fdupes` for duplicates, `organize` for rule-based
sorting, and the many Hazel-style clones. The thing they have in common is that they expect *you* to
write the rules. You need to know what a glob is, which flags to pass and what will happen when you
press enter, which for a cleanup tool is a bit scary.

Tidy works the other way around. It **proposes, you approve**. You never write a rule, and the first
thing you ever see is a preview, not a progress bar.

### The flow

1. Pick a folder. Downloads, Desktop and Documents are one click away, but any folder works.
2. Tidy scans it, looking at every file's type, age, size and name.
3. You get a plan with a before/after summary, something like "21 items → 8 items".
4. You can untick whole groups or single files, drag a file into another group, or change where a group goes.
5. You press Tidy, and if you change your mind, Tidy History puts everything back.

![The plan in the GTK frontend](/images/blog/tidy/gtk-plan.png)

### What it finds

At the moment (version 0.2) Tidy groups things like this:

<div class="table-responsive">

| Group | What | What happens |
|---|---|---|
| Clutter | unfinished `.part`/`.crdownload` downloads, empty folders, archives you already extracted | holding area |
| Duplicates | byte-identical copies, keeping the original | holding area |
| Installers | `.deb`, `.rpm` and `.pkg.tar.zst` files that are already installed, or any installer older than a month | holding area |
| Old Files | things you haven't opened in 6 months | moved to `Archive/` |
| Pictures, Documents, Music, Videos, Archives | the rest of the loose files, sorted by type | moved to a folder per type |

</div>

The installer check is one of my favourite parts. For `.deb`, `.rpm` and Arch packages Tidy reads the
package name from the filename and asks your package manager (`pacman -Q`, `dpkg-query` or `rpm -q`)
whether it is already installed. If it is, there's no reason to keep the 300 MB file around.

For duplicates it first groups files by size, then hashes the first 64 KB, and only hashes the whole
file when both of those match. Most files never get fully read, which keeps the scan fast even on a
big Downloads folder.

There is also a **What's Big** tab, because sometimes you don't want to clean, you just want to know
where the space went:

![What's Big in the GTK frontend](/images/blog/tidy/gtk-big.png)

### Safety is the actual feature

For a tool like this, trust is everything. One wrongly moved file and you would never open the app
again, and I wouldn't blame you. So most of the work went into making sure nothing bad can happen:

- **Nothing is deleted outright.** Removed items go to a holding area for 30 days and only then expire.
- **Every move is written to a small SQLite log *before* it happens.** If the app crashes in the middle
  of a run (or you pull the plug), the next start sees which moves completed and which didn't.
- **Undo puts files back exactly where they were.** A whole run or a single file. If the original name
  has been taken in the meantime, the file comes back as `name (2)` instead of overwriting anything.
- **It never overwrites.** Moves use the `renameat2()` system call with `RENAME_NOREPLACE`, so the kernel
  itself refuses to replace an existing file, even if one appears a millisecond before the move.
- **Files that changed since the scan are skipped.** So is anything modified in the last 10 minutes,
  because it might still be downloading.
- **Protected locations.** System folders, hidden files and config, git repositories and project
  folders (anything with a `package.json`, `Cargo.toml`, `Makefile` and so on) are left alone.
- **Local only.** There's no cloud, no account and no telemetry.

There is one small detail I really like. Checking whether a file is "old" uses its last access time,
but reading a file to hash it would *update* that access time, so every scan would make all your old
files look recently used. Tidy opens files with the `O_NOATIME` flag, so looking at a file
doesn't count as using it.

![Tidy History, where every run can be undone](/images/blog/tidy/gtk-history.png)

### Native on GNOME *and* KDE

This was a hard requirement for me. I use KDE Plasma, but most of the Linux world uses GNOME, and an
app that looks foreign on your desktop always feels a little bit wrong.

So Tidy has **two frontends sharing one core**:

- **GTK4 + libadwaita** for GNOME, with boxed lists, switches and a pill button, the way GNOME apps look.
- **Qt 6** for KDE Plasma, with a tree view, checkboxes, Breeze icons, your file manager's MIME icons and
  your locale's date and size format.

![The plan in the Qt frontend on KDE Plasma](/images/blog/tidy/qt-plan.png)

The launcher looks at `XDG_CURRENT_DESKTOP` and picks the right one on its own. You can also force one:

```shell
tidy --qt
TIDY_UI=gtk tidy
```

The core is plain Python with only the standard library, and both frontends use the GTK and Qt bindings
your distribution already ships (PyGObject and PySide6). There's no Electron and no bundled 600 MB runtime.

### There's also a CLI

Because sometimes you're already in a terminal:

```shell
$ tidy-cli scan ~/Downloads
/home/mustapha/Downloads: 19 files, 282.4 kB
18 items -> 8 groups, 103.0 kB can be freed
before: 21 items, after: 8 items

Duplicates (3 items, 89.0 kB) -> holding area (30 days)
  IMG_2041 (1).jpg  [40.0 kB] Copy of IMG_2041.jpg
  ...
```

`tidy-cli scan` is always a dry run. You need `--apply` to actually move anything, and
`tidy-cli undo` takes it back.

### Does it run on my distro?

Probably! I didn't want "works on my machine" to be the answer, so the project has a test script that
spins up clean containers of the big distributions and does the following in each one:

1. installs that distro's own GTK, libadwaita and PySide6 packages
2. runs the unit tests and drives *both* GUIs through scan → tidy → undo under a virtual X server
3. runs the installer

At the moment it passes on Ubuntu 24.04 and 26.04, Debian 13, Fedora 44, Arch and openSUSE Tumbleweed.
The only gap is Ubuntu 24.04, which doesn't package PySide6, so there you get the GTK version everywhere.

### What's next

The roadmap from here:

- **v0.3:** content-aware grouping. A PDF with "Invoice" and a total in it is a receipt, so suggest a
  "Receipts 2026" folder. Tidy will also learn your habits: if you always move bank statements to `~/Finance`,
  it offers that next time.
- **v0.4:** an optional watch mode that nudges you once in a while ("47 new files. Tidy up?") and rules
  you can write as plain sentences, like "Move screenshots older than 30 days to Pictures/Screenshots".
  Nothing will ever move on its own unless you turn on auto-tidy for that specific rule.

The rule for all of it stays the same: the preview, the undo and the holding area come first, and the
smart features only come after them.

Thanks for reading, and may your Downloads folder be forever tidy.


Meet Tidy, a small Linux app that looks at a messy folder like Downloads, shows you a plan to clean it up and only moves things once you approve. Every change can be undone, and it looks native on both GNOME and KDE.

Tidy - A folder cleanup tool for Linux that asks before it moves

Are you familiar with the Unix philosophy and how to create 

Are you acquainted with the Unix philosophy and how to improve scriptwriting?
In this comprehensive guide, we will delve into the general definition of the
Unix philosophy, explore the essential components of well-crafted scripts, and 
grasp the fundamentals of scripting, including concepts like the pipeline operator,
stdin, and stdout manipulation. Lastly, we will dissect how to apply these principles
as best practices in our Ruby and Bash scripts.

### What is the Unix philosophy?
The Unix philosophy was originally defined by the master Ken
thompson and it's a set of good practices that define a minimalist and modular 
software, all the core utils from Unix (such as find, grep) follow 
this good practices so we can agree that it need to be good right?

The original quote documented by Doug Mcllroy contain the following items:
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output
with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to 
throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to 
build the tools and expect to throw some of them out after you've finished using them.

### What is a pipeline?

A pipeline is a continuous run of programs where the stdout of one follow as the stdin of
the next one, on bash/zsh/fish shells we can use the | operator to refer as a pipe and we
use it a lot to further query information, for example: imagine you want to count how many
markdown files you have in your directory, you can do the following:

```shell
find . -iname '*.md' | wc -l
```

Let's break it down piece by piece so you can understand properly shall we?

First we have the find command being used to list all the markdown files on the current directory, 
for me personally this produces the following:

```shell
$ find . -iname '*.md'
./posts/20230814T124722/README.md
./posts/20230703T214043/README.md
./posts/20230616T234323/README.md
./posts/20230625T223158/README.md
./posts/20230731T212528/README.md
./posts/20230807T203924/README.md
./posts/20230804T140043/README.md
./REPL Driven Development - For not so smart developers.md
./Como escrever uma CLI CRUD utilizando ScyllaDB + Ruby.md
./Linux filters - How to streamline text like a boss.md
```

If you just want to list the proper file names without counting them, you
can even pipe it to the sort command, that way it lists alphabetically like the following:

```shell
$ find . -iname '*.md' | sort
./Como escrever uma CLI CRUD utilizando ScyllaDB + Ruby.md
./Linux filters - How to streamline text like a boss.md
./REPL Driven Development - For not so smart developers.md
./posts/20230616T234323/README.md
./posts/20230625T223158/README.md
./posts/20230703T214043/README.md
./posts/20230731T212528/README.md
./posts/20230804T140043/README.md
./posts/20230807T203924/README.md
./posts/20230814T124722/README.md
```

### What is stdin and stdout?
Stdin (standard input) and stdout (standard output) are the main ways
that a computer communicates with the outside world. Below, we'll delve more into the details of each one:

* Stdin (standard input) is normally referred to as anything that 
waits for a user interaction (like typing on an input, selecting an item 
from a list, etc.), but this can be understood in a more generalized way;
basically, we can think of Stdin as the default information provider, whether 
this comes from another program or from a user interacting with it.
* Stdout (standard output) is normally referred to as anything 
that prints out a value to the screen (it can be a terminal, a browser,
or anything). Differently from Stdin, this is totally correct, the only caveat 
is that when inserted in a pipeline context, all stdout is suppressed as
the stdin of the next command instead of printing to the screen.

### What defines a bad script and how to turn into a good one?
Describing a exact summary of what is a good script can be quite tricky
because of the many variables involved. Instead, let's flip the question:
what does a bad script look like according to the Linux philosophy? And how
can we solve the specific problem to create slightly better tools?

### Ignoring standard input and output communication
Have you ever used some CLIs that have a fancy way to display information 
with an animated input or a cool spinner? It's indeed quite cool to use those
tools when you just want to use them by themselves, but when you try to put those 
tools in a pipeline, they break the whole process. Instead, always write your tools
by using standard communication as the primary way to receive and retrieve information, 
prefer to use options instead of hard-coding values (an example of an option is --output=json or -o json).

In Ruby, it's far easier to not shoot yourself in the foot because the way we learn to 
get data already works pretty well with the standard input, but it's important to keep 
an eye on how you design your script.

For example, consider this simple script called printname.rb example:

```shell
#!/usr/bin/env ruby

puts 'Type your name: '
name = gets.chomp

puts "Your name is: #{name}"
```
This script in a first glance works both running by itself and on a pipeline, but observe the output produced by both:

```shell
$ echo "Cherry Ramatis" | ./printname.rb
Type your name:
Your name is: Cherry Ramatis
```

```shell
$ ./printname.rb
Type your name:
Cherry Ramatis
Your name is: Cherry Ramatis
```
You can observe that we're always printing the Type your name message, in this case we have two options:

* Accept this name with a flag parameters instead by receiving <mark>--name="Cherry Ramatis"</mark>
* Drop the Type your name message, turning the script into a more pipelineable (nice word huh?) one.

### Doing a lot on the same tool, aka monolithic scripts
Sometimes you're writing a tool and quickly observe that the scope got bigger while you were writing it, now what should be a small tool is growing to be a big project with various interactive steps. When it reaches that point it's quite seducing to just keep iterating on the same tool by adding a lot of sub commands, but the unix philosophy help us understand that writing a tool that do one thing right is more valuable than writing a gigantic behemoth.

So instead of creating a big CLI with a whole set of commands, try to think in writing small separate tools that interconnect and complement each other, for example:

Imagine you want to write a command that list all the songs from a database in a particular order and prompt the user to choose one, instead of writing all those functionalities in one command, you can compose with different ones like:

```shell
$ list_songs | sort | update_song
```

See how <mark>list_songs</mark> and <mark>update_song</mark> are different scripts? both communicate
via STDIN and STDOUT, allowing the user to pipeline
through any command and receive the same behavior (for example we're piping 
it to sort because we want to view the list in a sorted manner.)

### Bonus point: The bang operator in vim

Rejoice, Vim users! This is our time to shine. Vim is a somewhat standard editor in Unix systems and this comes with a set of benefits such as interacting with binaries directly in your buffer via the ! operator.

In vim you can press !! in normal mode to populate a command like this in your minibuffer :.!, the command you type after the ! will be used with the current line as STDIN, mind blowing right? Observe the example below:

Consider the following script in ruby:
```shell
#!/usr/bin/env ruby

STDIN.each do |line|
 puts "- #{line}"
end
```


### Conclusion
This is a smaller article where I tried to bring more context into something that I do a lot in my day to day life:
automating. I hope this content is useful for you and if I can help with anything just reach me out! May the force be with you 🍒


We will delve into the concept of Unix philosophy, examine the essential components of a finely crafted script, and grasp the foundational aspects of scripting, including the utilization of the pipeline operator,  stdin, and stdout manipulation.

Tech

QuickView - macOS Quick Look for KDE Plasma

Tidy - A folder cleanup tool for Linux that asks before it moves

Linux filters - How to streamline text