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.
Great Idea! Did you check out “sprog” ? It is something _very_ close to automator but based on Perl/Gtk+2.
Rock on!
Let’s go into brainstorm mode 😉
I think will be great has a way to autamate stuff, but it should be easy to create automation.
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)
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