< I had a simple goal. A noble goal, even. I wanted to sync my Obsidian vault across all my devices using Syncthing. For those not in the know, Syncthing is a fantastic piece of software that lets you create your own private, decentralized cloud. No big tech companies snooping on your files, just your own devices talking to each other. It’s the kind of thing that makes you feel like you’re finally taking control of your digital life.

So, I installed Syncthing on my Arch Linux box. I’m running Hyprland, a tiling window manager that’s both beautiful and ruthlessly efficient. I like my windows to snap into place, to obey my commands, to be predictable. This is where the trouble started.

Syncthing has a GUI. A perfectly functional, if a little dated, GUI built with Qt. And for some reason, that Qt application decided that the rules of my carefully curated Hyprland setup did not apply to it. It floated when it should have tiled. It ignored my window rules. It was the digital equivalent of a guest who puts their feet on the coffee table.

Now, a sane person would have said, “Huh, that’s weird,” and immediately switched to the web UI that Syncthing also provides. But I, dear reader, am not a sane person. I am an Arch Linux user. My stubbornness is a feature, not a bug.

“I can fix this,” I muttered to myself, cracking my knuckles. “It’s just a configuration issue.”

And so began my descent into madness.

My first stop was the usual suspect: xdg-desktop-portal-hyprland. Surely, this was a portal issue. I tweaked the config. I restarted the service. Nothing. The Syncthing window continued its defiant, floating existence.

Next, I went down the rabbit hole of Qt environment variables. QT_QPA_PLATFORM=wayland? QT_QPA_PLATFORMTHEME=qt5ct? I tried them all. I exported them in my .zshrc. I sourced them in my hyprland.conf. I probably tried to set them as my kernel boot parameters at some point. The result? A whole lot of nothing.

I spent hours reading forum posts from 2017, ArchWiki articles that were last updated when I was still in high school, and GitHub issues that were closed with the dreaded “Cannot reproduce.” I was convinced I was on the verge of a breakthrough. I was sure that the next tweak, the next environment variable, the next window rule would be the one that finally wrangled this rogue Qt app into submission.

All the while, my files were syncing perfectly in the background. Syncthing, the service, was doing its job flawlessly. It was just the GUI, the optional, cosmetic part of the experience, that was causing me this much grief.

It was sometime around 2 AM, staring at a screen full of config files and feeling the cold dread of an impending all-nighter, that I had an epiphany. A moment of clarity so profound, so earth-shattering, that it changed everything.

“Wait a minute,” I thought. “Doesn’t Syncthing have a web UI?”

I opened my browser. I typed localhost:8384. And there it was. A beautiful, functional, and most importantly, well-behaved interface. It was running in my browser, a native Wayland application that tiled perfectly. It was everything I wanted. It was there the whole time.

I had spent an entire evening trying to force a square peg into a round hole, all for the sake of a “native” experience, when a perfectly good, perfectly native-feeling web UI was just a URL away.

I closed all my terminal windows. I deleted the environment variables. I removed the custom window rules. And I bookmarked localhost:8384.

It’s a humbling experience, to be so thoroughly defeated by your own stubbornness. But it’s also a valuable lesson. Sometimes, the best solution isn’t the most complicated one. Sometimes, the “leet” way isn’t the right way. And sometimes, the most “Arch” thing you can do is admit defeat and use the web UI.

Now if you’ll excuse me, I have some files to sync. And a lot of sleep to catch up on.