Summer of Code 2006
From SubfireWiki
Contents |
Summer of Code Application for the GAT
RE: python
In response to Murray's comment: Python would be the more obvious choice for adding automation API to applications. The method for doing that (the Python C API) is already well-defined and working. Even so, it would be difficult to "encourage" everyone to imlement it.
So I think Python is great for scripting applications in-process, but I see three problems with using the Python/C API as a foundation for building an automation application.
1) The interface is limited to applications written in C/C++ and Python. Jython and IronPython notwithstanding, I think there will be technical problems integrating Mono, Java-GNOME, and C-GNOME apps such that the scripting engine provides a fully interoperable environment. In other words, how feasible is it to generate a single script that copies images from a page in epiphany, loads them into f-spot, and inserts them into a glom app? SWIG could provide some help here, but I don't think adding a new dependency to GNOME would be acceptable.
2) The Python/C API isn't component-oriented. A platform capable of supporting the GAT, needs a proper component model that provides components with queryable interfaces consisting of typed methods. Though I must plead some ignorance of it, I believe the Python/C API would lack the application level typing necessary for the GAT. Of course, this could be coded as necessary.
3) The Python/C API is essentially an in-process mechanism. I could be wrong here, but the API allows either embedding a python interpreter in an application for internal scripting or starting an application from within a python intepreter. What's really needed is an IPC mechanism to allow the GAT to communicate with other apps. Further, to simplify the work of adding scriptability to existing apps, the IPC mechanism should integrate with the glib main loop. DBus provides these facilities.
That said, I'm not fully committed to DBus as the IPC-related backend. What's important to me is that GNOME has an application that can communicate with running applications or daemons so the user can script them graphically. From my perspective, DBus provides the core facilities required for this.
And regarding the acceptance of AppleScript, I would look at it optimistically: even though Apple has no control over or source access to their ISV's code, many of them still implement the interface and provide means for users to script. GNOME actually has source access to most desktop applications, and dbus is already a part of the platform. One would hope that well written patches to GNOME applications that handle dbus messages for GAT during idle cycles would be accepted.
If I get another chance to update my submission...
I should put some links to some of my previous coding work:
Eclipse plugin for JScheme: http://cvs.zclipse.org/viewcvs.py/zclipse/org.zclipse.jscheme/
Winter break work (C, GTK, Glade, autotools): http://cvs.suppressingfire.org/cgi-bin/viewcvs.cgi/csiproject/ There's also a newsforge article about it.
PyGTK frontend for cdlabelgen and gtklp: http://cvs.suppressingfire.org/cgi-bin/viewcvs.cgi/labelator/
Answer to Robert's question about Dogtail
Here's my direct response to Robert's question: Have you investigated Dogtail? No, I had not. However, the goal and design of dogtail (automated testing of GNOME apps) is not the same as the goal of the GAT. The GAT is an end-user tool to graphically "script" simple or even complex actions. That said, dogtail could provide a potential alternative backend to the GAT. I think letting applications provide meanigful scripting APIs via DBUS and wrapping standard GNU/Unix commands will be more beneficial for users wishing to automate tasks without any other applications open.
Original Application
Name: Michael R. Head Email: burner@suppressingfire.org (also suppressingfire@gmail.com) IM: suppressingfire@gmail.com How much time do you expect to have for this project? Roughly 40 hours per week through the summer Please list jobs, summer classes, and/or vacations that you'll need to work around: I am a PhD candidate, so I have my own research to pursue. I set my own pace for that work, though. Hopefully, I'll find some connections between my summer of code work and my high performance computing research.
Please describe any experience you have with:
o C/C++ development I have worked with C/C++ for several years, both in classroom settings, and on larger research projects (XCAT-C++: http://grid.cs.binghamton.edu/projects/xcat.html). Recently, I built a GTK application with Glade and the autotools for a job over winter break, so I'm familiar with those tools, too.
o Scripting languages (Perl, Python, Lisp, etc.) Python is usually the first language I choose when approaching smaller programming problems. I've written a mock GridFTP server, a GUI frontend to cdlabelgen (using PyGTK), and many log processing tools for research papers I've co-authored.
o Windows development Minimal. The last time I had any contact with Microsoft C++ was in 1997 when I was a paper grader and lab assistant for a second semester data structures course.
o UNIX development Extensive. I use Ubuntu exclusively on all of my personal computers, and have used Ubuntu (and previously Debian) for around 8 years. My research area is Grid Computing, and almost all tools are Unix/Linux-based.
o Web development Solid. I have a good working knowlege of the HTML, HTTP, SOAP, XML, and GridFTP protocols and specification. My reseach for school involves benchmarking and improving XML parsers and SOAP toolkits.
Please describe your usage experience/familiarity with the project you are applying for: I've been a GNOME user for years, since I switched from WindowMaker around 2002. I'm a strong adherent to the GNOME philosophy that 'simple is beautiful.' I lurk on a number of the gnome.org mailing lists and have been active in gnome.org's bugzilla.
Please describe any development experience on the project you are applying for: As I mentioned above, I've recently built a C-based GUI program using Glade and the GNU autotools toolchain, so I can get up to speed with the GNOME toolset very quickly. I've been working with component oriented toolkits for several years now for a number of domains: high performance distributed computing, computer-supported cooperative work, and, in a former life, enterprise business software.
Please describe any open source development experience: I am a founding member of zclipse.org, which provides a number of open source Eclipse plugins, the most popular of which is a team-oriented bug tracking tool called 'Insectivore.' I've been a regular bugzilla (on gnome.org, eclipse.org, and formerly ximian.com) and bugs.debian.org for several years, reporting and helping resolve problems whenever possible. I've wanted to become more directly involved with development, but have not had the time. Being granted this summer to work on code would give me that time.
Did you participate in a 2005 Summer of Code project? No. Have you applied for any other 2006 Summer of Code projects? No.'
What school do you attend? How many years have you attended there? Binghamton University (SUNY). I've been here since Fall 2004.
What is your specialty/major at the school? I work in the Grid Computing Research Group here at Binghamton: http://grid.cs.binghamton.edu. In my time here, I've worked on benchmarking, component-ware for grid applications, and applications of intelligent gateways to grid communication protocols.
Any professional/resume or personal/blog URLs you would like to list? Resume: http://www.core.binghamton.edu/~burner/new/res.html
Please describe your proposed project in detail, including deliverables and expected timeline with milestones (answer in detail):
I would like to have the opportunity this summer to build the GNOME Automation tool (GAT). The grand vision is to have a graphical tool that would allow users to built scripts to automate various tasks without having to write a program or use a command line tool. Different operations appear as different blocks which have a number of in-built customizations and some number of inputs and outputs. Blocks connect together to form scripts that can perform complicated actions such as 'download all the images from a web site, saving them to a given folder, and convert them all to png.' One existing tool like this is the Automator tool provided with OS/X (http://www.apple.com/macosx/features/automator/).
OS/X's Automator works because of the AppleScript interface that most applications provide as a convention of the OS/X platform. In other words, there is an existing, well-used component system for which a graphical front-end can be readily built. Unix provides a simple component model a the command line: programs that read from stdin and write to stdout are components that can be customized using various commandline options, and the pipe '|' operator connects them together. Freedesktop.org provides the DBUS desktop bus which provides a simple way for desktop applications to communicate. GNOME Automation's implementation will rely on these two component systems to do the 'heavy lifting.'
There are some challenges to building the GAT on these two frameworks. The Unix component model is too simplistic to provide the features necessary to implement the GAT. The inputs accepted and outputs generated by Unix commands are not 'typed' in the sense that there's no automatic way to know if feeding the output of one command to the input of another command will be sensible. Additionally, the commandline options for each command can wildly change the input accepted or output generated. In order to meet this challenge, the GAT will require each command and its options to be described (using XML), so that each command's interface can be effectively queried and reasoned about. This information is necessary to compute which components' outputs can be connected to which components' inputs, thus preventing user error.
I don't know enough yet about the particulars of DBUS to know if it provides the necessary and sufficient information to build the GAT. My first goal this summer will be the build the basic GUI and write the XML markup described above for a number of GNU tools, such as 'find,' 'wget,' 'mv,' 'cp,' and others so that a number of simple scripts can be run within GAT, including the scenario described in the introduction.
This could be implemented in C or Python. I think it Python would reduce the development time, but if my mentor prefers C, that would be fine, too.
A potential 12 week schedule: Week 1: Set up glade, autotools, connect to gnome CVS, build sketch in Glade of the GAT. Get UI some feedback from mentor and others. Week 2-4: Implement the graphical component block and connector widgets in GTK. In parallel, describe (in XML Schema) the model for unix command markup and build the type deduction system for component inputs and outputs. Week 5-8: Write the markup for a number of simple scripts. At this point, the GAT should be working with the Unix command line, and it should be possible to graphically automate the task of downloading all the images from a given web site and converting them to png (with GAT running 'wget' and 'convert'). Week 9: Investigate DBUS. Not many user-level applications use this, but it should be possible to work with gaim's dbus interface or possibly NetworkManager's dbus interface. Week 10-12: Based on Week 9's investigations, build a dbus interface such that it's possible for a GAT user to automate the task of sending a file to a selection of gaim buddies, or automate the task of synchronizing a folder when a network connection becomes available via NetworkManager.
Future goals: save the automation for later use, generate shell or python scripts from a given automation, implement dbus interfaces for more applications so they can be automated, too, investigate Openoffice.org's UNO component model.
Why are you well suited to complete this project? I've been programming for more than a decade. I've worked with a variety of languages and libraries. I've implemented custom widgets and worked with GTKs drawing primitives which will be necessary to build the GUI quickly. I've studying type systems and worked with prolog and haskell, which will help in building the deduction system. I've worked with autotools and GTK with C and Python, so I can get up to speed very quickly. Given the time, I can suceed in the technical aspects of this project. My goal in applying for the 2006 summer of code is to have a chance to become more directly involved in the desktop platform that my friends, family, and I use and love.
