Lua API

September 2019 · 7 minute read

Hello, everyone! I’m happy to announce the release of Marta 0.7.

Also, there are two more project news. Keep reading :)

Why an API?

Before I started investing time in Marta, I tried a lot of macOS file managers. All of them were quite mature applications with lots of features. However, it doesn’t matter how much batteries are included – one day you realize the functionality you need the most is not there.

For some reason, macOS applications rarely have plugin APIs. Even system applications are made with a strong will against any external modifications. As a result, every time you need a feature, you have to ask the developer to implement it. If you are lucky enough, your request will be prioritized somehow and put into a long queue of tasks. God knows how much time it will take to satisfy your demand. A week? A month? A year? Glad if so.

As a software developer, I’d happily do the thing I need my myself – and share it with the whole world, as I believe that if I need something, probably there is someone else who needs the same. That’s why Marta has an open API. Everyone can write plugins for Marta and publish them under any conditions.

What’s wrong with Swift?

Starting from 0.1, Marta had a Swift API. It allowed not only to add new actions and context menu items, but also to monitor different kinds of events, and even to add new file system implementations. Moreover, as Swift is a native language, the performance was outstanding. However, I was not 100% happy with the result, as there were several drawbacks:

  • Swift changes rapidly. Until Swift 5, there was no ABI backward compatibility, so all plugins had to be recompiled each time Marta switched to the next Swift compiler version.
  • Library evolution support is still not here. As a Marta developer, I wanted to provide a stable and backward-compatible plugin API. Unfortunately, I couldn’t do it without enabling experimental features.
  • Making Swift plugins required installing Xcode – a powerful but quite a massive piece of software. Not only had you to set up it, but you also needed to get used to the IDE to make something meaningful.
  • You had to either distribute binary versions of plugins (built for some specific version of Marta) or share the XCode project.

While using Swift seemed natural at the time of 0.1, it became clear that it contradicts with Marta philosophy: everyone should be able to write a plugin in a couple of minutes. Also, sharing plugins should be easy – ideally, a simple plugin should consist of a single source file. I spent a lot of time exploring alternatives and finally chose Lua.

Lua API

Lua is an embeddable scripting programming language. Here is a list of things I like about it:

  • Lua is simple and predictable. If you already know some procedural programming language, learning it will be easy. Its official site has a reference manual containing everything needed.
  • Unlike alternatives, such as Python or Ruby, both interpreter and runtime library are incredibly lightweight.
  • Lua is mature. Its development started in 1993, and the last major version, 5.3 came in 2015. That doesn’t mean the language is dead – the actual release (5.3.5) was published exactly a year ago.
  • Lua is robust and battle-tested. It’s heavily used in the game industry as a scripting language.
  • Lua has outstanding interoperability with C – and with any languages that expose C API and allow to link against C headers. For example, it’s possible to write a plugin in Swift or Kotlin/Native.
  • There is no GIL. You can achieve true multi-threading with Lua, as long as threads don’t share any data directly.

Here is an example of a trivial plugin written in Lua. It declares an action that displays the “Hello, world!” popup message.

plugin {
    id = "marta.example.helloworld",
    name = "Hello world",
    apiVersion = "1.0"
}

action {
    id = "action",
    name = "Hello world",
    apply = function(context)
        martax.alert("Hello, world!")
    end
}

The Lua API already has most of the Swift API features. The only significant part that is missing is the ability to create custom file systems. It’s in progress, and I expect it to come in one of the upcoming releases.

Marta supports LuaRocks dependencies out of the box, so if you feel you need to include a library dependency, it’s as simple as running:

luarocks install --tree rocks <package name>

The updated API section contains the API reference and a few tutorials. More of them to come!

Let the power of Lua be with you! 🌜

Marta is coming to Patreon!

Three years passed since I started working on Marta. In the very first blog post, I described my intention to sell it when the application reaches production quality. Strictly speaking, the 1.0 release is still somewhere in the future, but Marta is already in good shape. What stops me from putting a price tag on it?

There are two reasons. The first one is that I want Marta to be fully competitive. Admittedly, its performance and lightweight nature alone make it a good competitor. However, I want a bit more checkmarks in the “functionality” section. Of course, I’m working on the missing functionality.

The second reason is that I’m not a salesman; I’m an engineer. My goal is not to make as much money as possible, but to create an outstanding file manager. Selling Marta will introduce a lot of side work, including accounting and promotion. And I feel it’s much efficient for me to spend more time on the project itself.

That said, Marta development takes quite a lot of time and mental energy, and I think it’s fair to get a reward. So I opened a page on Patreon. I will be grateful if you support me by subscribing to the project.

There is also a bonus. If/when Marta becomes a paid app, every subscriber who donated at least $15 over the time will receive a perpetual license (with free updates, of course). There’s a chance, though, that donations from Patreon will be enough for keeping the sustainable development. In that case, I will be able to give Marta away for free forever.

One more thing

I’m not a big fan of the Internet in its current state. I don’t like when people use JavaScript when a simple HTML is enough. I don’t understand why CSS files weight several megabytes. I generally prefer ‘classic’ web sites over modern web applications.

That’s why this web site is not like many others. It’s completely static, and even if you turn off JavaScript, nothing will really change. Marta distribution is accessible via a direct link – no need to sign up to some boring newsletter to get the binary. I like this kind of simplicity. And I feel honest to my users.

I used to use Jekyll as a static blog engine. While it seemed pretty convenient to use at first, Jekyll often crashed for different obscure reasons each time I upgraded some Ruby component. I tired of fixing the build, so I decided I should try something different.

So I gave a chance to Hugo, and I loved the experience. It comes as a single binary, so I don’t have to worry about broken dependencies anymore. It’s extensible – I easily migrated all of my custom plugins to Hugo’s shortcodes. I also liked how fast Hugo builds the site; it took around 5 seconds for Jekyll to assemble it, and now the build is almost instant.

I had to adapt the existing web site to work with Hugo, and I took the opportunity to refine the design a bit. I hope you like the result. :simple_smile: As a nice bonus, now you can turn on the dark mode. Just press on the ☼ icon on the top menu, and feel the difference.

Feel the dark side of Marta! 🌚