Have you submitted this yet? I have several suggestions for you.
The first one is to focus only on what you are trying to achieve with
the SOC project. You should be explicit in detail and quite formal in
your proposal. You talk too much about so many different projects and
possibilities. This is good for brainstorming, but maybe not for this
proposal. You should be affirmative in saying exactly what you will do
and then when there are areas where experimentation is needed, be
affirmative about these as well yet allow for possibilities.
It is cool you would like to undertake this, as it needs to be done.
I'm going to go into the text now to go through your points.
On Tue, 2005-06-14 at 23:57 -0400, Greg Steffensen wrote:
> 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
> Creating an openclipart.org GUI for Inkscape
I think this title is better. You might re-title:
Creating a Generalized Graphical User Interface to the Open Clip Art
Library for Inkscape
> This is a proposal to implement an interface to the open clipart
> library (openclipart.org) in Inkscape,
Open Clip Art Library
> 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.
This is good, but I think you should focus much more on the idea
straight up front, and then explain your concepts. You can sum up
yourself in a bio at the end of your proposal.
> 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
> 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.
Yeah, I think you should firm this up.
> 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
> (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, 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.
Maybe you should also provide the INX. Cool that you made a prototype.
You might want to take out the informal language.
> 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.org server 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
I think you hsould just say that you are going to build this as an
extension rather than wandering through other areas. You might sum up
the options in a sentence, but not a really long para.
> Ok, now I'll summarize the most obvious issues that appeared while
> building the prototype. The main one is that the openclipart.org
> website 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.
Start contributing to it is the preferred way of asking ;)
> 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
Ok, yes, I agree that the Open Clip Art Library needs some help on the
site, but your proposal is about making a GUI to the library and not the
OCAL site. I think you should focus only on the GUI. Also, there is code
being written to change the site and run on Bryce's DMS:
You should be able to connect with DMS through the SOAP interface.
> 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.
DMS will control this...
> 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).
Ok, you are talking about a lot of ideas. I think you should cut these
and just talk about the GUI to the clipart library.
> 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
Others can speak on this better...Inkscape others?
> The other major bug that the prototype demonstrated seems to be caused
> by gnome svg rendering support (librsvg, I assume). Many of the
> openclipart.org files 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.org website provides,
> instead of the actual svg (the actual SVG is inserted into the
> document, of course).
File bugs at openclipart.org for these problems please.
> I would also write a tutorial for this feature, and try to publicize
> any new APIs for the openclipart library that I developed.
That would be great. You would need to work with Inkscape and Open Clip
Art developers more than likely, so all this can be worked up.
> 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.
Yeah, I think you should shrink this document in half and remove the
liberal language in favor of details and explictly the task you are
Please email back if any questions. It would be most excellent to get
you working on this. Also, I wanted to say that it would be great if any
interface to the Open Clip Art Library would be able to both connect to
the SOAP web service to go through the library, or if clip art files are
installed onto one's computer, through a yet-to-be-determined commong
place (/usr/share/clipart/*) through packaging (RPM, emerge, deb), or
another process, those should be visible through this interface as well.
Ok, please check out the Open Clip Art Library's wiki as well as
Inkscape's. There is already much info. on this. Also, hop into the chat
channels for each project to discuss in more depth.
USA PH 510.499.0894
Open Clip Art Library (www.openclipart.org)
CVS Book (http://cvsbook.ucsd.edu)
Scale Journal (http://scale.ucsd.edu)