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:<br>
<br>
------------------------------------<br>
Toward an Implementation of an Intuitive Visual Mapping of Remote Vector Graphics Repository Access Interfaces<br>
<br>
OR<br>
<br>
Creating an <a href="http://openclipart.org">openclipart.org</a> GUI for Inkscape<br>
<br>
This is a proposal to implement an interface to the open clipart
library (<a href="http://openclipart.org">openclipart.org</a>) in Inkscape, as suggested by the &quot;Create a
Clipart Library interface&quot; item on the Inkscape Summer of Code ideas
page.&nbsp; I'll introduce myself, describe the technical design I'd
implement, and list some remaining technical questions and ways a
mentor might help.<br>
<br>
I'm a 22 year old computer-science major at the University of Richmond
(I'll be a senior this year).&nbsp; I'm also a open-source geek.&nbsp;
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.&nbsp; I build websites for fun and cash.&nbsp; I've tried many
distros, but have been happily using Gentoo on my own box for about 6
months now.&nbsp; 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.&nbsp; 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!).&nbsp; I use GTK constantly, and
as I mentioned, I've contributed to Dia, so I know how to get around
gnu-ish code.&nbsp; Philosophically, I align myself with the FSF,
though I don't consider myself a zealot.&nbsp; <br>
<br>
Blah, blah, blah.&nbsp; Let's talk turkey.&nbsp;&nbsp; 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.&nbsp; I just threw it up at the site I'm using to host my
distributed computing project for convenience; you can download it at <br>
<br>
<a href="https://developer.berlios.de/project/filelist.php?group_id=3863">https://developer.berlios.de/project/filelist.php?group_id=3863</a><br>
<br>
(the tgz is listed under Inkscape, obviously).&nbsp; 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
<a href="http://openclipart.org">openclipart.org</a>,&nbsp; then writes the doc back to standard output,
with the clipart inserted.&nbsp; It should be installable with a
bare-bones .inx file like any other extension.&nbsp; The gui is GTK, of
course, via libglade.&nbsp; Its pretty minimalistic, but should show
that this project will not be difficult.<br>
<br>
I currently see two ways to build this thing; either as an extension,
as the prototype is, or integrated into the main codebase.&nbsp; 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.&nbsp; 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).&nbsp; 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.&nbsp; Either way, the code will have to
query the <a href="http://openclipart.org">openclipart.org</a> server somehow, download the clipart, and
insert it into the document.&nbsp; And, either way, the most natural
way to provide the basic UI seems to be through the new Iconview class
in GTK 2.6.&nbsp; <br>
<br>
Ok, now I'll summarize the most obvious issues that appeared while
building the prototype.&nbsp; The main one is that the <a href="http://openclipart.org">openclipart.org</a>
website is clearly in need of a technical tuneup.&nbsp; The keyword
search is barely functional, and performance is already iffy.&nbsp; If
they'd be willing to let me, I'd prefer to actually work on the site
myself.&nbsp; 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.&nbsp;
Hopefully, I could also add some search results caching to speed it
up.&nbsp; 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.&nbsp; This should be easy; it just requires a storage
directory and an index file.&nbsp; <br>
<br>
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.&nbsp; 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).&nbsp; 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.&nbsp; <br>
<br>
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).&nbsp; 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).&nbsp; Searching by
clipart author is also desirable (though not in the default interface),
to help people find work of similar visual styles.&nbsp; The UI should
make basic metadata available (the clipart title as the icon caption,
and all associated keywords visible as a tooltip, for example).&nbsp; A
list of the most recently used clipart should be available for
convenience.&nbsp; Clipboard copying and large previews of icons will
be available through a right-click popup menu.&nbsp; 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).&nbsp; <br>
<br>
The conceptual questions I've currently noticed about the UI include
where clipart should be inserted into the document, and at what
size.&nbsp; 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.&nbsp; 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).&nbsp; Gnome HIG compliance is also
intended.<br>
<br>
One feature that may be necessary is XSLT-based conversion of incoming
clipart to a more standard Inkscape-friendly format.&nbsp; 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.&nbsp; It is probably solvable by modifying the clipart
object to use an svg &quot;g&quot; object instead of &quot;svg&quot; or something like
that.&nbsp; Cleanup like this will be one major area that mentors could
advise me on.<br>
<br>
The other major bug that the prototype demonstrated seems to be caused
by gnome svg rendering support (librsvg, I assume).&nbsp; Many of the
<a href="http://openclipart.org">openclipart.org</a> 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 <a href="http://openclipart.org">openclipart.org</a> website provides,
instead of the actual svg (the actual SVG is inserted into the
document, of course).<br>
<br>
I would also write a tutorial for this feature, and try to publicize any new APIs for the openclipart library that I developed.<br>
<br>
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.<br>
<br>
Anyway, sorry to go on for so long, but I figured more detail was
better than less.&nbsp; I'm actually a reasonably fun guy, sorry about
the stodgy tone of this app, just trying to give you the info you
want.&nbsp; I'm really a free software nut, and have a lot of hope for
its ability to kickstart the economies of the developing world.&nbsp;
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. <br>
<br>
Thanks!<br>
-----------------<br>