Enso Developer Prototype

Our Products Software Development

Ever since we launched Enso, we’ve been getting feedback like this:

— When are you going to come out with the Python API for commands?
— I’m looking for a way to extend Enso.
— Is it is possible to enrich Enso with custom commands?
— I heard there will be support to create your own commands. How far off is this?
— An SDK would be wonderful!
— Being a Python developer, I am very interested in the ability to expand Enso.
— Would you have any available API’s?

The entire Humanized team is extremely proud to announce that the answer to whether is “Yes“, and the answer to when is “Now“! Today marks the release of Enso Developer Prototype, which lets anyone develop commands for Enso. It’s free and it’s available for download.

To develop for Enso, you’ll need the above download and a programming language that can do XML-RPC. Any programming language will do. We use Python, but feel free to use whatever you feel most comfortable in, whether it be Ruby, C++, or a .NET language.

Head on over to the Enso Dev Wiki to find HOWTOs, commands/code snippets, and the API reference. At the moment, we only have examples for Python, so we would love it if you’d help out and share your experiences and code for other languages. It’s a normal wiki, so feel free to dive in.

Why do we call it a prototype? Because we’re pretty sure that Enso’s got some big—and awesome—changes coming. We will make changes to the API as we improve the Enso core; we’ll try to keep it backwards-compatible but we can’t promise anything. But we wanted to get something out there for all of you who’ve been wanting to add your own commands. To paraphrase Jono’s recent article on OSS software, the strength of a program—especially a universal program like Enso—is the strength of its extensions and its community. The Enso Developer Prototype is released in honor of you.

Happy Enso day. Go forth and create!

Awesome. I finally got off my arse and bought Enso for this!

Exciting news, congratulations, love the wiki aspect.

I don’t have windows, so I can’t get massively excited by this like I want to, but the second I saw the API I knew a better way to do it, that I really wanted to implement.

I’ve put this up on the wiki on the Design Patterns page, basically it provides a class that can be inherited from which will register all the methods of that class that don’t begin with ‘_’ with a central command handling object, which is then made the XMLRPC handling object.

It derives the type of the postfix by introspecting on the signature of the methods, and uses the docstring as a description. I want to add support to either include semantic data in the docstring, or to have the developer set properties on their method. (Yes, you can set properties on a method since it’s just an object.)

Cool, thanks a lot Alexander! Congratulations for being the first person outside of Humanized to contribute sample code.

We wanted to keep the basic API as simple as possible, with the intention that people could build what they wanted on top of it.

The architecture you’ve described has a lot of advantages. Thanks for sharing it!

This is awesome. I can’t wait to start building some extensions. As great as python is, for those of us who prefer ruby, I have added a short example to the wiki. I will add more later after I learn a bit more about the API.

Thanks Jono!

I switched to using a decorator to set properties on the method (so that it consolidates it all in one place and so I don’t have to write a parser for a docstring format). It has some default values it will use if you don’t set certain properties, and currently a method has to be wrapped in the decorator to be useable. As an upshot, it’s quite straight forward to wrap a regular function with the decorator and pass it to EnsoCommandHandler’s register method, so method’s don’t have to part of a wrapped class.

Thanks, Nick! It’s good to have the Ruby crowd on board, too. We love Python, but that doesn’t mean we hate Ruby :)

Thanks, Humanized! This is exactly what I was hoping you were going to release when you first started hinting at the Beta products.

And thanks, Nick. With your example as a base, I was able to write a quick song tagging extension with no trouble.

Well, with a little trouble. I have to remember that the command name changes when the type of postfix changes…

Well I decided to write a Python Command Server(link is to the enso wiki) that simplified command creation a little bit. Instead of having to create a thread, setup the XMLRPC and run an instance of python per command you wish to add the Command Server lets you add any number of commands to the Servers instance of python and have them work with Enso.

This is very useful IMHO since threads are a limited resource, and each python instance takes up ~6 megs of RAM. Also the Command Server has a bulitin reload commands command, so you can make changes or add new commands without having to restart the Command Server.