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.