Hi, I'm getting my application in really late, and Google isn't working for some reason. My name is Greg Steffensen, I'm an undergrad at the University of Richmond, and here's the text of my application:
------------------------------------ Toward an Implementation of an Intuitive Visual Mapping of Remote Vector Graphics Repository Access Interfaces
OR
Creating an openclipart.org http://openclipart.org GUI for Inkscape
This is a proposal to implement an interface to the open clipart library ( openclipart.org http://openclipart.org) in Inkscape, as suggested by the "Create a Clipart Library interface" item on the Inkscape Summer of Code ideas page. I'll introduce myself, describe the technical design I'd implement, and list some remaining technical questions and ways a mentor might help.
I'm a 22 year old computer-science major at the University of Richmond (I'll be a senior this year). I'm also a open-source geek. To date, my personal free software contributions are limited to a patch to add fixed-aspect resizing of elements to the Dia diagramming program (if you'd like me to send you the patch for inspection, let me know) and a wrapper to allow easy use of the IE7 javascript library within Zope. I build websites for fun and cash. I've tried many distros, but have been happily using Gentoo on my own box for about 6 months now. I'm originally a self-taught programmer (I started on PHP, but I haven't used it for years, promise!), and am now most of the way through my school's CS program, and am doing summer research on the security of distributed computing with one my professors currently; for that work, I'm writing a custom distributed computing framework that I'm GPLing, based on Python and Postgresql. My preferred language is Python, but I consider myself competent in Java, C and PHP too (but I haven't used PHP in years, promise!). I use GTK constantly, and as I mentioned, I've contributed to Dia, so I know how to get around gnu-ish code. Philosophically, I align myself with the FSF, though I don't consider myself a zealot.
Blah, blah, blah. Let's talk turkey. I've coded up a quick prototype of this project in Python, more as a demonstration that I'll actually be able to do this than as a preview of the actual solution. I just threw it up at the site I'm using to host my distributed computing project for convenience; you can download it at
https://developer.berlios.de/project/filelist.php?group_id=3863
(the tgz is listed under Inkscape, obviously). I didn't have time to recompile Inkscape with support for extensions (yeah, yeah, save your Gentoo jokes), but it should work like a normal Inkscape effect extension; it takes an inkscape svg doc on standard input, puts up a gui for the user to search for then select clipart from openclipart.org http://openclipart.org, then writes the doc back to standard output, with the clipart inserted. It should be installable with a bare-bones .inx file like any other extension. The gui is GTK, of course, via libglade. Its pretty minimalistic, but should show that this project will not be difficult.
I currently see two ways to build this thing; either as an extension, as the prototype is, or integrated into the main codebase. The advantages of doing it as an extension are that its more likely to be robust (it won't affect existing code, and should be easier for the maintainers to review), it can (optionally) be developed in a dynamic language (resulting in faster development and making it easier for others to patch and extend), and it will be easier for other projects (such as Dia or Kivio) to take advantage of the code. The main advantages of integrating it into the codebase are performance, tighter UI integration (the interface can appear as a child window within Inkscape), and wider distribution (anyone that can run Dia can run it, as opposed to needing to have extensions enabled and Python installed as well). Currently, the extension route looks preferrable (performance is a total non-issue and I expect the vast majority of Inkscape users to have Python), but either approach should be doable without too much difficulty. Either way, the code will have to query the openclipart.orghttp://openclipart.orgserver somehow, download the clipart, and insert it into the document. And, either way, the most natural way to provide the basic UI seems to be through the new Iconview class in GTK 2.6.
Ok, now I'll summarize the most obvious issues that appeared while building the prototype. The main one is that the openclipart.orghttp://openclipart.orgwebsite is clearly in need of a technical tuneup. The keyword search is barely functional, and performance is already iffy. If they'd be willing to let me, I'd prefer to actually work on the site myself. I love doing database-based websites, and I'd be able to add a cleaner REST-based API for this and other code to use. Hopefully, I could also add some search results caching to speed it up. Which brings me to the next issue; I don't want this fancy new feature to kill the openclipart folks' bandwidth and run up their hosting bill, so the most important new feature to add is probably a way to cache clipart data that past searches have already returned locally. This should be easy; it just requires a storage directory and an index file.
Along those lines, I'd probably also try to get the openclipart people to give each clipart a unique id associated with their system; it appears that all clipart currently has unique filenames, but its hard to be certain since they organize it into hierarchical namespaces. Even if so, they probably ought to be giving the files a numerical id in addition to a filename anyway (assuming they aren't already; I didn't find any, but didn't search exhaustively). That would make caching past retrievals locally technically simpler, would make the most likely to be used clipart available even when network access is unavailable, and would significantly reduce the load on the servers.
In terms of the UI, I'd like to give people the ability to search by keyword or browse by categories (I certainly am not advocating that they get rid of the hierarchical structure entirely). I'd also provide simple boolean searching logic (AND, OR, NOT), which could be implemented with or without server access (although its easier on the clients and server if its done on the server). Searching by clipart author is also desirable (though not in the default interface), to help people find work of similar visual styles. The UI should make basic metadata available (the clipart title as the icon caption, and all associated keywords visible as a tooltip, for example). A list of the most recently used clipart should be available for convenience. Clipboard copying and large previews of icons will be available through a right-click popup menu. To insert clipart into their document, I intend to support dragging-and-dropping (this should be possible regardless of whether the interface is implemented as an extension or in the main codebase) or through basic icon activation (double-clicking, etc).
The conceptual questions I've currently noticed about the UI include where clipart should be inserted into the document, and at what size. Through a dragging-and-dropping interface, it may be possible to place clipart near the drop location, though I am not yet certain of this. Otherwise, placing it near the center of the document, with dimensions noticably less than those of the whole document, seem like reasonable defaults (placing it at the center will, of course, require arithmetic). Gnome HIG compliance is also intended.
One feature that may be necessary is XSLT-based conversion of incoming clipart to a more standard Inkscape-friendly format. The prototype seems to already be running into problems in this area; attempting to drag the new clipart object on the canvas makes my Inkscape 0.41 freeze, unless you save the modified canvas as Inkscape SVG beforehand. It is probably solvable by modifying the clipart object to use an svg "g" object instead of "svg" or something like that. Cleanup like this will be one major area that mentors could advise me on.
The other major bug that the prototype demonstrated seems to be caused by gnome svg rendering support (librsvg, I assume). Many of the openclipart.orghttp://openclipart.orgfiles cause my Gnome 2.10 to freeze when rendered by my app or Nautilus; Inkscape renders them fine, so I'm assuming the problem is in the SVG renderer, and for now I'm working around it by displaying the PNG images that the openclipart.orghttp://openclipart.orgwebsite provides, instead of the actual svg (the actual SVG is inserted into the document, of course).
I would also write a tutorial for this feature, and try to publicize any new APIs for the openclipart library that I developed.
The things that a mentor would be able to help with include Gnome HIG advice (I have no familiarity with it), insight into the Inkscape renderer (to help solve any bugs related to merging two svg documents, as described above), and information on how to make the feature as widely available as possible.
Anyway, sorry to go on for so long, but I figured more detail was better than less. I'm actually a reasonably fun guy, sorry about the stodgy tone of this app, just trying to give you the info you want. I'm really a free software nut, and have a lot of hope for its ability to kickstart the economies of the developing world. This feature in particular is one that, while not technically very interesting, would probably be REALLY appreciated by your users, particularly the less technically adept ones that appreciate conveniences; if there's a single feature on your list that is likely to increase Inkscape's user base, I think this is it.
Thanks! -----------------