The Zen of a file manager
When you run the statement import this in Python, you get an
opinionated list of principles that guide the programming language's design.
Much in the same spirit, here are the core values driving fman:
Looks matter.
Speed counts.
Extending must be easy.
Customisability is important.
But not at the expense of speed.
I/O is better asynchronous.
Updates should be transparent and continuous.
Development speed matters more than program size.
fman is fast, beautiful and extensible. It's also customisable, but you can't change it completely. The reason for this is that customisability costs performance. For example, the Atom text editor is very adaptable but suffers from severe performance issues.
The next point on the list – that I/O should never block the GUI – is obvious for a file manager. The item that follows is more interesting: Have you ever really needed to get something done and the app / OS interrupts you for some updates? You don't care. Manual updates are also tedious. fman addresses this by updating itself in the background similarly to Google Chrome. It does so without unnecessarily straining your system's resources or bandwidth.
Finally, program size – both on disk and in RAM – affects your workflow much less than some extra polish in the other areas mentioned above. Sublime Text for instance is very efficient on resources but has been criticised for its slow development. Part of the reason for this is likely that it is developed in C++ with a custom UI toolkit. All else being equal, fman therefore prefers ready made solutions, even if this increases its size.
The next post explains how these principles affect fman's technology stack. Stay tuned!
Update October 6, 2017: The last Zen item was replaced by a more powerful statement. See the new blog post for details.
Michael started fman in 2016, convinced that we deserve a better file manager. fman's launch in 2017 was a huge success. But despite full-time work, it only makes $500 per month. The goal is to fix this.
Subscribe