[Clipart] Re: Clip Art Browser

[Jon Phillips]

Please, don't forget to reply to the lists...how else can other people
learn and help out? Replies below on and on the lists.

Replies below...

On Wed, 2005-08-24 at 21:03 -0400, Greg Steffensen wrote:
> Hey, glad its working.  Some of your points are related, so I'll
> address those together.
> 
> 
>         1.) The first time the app loads, there should be all image
>         loaded, or
>         some kind of random image, or some kind of text that says
>         search for 
>         what you need...basically, users need help.
> 
> Good idea.  Loading all images would take an unreasonable amount of
> memory, but a text prompt in the results pane is very doable.

Ok, maybe just load then like the last search, or some random search, or
random images. The text as well should be included to make it more
friendly IMO.

>         2.) When dragging in clip art, could it land in Inkscape where
>         it is
>         dropped? Is this an Inkscape or a Clip Art Browser issue?
> 
> This is an Inkscape issue.  I've been trying to fix this, and I
> believe the relevent code is in the sp_ui_drag_data_received function
> in interface.cpp .  The fix doesn't appear hard; just take the x and y
> parameters to the function (which are currently unused), find what
> coordinates in the document correspond to that point on the screen,
> and set the x, y attributes on the outermost element of the incoming
> xml accordingly.  Unfortunately, I don't know what function to use to
> map screen coordinates to document coordinates.

Inkscape folk...can you help Greg out with this one?

> 
>         3.) Where are the titles for all the clip art?
> 
> The icon titles should be the metadata titles; are you seeing
> something different?  Also, the title should be listed near the bottom
> of the right hand pane when a specific icon is active.

It says "No Title" in all the searches I do under the clip art. I'm
assuming that each has  title in the metadata? Where is the problem at?

> 
>         4.) Could the right pane collapse, or be collapsed at the
>         beginning?
> 
> Sure, though from a user interface perspective, I'm not sure that its
> good to have the dimensions of the main window be changing
> dynamically.  The large, empty space initially doesn't look good
> either though.

Right, I'm not saying that it opens and closes, but should probably
start up closed...look at the file open and save in inkscape and gimp
for reference/examples.

> 
>         5.) Is there a way to add a light preferences menu, or a
>         button to this.
>         I wonder if it is wise to put a menu or some kind of icon bar
>         in this 
>         app. I'm leaning towards icon menu rather than a menu because
>         it will be
>         used inside apps for the most part.
> 
> 
> Right now, I'm working on turning the whole interface into a gtk
> notebook that will have 3 tabs: search, browse, and settings.  I'm
> nervous about this, because I'm just having a hard time coming up with
> any reasonable visual interface for the browse tab, but I'll discuss
> that more below.

Cool...

> 
>         6.) When doing a search, the app goes non-responsive for long
>         periods of
>         time which is bad IMO.
> 
> 
> Definitely agree; this is an Inkscape issue, and after looking through
> the extensions code a bit, I suspect its a non-trivial fix.  You could
> partially fix this by having the subprocess that Inkscape spawns for
> the extension spawn the real extension process and then return
> immediately, giving Inkscape back the unaltered document.  You could
> then insert clip art by dragging and dropping, but not by selecting an
> image.  The issue is that Inkscape effects extensions work by writing
> the current document to the extensions's standard input, waiting
> (freezing), then reading the modified document on standard input.  To
> keep it responsive during the waiting period, you'd have to spawn
> another thread that would poll the extension continuously.  This could
> be done by modifications to extension/implementation/script.cpp, but I
> haven't attempted this yet.

This is yet another area that Inkscape hackers can help. Ted and others,
can you look into this and help Greg out? (This is another benefit of
always cc'ing the lists...this is open source, right) ;)


>         7.) Could you add some kind of link to the image or to the
>         open clip art
>         library that says "get more clip art"
> 
> Not sure what you mean here.

Basically, a plug to get more clip art at Open Clip Art Library. For
example, if there are no results, maybe have a link that encourages ppl.
to go to www.openclipart.org to find more imagery.
 
> 
>         8.) When running the Clip Art Browser, Inkscape is blocked and
>         appears
>         frozen so then it is not possible to do drag and drop...not
>         good! This 
>         should be fixed. The Clip Art Browser should be spawned, the
>         pid
>         recorded, etc, so that Inkscape controls that process, but so
>         that
>         Inkscape can continue...
> 
> Yeah, I tried to describe why this is above.  Spawning the browser off
> into its own app would work, but you lose the ability to write to the
> pipe that did the spawning, which means you can't use the traditional
> effect extension interface to modify the document.  And the only other
> IPC technique to modify the document then is gtk drag-drop, I believe.
> The way effect extensions are implemented, as long as that original
> pipe is open, Inkscape is frozen (uh, right, guys)?.  Again, I think
> this might be solvable with threads.
> 
Ted, others?
> 
>         9.) The name of the program, Clip Art Browser needs to be made
>         consistent throughout the code
> 
> Working on that for 0.32, which I intend to release absolutely ASAP.

Cool! Ok, lets get the next release on Inkscape infrastructure ok...
> 
>         10.) You need to make the clip art indexer take an argument as
>         to where
>         the clipart folder is, and then it needs to also take an
>         argument for 
>         where to install the index.dat it generates...if this arg. is
>         not passed
>         in, then generate that file in the same dir. as where the
>         script is run.
> 
> This is actually how I implemented it initially, before I started
> worrying that I was making everything too complex.  But I agree, and
> will switch it back.

cool
> 
>         11.) There should be some kind of information in the GUI as to
>         how many
>         images are at the apps disposal.
> 
> Good idea... only prob is that this will require some way to retrieve
> this info from ocal.  The ocal web site currently just says "Over 4300
> clips.", which isn't quite usable, unless I'm desperate.

For the on-disk clipart this shouldn't be a problem...on ocal, this will
be query-able with dms...maybe not now though ;)
> 
>         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?

>         13.) Some kind of browse alphabetically would be nice
>         too... :)
> 
> This can be done without too much trouble for local clip art, but will
> require server-side additions to be used for querying ocal over the
> network.
>  
> Anyway, I promise I'm coding like mad nowadays to get this stuff in
> there.  0.32 will be out soon.  Thanks for the feedback, I expect to
> be able to implement most of it, as described above.

Cool...any feedback on Makefile? It is good to add this kind of
infrastructure that makes testers and other developers' lives easy.
Never forget that programmers are lazy!

Jon

> 
> 
> 
-- 
Jon Phillips

San Francisco, CA
USA PH 510.499.0894
jon at rejon.org
http://www.rejon.org

MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: rejon at gristle.org
IRC: rejon at irc.freenode.net

Inkscape (http://inkscape.org)
Open Clip Art Library (www.openclipart.org)