Hello Greg,
I have tested your browser outside of inkscape.
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.
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?
3.) Where are the titles for all the clip art?
4.) Could the right pane collapse, or be collapsed at the beginning?
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.
6.) When doing a search, the app goes non-responsive for long periods of time which is bad IMO.
7.) Could you add some kind of link to the image or to the open clip art library that says "get more clip art"
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...
9.) The name of the program, Clip Art Browser needs to be made consistent throughout the code
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.
11.) There should be some kind of information in the GUI as to how many images are at the apps disposal.
12.) Some kind of browse by category would be nice.
13.) Some kind of browse alphabetically would be nice too... :)
I've attached a Makefile which should go into the main directory for your app. Now ppl. can do make install and uninstall.
Also, now it will be quite easy to do more testing, as users have a way to get this in and out of their extensions dir easily.
Should Greg's program be a new project on the main Inkscape page, or should it be moved into the extensions directory?
Now that I have made a makefile I'm in favor of making it its own project. Also, it is usable by other apps, so it can be standalone.
Jon
PS: Ted, it would be great to allow for folders inside the extensions dir to help organize new messes created by extensions with lots of folders. :)
On 8/25/05, Jon Phillips <jon@...235...> wrote:
Hello Greg,
I have tested your browser outside of inkscape.
<skipped/>
http://sharelinux.org/?q=node/1 could be of interest
Alexandre
http://sharelinux.org/?q=node/1 could be of interest
Wow. I will be very, very depressed if he has working code.
Greg
On 8/25/05, Greg Steffensen <greg.steffensen@...400...> wrote:
http://sharelinux.org/?q=node/1 could be of interest
Wow. I will be very, very depressed if he has working code.
Please don't. Only happy developers can make users happy. Hold your head up! ;-) You have another nice example of UI. Make a lemon of it.
Alexandre
On Thu, 2005-08-25 at 05:13 +0400, Alexandre Prokoudine wrote:
On 8/25/05, Greg Steffensen <greg.steffensen@...400...> wrote:
http://sharelinux.org/?q=node/1 could be of interest
Wow. I will be very, very depressed if he has working code.
Please don't. Only happy developers can make users happy. Hold your head up! ;-) You have another nice example of UI. Make a lemon of it.
I think the best way to handle this is to contact the dev. and get him into your project and focus efforts...2 is better than 1...this isn't closed source :)
I see no code from this other fellow...so maybe integrate some of those gui ideas and he can help out on Clip Art Browser.
Jon
On 8/25/05, Jon Phillips <jon@...235...> wrote:
I think the best way to handle this is to contact the dev. and get him into your project and focus efforts...2 is better than 1...this isn't closed source :)
I see no code from this other fellow...so maybe integrate some of those gui ideas and he can help out on Clip Art Browser.
Seconded
Alexandre
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
Oops- I wrote that effects extensions work by writing the current document to the extensions's standard input; actually, its written to a tempfile, and the filename is provided as a command line arg, although this doesn't affect the issue I was discussing.
Greg
On Wed, 2005-08-24 at 21:06 -0400, Greg Steffensen wrote:
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.
Well, this isn't really the way that effects are meant to be used. You're asking for a pallet, which honestly isn't available. In order to do multithreaded, we can't assume that anyone has a golden version of the document anymore. Palettes are on the roadmap, but until the DOM is available, I'm afraid that they are impractical. We could make the GUI refresh, but would have to force you to be unable to edit the document (which makes the GUI refreshing not that useful).
--Ted
On Wed, 2005-08-24 at 23:51 -0700, Ted Gould wrote:
On Wed, 2005-08-24 at 21:06 -0400, Greg Steffensen wrote:
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.
Well, this isn't really the way that effects are meant to be used. You're asking for a pallet, which honestly isn't available. In order to do multithreaded, we can't assume that anyone has a golden version of the document anymore. Palettes are on the roadmap, but until the DOM is available, I'm afraid that they are impractical. We could make the GUI refresh, but would have to force you to be unable to edit the document (which makes the GUI refreshing not that useful).
What is the best way to solve this then Ted? Wait? Or how can Greg push this through for his project?
Jon
On Thu, 2005-08-25 at 00:33 -0700, Jon Phillips wrote:
Well, this isn't really the way that effects are meant to be used. You're asking for a pallet, which honestly isn't available. In order to do multithreaded, we can't assume that anyone has a golden version of the document anymore. Palettes are on the roadmap, but until the DOM is available, I'm afraid that they are impractical. We could make the GUI refresh, but would have to force you to be unable to edit the document (which makes the GUI refreshing not that useful).
What is the best way to solve this then Ted? Wait? Or how can Greg push this through for his project?
Please note that Inkscape is pervasively non-thread-safe, so threads are not an option for implementing this.
-mental
Jon Phillips wrote:
On Wed, 2005-08-24 at 23:51 -0700, Ted Gould wrote:
Well, this isn't really the way that effects are meant to be used. You're asking for a pallet, which honestly isn't available. In order to do multithreaded, we can't assume that anyone has a golden version of the document anymore. Palettes are on the roadmap, but until the DOM is available, I'm afraid that they are impractical. We could make the GUI refresh, but would have to force you to be unable to edit the document (which makes the GUI refreshing not that useful).
What is the best way to solve this then Ted? Wait? Or how can Greg push this through for his project?
Well, I would have to say that this isn't going to happen in the short term. Bob is working on getting the DOM implemented, but it is a huge task. If Greg would like to help with that he'd need to talk to Bob about it. It is a drastically different task than working on OCAL stuff though.
I've mentioned it to Greg, and I still believe, that perhaps his application would work better separately from Inkscape instead of being an extension. Such that you could run them side by side, and then drag and drop files into Inkscape. This would also allow it to be used with other applications in a similar way. I think that is probably a stronger paradigm for using it.
I think also, from the marketing perspective, making it "OCAL Browser" is better than "The Inkscape Extension for OCAL". This way it can be made to work with applications like Illustrator and promote OCAL.
--Ted
I've mentioned it to Greg, and I still believe, that perhaps his application would work better separately from Inkscape instead of being an extension. Such that you could run them side by side, and then drag and drop files into Inkscape. This would also allow it to be used with other applications in a similar way. I think that is probably a stronger paradigm for using it.
I think also, from the marketing perspective, making it "OCAL Browser" is better than "The Inkscape Extension for OCAL". This way it can be made to work with applications like Illustrator and promote OCAL.
This sounds like a good idea, and requires minimal changes to the code.
But I'm theoretically working on this for Inkscape, as far as Google is concerned. Would a stronger separation from Inkscape be tolerable?
Greg
On Thu, 2005-08-25 at 12:49 -0400, Greg Steffensen wrote:
I've mentioned it to Greg, and I still believe, that perhaps his application would work better separately from Inkscape instead of being an extension. Such that you could run them side by side, and then drag and drop files into Inkscape. This would also allow it to be used with other applications in a similar way. I think that is probably a stronger paradigm for using it. I think also, from the marketing perspective, making it "OCAL Browser" is better than "The Inkscape Extension for OCAL". This way it can be made to work with applications like Illustrator and promote OCAL.This sounds like a good idea, and requires minimal changes to the code. But I'm theoretically working on this for Inkscape, as far as Google is concerned. Would a stronger separation from Inkscape be tolerable?
I think its one of those things that we define, and if this is the best solution, then this is the solution :)
I think the most important part is to basically just get interoperability down.
So, then my question is where to host the code? Should it be a new project on the sf.net inkscape page, or now under Open Clip Art Library's CVS?
Thoughts?
Jon
On Thu, 2005-08-25 at 12:49 -0400, Greg Steffensen wrote:
I've mentioned it to Greg, and I still believe, that perhaps his application would work better separately from Inkscape instead of being an extension. Such that you could run them side by side, and then drag and drop files into Inkscape. This would also allow it to be used with other applications in a similar way. I think that is probably a stronger paradigm for using it. I think also, from the marketing perspective, making it "OCAL Browser" is better than "The Inkscape Extension for OCAL". This way it can be made to work with applications like Illustrator and promote OCAL.This sounds like a good idea, and requires minimal changes to the code. But I'm theoretically working on this for Inkscape, as far as Google is concerned. Would a stronger separation from Inkscape be tolerable?
There is also the other option of just starting a separate project with this browser. I think many apps. could benefit from it and believe that it would be integrated into the Gnome desktop if development on it scaled up.
OCAL ppl what say you? Inkscape ppl speak please...
Jon
On 8/25/05, Jon Phillips <jon@...235...> wrote:
On Thu, 2005-08-25 at 12:49 -0400, Greg Steffensen wrote:
This sounds like a good idea, and requires minimal changes to the code. But I'm theoretically working on this for Inkscape, as far as Google is concerned. Would a stronger separation from Inkscape be tolerable?
I like the idea of a separate browser so long as:
- drag and drop from it to Inkscape works
- it is as crossplatform as is Inkscape
- it is shipped along with Inkscape at least on Windows
- it can be run from within Inkscape
All 4 are achievable; in fact, this is the best way to achieve #1.
Greg
On 8/25/05, bulia byak <buliabyak@...400...> wrote:
On 8/25/05, Jon Phillips <jon@...235...> wrote:
On Thu, 2005-08-25 at 12:49 -0400, Greg Steffensen wrote:
This sounds like a good idea, and requires minimal changes to the code. But I'm theoretically working on this for Inkscape, as far as Google is concerned. Would a stronger separation from Inkscape be tolerable?
I like the idea of a separate browser so long as:
drag and drop from it to Inkscape works
it is as crossplatform as is Inkscape
it is shipped along with Inkscape at least on Windows
it can be run from within Inkscape
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Thu, 2005-08-25 at 14:58 -0300, bulia byak wrote:
On 8/25/05, Jon Phillips <jon@...235...> wrote:
On Thu, 2005-08-25 at 12:49 -0400, Greg Steffensen wrote:
This sounds like a good idea, and requires minimal changes to the code. But I'm theoretically working on this for Inkscape, as far as Google is concerned. Would a stronger separation from Inkscape be tolerable?
I like the idea of a separate browser so long as:
- drag and drop from it to Inkscape works
Already does...just need to get it to drop where the cursor is located...anyone have thoughts on this?
- it is as crossplatform as is Inkscape
cool
- it is shipped along with Inkscape at least on Windows
I think it should ship for all platforms...there might be issues though until python 2.4 and pygtk become standard on most systems...
- it can be run from within Inkscape
Where should it go in the Inkscape menu IYO? Also, it would be good for inkscape to check and see if it exists and add it to the menu at run-time possibly...
On Aug 25, 2005, at 12:22 PM, Jon Phillips wrote:
On Thu, 2005-08-25 at 14:58 -0300, bulia byak wrote:
I like the idea of a separate browser so long as:
- drag and drop from it to Inkscape works
Already does...just need to get it to drop where the cursor is located...anyone have thoughts on this?
Look at what I did to get drag-n-drop of images to go in the right place.
On Thu, 2005-08-25 at 19:27 -0700, Jon A. Cruz wrote:
On Aug 25, 2005, at 12:22 PM, Jon Phillips wrote:
On Thu, 2005-08-25 at 14:58 -0300, bulia byak wrote:
I like the idea of a separate browser so long as:
- drag and drop from it to Inkscape works
Already does...just need to get it to drop where the cursor is located...anyone have thoughts on this?
Look at what I did to get drag-n-drop of images to go in the right place.
Huh, did you commit code? What's up? Cryptic your msg is...
Jon
On Aug 25, 2005, at 8:12 PM, Jon Phillips wrote:
Huh, did you commit code? What's up? Cryptic your msg is...
I think I addressed things for bug 1179362 "Images should be placed where dropped"
src/interface might be the point where things start coming in. I don't recall all the details off-hand
:-(
On Thu, 2005-08-25 at 20:29 -0700, Jon A. Cruz wrote:
On Aug 25, 2005, at 8:12 PM, Jon Phillips wrote:
Huh, did you commit code? What's up? Cryptic your msg is...
I think I addressed things for bug 1179362 "Images should be placed where dropped"
src/interface might be the point where things start coming in. I don't recall all the details off-hand
Cheer up buddy...no dig intended :) I am just curious about your message.
Jon
On Aug 25, 2005, at 11:22 PM, Jon Phillips wrote:
On Thu, 2005-08-25 at 20:29 -0700, Jon A. Cruz wrote:
On Aug 25, 2005, at 8:12 PM, Jon Phillips wrote:
Huh, did you commit code? What's up? Cryptic your msg is...
I think I addressed things for bug 1179362 "Images should be placed where dropped"
src/interface might be the point where things start coming in. I don't recall all the details off-hand
Cheer up buddy...no dig intended :) I am just curious about your message.
Just scan the changes around Apr 10 to see what I might have touched. That's the date on a meaningful change I did to src/interface.cpp. I'm not sure where the drop point stuff ended up, as I was doing all sorts of back-and-forth on the final solution.
participants (7)
-
Alexandre Prokoudine -
bulia byak -
Greg Steffensen -
Jon A. Cruz -
Jon Phillips -
MenTaLguY -
Ted Gould