[Clipart] Re: Clip Art Browser

[Greg Steffensen]

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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.

 
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.
 
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.
 
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.
 
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.

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.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/clipart/attachments/20050824/a9291cc6/attachment.html>