I have the honour to present you Atomato, a scripting and automation tool for GNOME. The idea behind it is to allow non programmers to build their own scripts for automating tasks without having to write a single line of code, much like Apple’s Automator.
There is very little code yet, but thanks to the hacking session on Wednesday at Vilanova Park, it is starting to take shape. The idea is, first, to write a library that loads all actions (currently the actions are DBUS methods, but the idea is to have more action providers, like simple commands or small scripts) and is able to make calls to those actions. Once this library is done, we’ll have to write a GUI to allow users to concatenate calls to actions in a script (workflow in Apple’s terminology). For that, we need to look at S-Flux, a tool developed by Christian after my call for UNIX Power for Desktop. The S-Flux GUI is a bit ugly, since Christian just did it as a proof of concept, but the basis are there, so I think we can reuse some of his code.
After that, we really need applications to provide services, so once we have all the basis going, we’ll start trying to convince people to provide services from their applications via DBUS (or whatever is better), so that we can, once for all, really provide what other desktops (Apple and AppleScript, KDE and DCOP) have been providing for a long time. We failed with CORBA/Bonobo because people disliked CORBA, so let’s hope that now that most people are ok with DBUS, and given that KDE is switching to DBUS, we won’t have any real problem about it.
Of course, there are still some details to be taken care of, like getting the list of all (active and inactive) DBUS methods, which right now is not possible without activating them all. Or how to discard some of the DBUS methods that have no purpose in a user-oriented scripting applications (things like GetConnectionUnixUser method on the DBUS interface, for instance). We have been talking about using a separate way for getting the list of methods, having apps create a XML file or whatever with the list of methods they want to provide to Atomato, instead of just having Atomato use DBUS to get all of that app’s methods. That would solve lots of problems, since Atomato would just need to read those XML files on startup and then activate services as they are really needed.
Also, about having apps provide DBUS methods, there is a little problem, which is that apps need to take care of just activating the DBUS interface when called from a 3rd party app, and not open the application window if not needed. Not a big problem I guess, but something to take care of. For some simple services, we are planning to write our own DBUS services (see the services/imaging service in Atomato source tree), which should provide most of the basic actions (copy/move files, image management, etc).
So, enjoy it, and if you have any good ideas, please let me know.
How about using wsdl files to describe the methods, don’t know if it’s possible to descibe a DBUS method/service but if Atomato at least supports them it would be an easy way to ‘drop in’ support for webservices.
Yeah, using WSDL (or something similar) is the idea, so yeah, WSDL might be the correct thing to use, although it might get things too complicate. I’ll have a look
KDE has a SoC projects about this as well, called “workflow”. Maybe it would be nice if there was some kind of compatibility between the two.
Hi, a really promising and needed project, some random concerns/ideas/delirious :
* It seems very difficult to connect (pipe) the different actions on the workflow, I suppose you would define some types of input and output data like (FILE,URI,NUMBER,TEXT) and the gui would allow to connect the actions according to the types that the action supports, like an epiphany action that takes an URI and download it to a FILE, and connects to a ftp action that takes the FILE and a URI where to upload that file…
* Also in the case of actions that are scripts with multiple commands, who would check for the existence of those commands, the own action incorporating m4 files, or by centralizing all these actions in one package that checks for all commands on the configure…
* Apart from the above issues that are atomato related, just the applications begining to export their abilities as dbus methods would open lot of possibilities, e.g. gimp export a dbus method that takes an image and returns that image with the red-eye effect corrected, then I could cook up a python script to upload images to my www gallery that would red-eye correct them if this gimp dbus method is present.
* Also I think before all applications begin to export dbus methods in an arbitrary way, there should be a freedesktop naming policy that defines common methods in an object like (open,save,close) and common objects like IMAGE,SONG,MOVIE,DOCUMENT,CONTACT,ARCHIVER or BROWSER, so calling BROWSER->download_url($url); would result in that method executed by epiphany in GNOME and konqueror in KDE, as both registered for that fd.o defined method. Other standard calls could be ARCHIVER->zip($files) or CONTACT->is_online($name), IMAGE->resize_image($image) , that would be done by the applications that registered for them.
What about using RDF/OWL documents like I’ve done in S-Flux? Schemas are described at http://sflux.sourceforge.net/schema.php
Great news !
If I understand well, the aTomato scripts created by the user, will be exported to DBUS too, so other applications can list and activate them too. I’m of course thinking about integrating it in Nautilus-actions[1] once it will be ready ;o)
First, I have to document myself about DBUS…
[1] http://www.grumz.net/taxonomy/term/2/9
I’ve quickly looked at Atomao code and it seems to me it lacks of a couple of features that instead are present in S-Flux:
1) There’s no mimetype->operation association. This means you can’t filter out the operations suitable for a document. Probably we can go beyond the simple link mimetype->operation extending it to other kinds of objects (devices or so). All we have to do is to provide a URI to every object (maybe they already exists, I don’t know…sorry).
2) In my opinion only DBUS in not enough. I mean probably giving the opportunity to expose to atomato command line applications too could be really useful. Linux systems are plenty of excellent command line utilities and letting newbies users a simple way to use them could be a great thing.
Do you agree?