Extending the Nautilus scripts support

We all know now about Nautilus Actions, and I think people agreed, while discussing its inclusion in 2.14, on having this much better integrated into Nautilus itself. And, you know, I am in a quest to provide UNIX power to all kinds of users :) So, I’ve been wondering for a few days about some ideas, which can be summarised in a mix of nautilus-actions, Automator and, of course, Nautilus.

What I’m thinking is about the Scripts menu in Nautilus context menu to provide better tools to write scripts. One, the simplest, is to create scripts directly (by allowing the user to enter a command or a full script in any language), and allowing the user the kind of tweaks nautilus-actions offers, like specifiying for which files/protocols to show the script in the menu. The other is to provide a mechanism for writing scripts like what Automator does.

In Automator, there are ‘actions’, which are just calls to AppleScript/Automator modules (and which could be calls to D-BUS services and normal commands in our case), and then there are ‘workflows’, which are combinations of actions in a specific order and with specific input parameters/sources. In our case, a XML file describing all the actions and their relationships, and an accompanying command-line tool to run those files through, could be enough for users to write scripts without even knowing a thing about programming. Experienced users could also define more actions, by just specifying commands to be run. And applications could provide even more actions, via D-BUS.

As you can see, my ideas are not still very clear, so would appreciate any opinion on how this could be done, or if it should be done at all.

4 thoughts on “Extending the Nautilus scripts support”

  1. Have you thought about using a data-flow paradigm? Software could then provide ‘blocks’ which could be assembled by users in a drag and drop fashion. No need to know anything about the calling format of command line programs and clear presentation for a (perhaps novice) user trying to understand what is happening. http://www.jpaulmorrison.com/fbp/ provides a good description of the paradigm which also, to an extent, underlies current research into web-services (part of my research field)

  2. Joe, yeah, that’s what the actions are. We just need a layer that maps D-BUS services and command-line tool based actions (described in XML files, for instance) to an “Action” structure. Then, we can easily build blocks for workflows

Comments are closed.