Explobar: Fixing That Surprisingly Annoying Friction in Windows Explorer

Oleg Shilo — Wed, 06 May 2026 02:54:31 +0000

Why?

If you do most of your work in a terminal, this post may feel only mildly relevant.

But if your day often starts in Windows Explorer, the gap between browsing files and acting on them can be surprisingly clumsy.

You open a folder, inspect files, jump between project directories, right-click things, copy paths, open terminals, launch editors, and repeat the same small rituals dozens of times a day. None of these steps is difficult on its own, but together they quietly drain momentum.

That is the problem Explobar is built to solve.

The Windows Explorer gap

Windows Explorer is often the default workspace for many developers on Windows. Not for everything, of course, but for plenty of real work:

opening a repo you just cloned
browsing generated files
inspecting logs, assets, build output, config files, etc.
comparing folders
jumping into the right directory before launching tools

This is especially common in what can be called a gemba workflow: you start where the work physically is, in the file system, and act from there.

The issue is not that Explorer is bad at browsing files. The issue is that acting on those files usually takes too many steps. Open Terminal. Copy path. Paste path. Launch an editor. Run a helper script. Open properties. Create a file. Create a folder. Jump to a recent location.

Explorer makes these actions possible, but not fluid.

A note on QTTabBar

It is worth acknowledging QTTabBar here. For years, it was the tool that made Explorer genuinely usable for power users and developers.

It proved that Explorer could become far more productive with the right extensions around it.

The problem is that the "extensions approach" has become much less viable over time. Windows 10/11 has changed the Explorer hosting model, and that effectively broke the assumptions tools like QTTabBar depended on. What used to be a powerful extension point turned into a fragile maintenance problem.

So this is not a criticism of QTTabBar. It's rather excellent. It is simply a recognition that Windows moved on in a way that practically killed one of the best Explorer productivity tools many of us relied on.

Terminal-first developers already have a solution

It is worth being precise here: if you are already living in a terminal, this problem is almost irrelevant.

Shell users have fast navigation, aliases, scripts, history, fuzzy finders, editor integration, and automation built into the workflow because they rely on the "textual" experiences that are handled by the terminals really well. Explobar is not trying to replace that world.

It is for developers who work on Windows and still rely on visual/graphical experiences and use Explorer as a usual starting point: people who navigate visually first, then want immediate access to the tools and commands that matter in that context.

What Explobar does

Explobar adds a customizable floating toolbar to Windows Explorer.

When you trigger it (e.g. hot-key), a toolbar appears right where you are working, with awareness of the current folder and selected files. From there, you can launch apps, run custom commands, open recent locations, trigger built-in file actions, or wire in your own automation.

Conceptually, Explobar partially overlaps with Explorer right-click shell extensions: it gives you context actions for the files and folders in front of you.

But it is dramatically faster because it is not competing with Explorer's own context menus or with the hundreds of third-party apps that keep adding entries there. Instead of digging through an overloaded menu tree, you get a focused toolbar built by you around your workflow.

And that is the key difference: you are in complete control of what those context actions are. You can keep just a few essential pre-configured buttons, or define as many new actions as you need.

In practice, that means less of this:

copy path
switch windows
type the command again
dig through menus

And more of this:

navigate > select > act

That is the core idea: reduce the distance between seeing something and doing something.

Just as importantly, Explobar avoids the integration model that made older Explorer extensions fragile. It is not a shell extension tightly embedded into Explorer. It is a simple, standalone, zero-dependency app running outside the Explorer process.

That design choice matters. If Explorer changes internally, Explobar is far less exposed compared to tools that live inside Explorer itself.

Why this is interesting

Explobar is lightweight in concept, but it opens up a very useful layer of customisation.

At the centre of the app is a very simple idea: the toolbar is just a set of buttons and actions fully defined by the user in a declarative config file (YAML).

You can keep it simple with a few buttons in the config (e.g. open in Terminal/Notepad, navigate to recent folders). That alone removes plenty of friction.

But the model does not stop at static launchers. If you need something more advanced, like calculating hashes for all selected files, you can attach custom logic implemented in a small .NET assembly or even a single C# .cs file (script file).

That is what makes it appealing for developers:

easy to start
fast to adapt
powerful if you want to grow into it

Final thought

A lot of developer tooling focuses on editors, terminals, and cloud workflows. That makes sense. But local file-system work is still part of the day for many developers.

Explobar is a focused answer to that reality. It does not try to replace your terminal or your editor. It just removes friction from the place where many Windows workflows still begin: Explorer.

If this sounds like your workflow, the project is on GitHub.
Post your questions, suggestions, bug reports there: https://github.com/oleg-shilo/explobar.

And installation on Windows is as simple as:

winget install explobar

DEV Community: Oleg Shilo