[Clipart] Re: Clip Art Browser
eady at galion.lib.oh.us
Thu Aug 25 08:51:18 PDT 2005
Jon Phillips wrote:
>> 12.) Some kind of browse by category would be nice.
>>I have absolutely been wracking my brain about how to do the interface
>>for this. If I'm willing to make the interface target OCAL in
>>particular, and not arbitrary clip art repositories, its not
>>difficult, but if you want to connect it to arbitrary repositories
>>(such as custom local ones) that may have differing category
>>structures, providing a browsing interface becomes more challenging.
>>For now, the best solutions I see are to either hard code OCAL's
>>category structure, or let users only browse one repository at a time.
>>Right now, I'm trying to implement the former. There's some other
>>more complex issues too, including the performance of trying to browse
>>ocal over the network, but they're not worth going into on the list.
> Maybe make this a page in the notebook, but save it for last, right. :)
> Does anyone have any ideas for this?
Yes. Do what we were planning anyway for eventual l10n:
Define the category hierarchy in an XML file. Each collection could
have its own. This way, you do have to create the hierarchy for each
collection, but it does not have to be hardcoded.
Say, for instanced, that Bob's Clipart Collection has two toplevel
categories: full-color, and one-color. Within the one-color
category are two subcategories: silhouette, and shaded. (I have
deliberately made up a categorization scheme that is very different
from OCAL's, so we don't get hung up on the details of the specific
hierarchy.) There might also be some images loose in the one-color
category that have not been categorized yet as to their shaded or
The XML for this might be something like the following:
<clipart-hierarchy collection="Bob's Clipart Collection">
<category name="Full-Color Images">
<category name="One-Color Images">
Then the images in Bob's collection need to be tagged with those
keywords. The hierarchy also could be distributed with the
collection, if Bob is willing to do that, or you could include
it with the browser or make it available separately.
We intend to create something along these lines for the Open
Clip Art Library anyway, although we haven't gotten around to
it yet. Actually, we intend to create different ones for
different target locales.
The above does not cover the filtering/exclusion of images,
something we had discussed handling in our l10n hierarchies.
Anyway, the clip art browser can have one of these hierarchies
installed for each collection, and then it can just read those
instead of having anything hardcoded.
Allowing the user to create or change this hierarchy on the
fly by dragging and dropping "folder" objects around and stuff,
with the resulting changes being written to the XML hierarchy
file, is a natural improvement that could be added later, but
this is probably not necessary right now. Along similar
lines, dragging individual pieces of clipart from one folder
to another could cause changes in the embedded keywords...
but that is fairly ambitious and for now should probably just
be filed away under TODO-post-1.0 or somesuch.
> Never forget that programmers are lazy!
That is the greatest of the three virtues of a programmer.
Of the others, I'm not sure whether the impatience or the
hubris is the more important, but I'm pretty sure the
laziness is the most important of the three.
More information about the clipart