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:
------------------------------------ Toward an Implementation of an Intuitive Visual Mapping of Remote Vector Graphics Repository Access Interfaces
OR
Creating an openclipart.org http://openclipart.org GUI for Inkscape
This is a proposal to implement an interface to the open clipart library ( openclipart.org http://openclipart.org) in Inkscape, as suggested by the "Create a Clipart Library interface" item on the Inkscape Summer of Code ideas page. I'll introduce myself, describe the technical design I'd implement, and list some remaining technical questions and ways a mentor might help.
I'm a 22 year old computer-science major at the University of Richmond (I'll be a senior this year). I'm also a open-source geek. 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. I build websites for fun and cash. I've tried many distros, but have been happily using Gentoo on my own box for about 6 months now. 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. 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!). I use GTK constantly, and as I mentioned, I've contributed to Dia, so I know how to get around gnu-ish code. Philosophically, I align myself with the FSF, though I don't consider myself a zealot.
Blah, blah, blah. Let's talk turkey. 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. I just threw it up at the site I'm using to host my distributed computing project for convenience; you can download it at
https://developer.berlios.de/project/filelist.php?group_id=3863
(the tgz is listed under Inkscape, obviously). 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 openclipart.org http://openclipart.org, then writes the doc back to standard output, with the clipart inserted. It should be installable with a bare-bones .inx file like any other extension. The gui is GTK, of course, via libglade. Its pretty minimalistic, but should show that this project will not be difficult.
I currently see two ways to build this thing; either as an extension, as the prototype is, or integrated into the main codebase. 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. 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). 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. Either way, the code will have to query the openclipart.orghttp://openclipart.orgserver somehow, download the clipart, and insert it into the document. And, either way, the most natural way to provide the basic UI seems to be through the new Iconview class in GTK 2.6.
Ok, now I'll summarize the most obvious issues that appeared while building the prototype. The main one is that the openclipart.orghttp://openclipart.orgwebsite is clearly in need of a technical tuneup. The keyword search is barely functional, and performance is already iffy. If they'd be willing to let me, I'd prefer to actually work on the site myself. 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. Hopefully, I could also add some search results caching to speed it up. 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. This should be easy; it just requires a storage directory and an index file.
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. 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). 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.
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). 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). Searching by clipart author is also desirable (though not in the default interface), to help people find work of similar visual styles. The UI should make basic metadata available (the clipart title as the icon caption, and all associated keywords visible as a tooltip, for example). A list of the most recently used clipart should be available for convenience. Clipboard copying and large previews of icons will be available through a right-click popup menu. 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).
The conceptual questions I've currently noticed about the UI include where clipart should be inserted into the document, and at what size. 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. 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). Gnome HIG compliance is also intended.
One feature that may be necessary is XSLT-based conversion of incoming clipart to a more standard Inkscape-friendly format. 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. It is probably solvable by modifying the clipart object to use an svg "g" object instead of "svg" or something like that. Cleanup like this will be one major area that mentors could advise me on.
The other major bug that the prototype demonstrated seems to be caused by gnome svg rendering support (librsvg, I assume). Many of the openclipart.orghttp://openclipart.orgfiles 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 openclipart.orghttp://openclipart.orgwebsite provides, instead of the actual svg (the actual SVG is inserted into the document, of course).
I would also write a tutorial for this feature, and try to publicize any new APIs for the openclipart library that I developed.
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.
Anyway, sorry to go on for so long, but I figured more detail was better than less. I'm actually a reasonably fun guy, sorry about the stodgy tone of this app, just trying to give you the info you want. I'm really a free software nut, and have a lot of hope for its ability to kickstart the economies of the developing world. 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.
Thanks! -----------------
Have you submitted this yet? I have several suggestions for you.
The first one is to focus only on what you are trying to achieve with the SOC project. You should be explicit in detail and quite formal in your proposal. You talk too much about so many different projects and possibilities. This is good for brainstorming, but maybe not for this proposal. You should be affirmative in saying exactly what you will do and then when there are areas where experimentation is needed, be affirmative about these as well yet allow for possibilities.
It is cool you would like to undertake this, as it needs to be done.
I'm going to go into the text now to go through your points.
On Tue, 2005-06-14 at 23:57 -0400, Greg Steffensen wrote:
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:
Toward an Implementation of an Intuitive Visual Mapping of Remote Vector Graphics Repository Access Interfaces
OR
Creating an openclipart.org GUI for Inkscape
I think this title is better. You might re-title:
Creating a Generalized Graphical User Interface to the Open Clip Art Library for Inkscape
This is a proposal to implement an interface to the open clipart library (openclipart.org) in Inkscape,
Open Clip Art Library
as suggested by the "Create a Clipart Library interface" item on the Inkscape Summer of Code ideas page. I'll introduce myself, describe the technical design I'd implement, and list some remaining technical questions and ways a mentor might help.
This is good, but I think you should focus much more on the idea straight up front, and then explain your concepts. You can sum up yourself in a bio at the end of your proposal.
I'm a 22 year old computer-science major at the University of Richmond (I'll be a senior this year). I'm also a open-source geek. 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. I build websites for fun and cash. I've tried many distros, but have been happily using Gentoo on my own box for about 6 months now. 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. 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!). I use GTK constantly, and as I mentioned, I've contributed to Dia, so I know how to get around gnu-ish code. Philosophically, I align myself with the FSF, though I don't consider myself a zealot.
Yeah, I think you should firm this up.
Blah, blah, blah. Let's talk turkey. 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. I just threw it up at the site I'm using to host my distributed computing project for convenience; you can download it at
https://developer.berlios.de/project/filelist.php?group_id=3863
(the tgz is listed under Inkscape, obviously). 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 openclipart.org, then writes the doc back to standard output, with the clipart inserted. It should be installable with a bare-bones .inx file like any other extension. The gui is GTK, of course, via libglade. Its pretty minimalistic, but should show that this project will not be difficult.
Maybe you should also provide the INX. Cool that you made a prototype. You might want to take out the informal language.
I currently see two ways to build this thing; either as an extension, as the prototype is, or integrated into the main codebase. 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. 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). 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. Either way, the code will have to query the openclipart.org server somehow, download the clipart, and insert it into the document. And, either way, the most natural way to provide the basic UI seems to be through the new Iconview class in GTK 2.6.
I think you hsould just say that you are going to build this as an extension rather than wandering through other areas. You might sum up the options in a sentence, but not a really long para.
Ok, now I'll summarize the most obvious issues that appeared while building the prototype. The main one is that the openclipart.org website is clearly in need of a technical tuneup. The keyword search is barely functional, and performance is already iffy. If they'd be willing to let me, I'd prefer to actually work on the site myself.
Start contributing to it is the preferred way of asking ;)
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. Hopefully, I could also add some search results caching to speed it up. 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. This should be easy; it just requires a storage directory and an index file.
Ok, yes, I agree that the Open Clip Art Library needs some help on the site, but your proposal is about making a GUI to the library and not the OCAL site. I think you should focus only on the GUI. Also, there is code being written to change the site and run on Bryce's DMS:
http://openclipart.org/cgi-bin/wiki.pl?DocumentManagementSystem
You should be able to connect with DMS through the SOAP interface.
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. 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). 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.
DMS will control this...
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). 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). Searching by clipart author is also desirable (though not in the default interface), to help people find work of similar visual styles. The UI should make basic metadata available (the clipart title as the icon caption, and all associated keywords visible as a tooltip, for example). A list of the most recently used clipart should be available for convenience. Clipboard copying and large previews of icons will be available through a right-click popup menu. 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).
Ok, you are talking about a lot of ideas. I think you should cut these and just talk about the GUI to the clipart library.
The conceptual questions I've currently noticed about the UI include where clipart should be inserted into the document, and at what size. 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. 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). Gnome HIG compliance is also intended.
One feature that may be necessary is XSLT-based conversion of incoming clipart to a more standard Inkscape-friendly format. 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. It is probably solvable by modifying the clipart object to use an svg "g" object instead of "svg" or something like that. Cleanup like this will be one major area that mentors could advise me on.
Others can speak on this better...Inkscape others?
The other major bug that the prototype demonstrated seems to be caused by gnome svg rendering support (librsvg, I assume). Many of the openclipart.org 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 openclipart.org website provides, instead of the actual svg (the actual SVG is inserted into the document, of course).
File bugs at openclipart.org for these problems please.
I would also write a tutorial for this feature, and try to publicize any new APIs for the openclipart library that I developed.
That would be great. You would need to work with Inkscape and Open Clip Art developers more than likely, so all this can be worked up.
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.
Anyway, sorry to go on for so long, but I figured more detail was better than less. I'm actually a reasonably fun guy, sorry about the stodgy tone of this app, just trying to give you the info you want. I'm really a free software nut, and have a lot of hope for its ability to kickstart the economies of the developing world. 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.
Yeah, I think you should shrink this document in half and remove the liberal language in favor of details and explictly the task you are doing.
Please email back if any questions. It would be most excellent to get you working on this. Also, I wanted to say that it would be great if any interface to the Open Clip Art Library would be able to both connect to the SOAP web service to go through the library, or if clip art files are installed onto one's computer, through a yet-to-be-determined commong place (/usr/share/clipart/*) through packaging (RPM, emerge, deb), or another process, those should be visible through this interface as well.
Ok, please check out the Open Clip Art Library's wiki as well as Inkscape's. There is already much info. on this. Also, hop into the chat channels for each project to discuss in more depth.
Thanks!
On Tue, 14 Jun 2005, Greg Steffensen wrote:
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:
The reason Google won't be working is that your proposal text is too long their submission form. They have stated that the application needs to be less than 9K. You can either cut it down to less than the limit, or put the full text up on a webpage and provide a link to that as your submission.
Cheers, Michael
On Wed, 2005-06-15 at 15:54 +1000, Michael Wybrow wrote:
On Tue, 14 Jun 2005, Greg Steffensen wrote:
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:
The reason Google won't be working is that your proposal text is too long their submission form. They have stated that the application needs to be less than 9K. You can either cut it down to less than the limit, or put the full text up on a webpage and provide a link to that as your submission.
I would recommend cutting it down to this structure, with 5 paragraphs max:
1. Intro and sum up all ideas 2. explain the problem 3. explain your proposed solution 4. explain your proposed timeline 5. conclude
At the end include a 4-6 sentence bio with a link to your website.
That is solid and will cut to the chase.
jon
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hey, thanks a ton for the feedback. I wish I'd showed it to you earlier; as it is, I submitted too late to incorporate your suggestions. Still, for the record, if accepted, I'd implement all the features I described, except for the ones I specifically said I wasn't sure I could do. By those, I mean placing clipart in the document near the drop location of a drag-and-drop operation, and full Gnome HIG compliance (I intend to try to implement both of those, but don't know enough about them to say for certain that I'll be able to). I'd help to improve the OCAL backend and API if that's ok with them, but none of the client features I described depend on server changes; I'd implement everything even without OCAL access. Also, since no one seemed to have a problem with implementing it as an extension, I'd do that, unless a mentor objected later. Finally, I'd provide integrated access to local clipart in addition to OCAL (this would be independent of the local caching feature I described).
Also, just so you know, the first title in my app was supposed to be a joke :). Thanks again,
Greg
On 6/15/05, Jon Phillips <jon@...235...> wrote:
On Wed, 2005-06-15 at 15:54 +1000, Michael Wybrow wrote:
On Tue, 14 Jun 2005, Greg Steffensen wrote:
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:
The reason Google won't be working is that your proposal text is too
long
their submission form. They have stated that the application needs to be less than 9K. You can either cut it down to less than the limit, or put the full text up on a webpage and provide a link to that as your submission.
I would recommend cutting it down to this structure, with 5 paragraphs max:
- Intro and sum up all ideas
- explain the problem
- explain your proposed solution
- explain your proposed timeline
- conclude
At the end include a 4-6 sentence bio with a link to your website.
That is solid and will cut to the chase.
jon
SF.Net http://SF.Net email is sponsored by: Discover Easy Linux
Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Jon Phillips
USA PH 510.499.0894 jon@...235... http://www.rejon.org
Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org http://www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)
Cool, it would be great to get your help no matter the outcome from SOC. First of all, could you put your .INX file up at that URL where you put the extension for the test interface for OCAL.
Jon
On Wed, 2005-06-15 at 15:16 -0400, Greg Steffensen wrote:
Hey, thanks a ton for the feedback. I wish I'd showed it to you earlier; as it is, I submitted too late to incorporate your suggestions. Still, for the record, if accepted, I'd implement all the features I described, except for the ones I specifically said I wasn't sure I could do. By those, I mean placing clipart in the document near the drop location of a drag-and-drop operation, and full Gnome HIG compliance (I intend to try to implement both of those, but don't know enough about them to say for certain that I'll be able to). I'd help to improve the OCAL backend and API if that's ok with them, but none of the client features I described depend on server changes; I'd implement everything even without OCAL access. Also, since no one seemed to have a problem with implementing it as an extension, I'd do that, unless a mentor objected later. Finally, I'd provide integrated access to local clipart in addition to OCAL (this would be independent of the local caching feature I described).
Also, just so you know, the first title in my app was supposed to be a joke :). Thanks again,
Greg
On 6/15/05, Jon Phillips <jon@...235...> wrote: On Wed, 2005-06-15 at 15:54 +1000, Michael Wybrow wrote: > On Tue, 14 Jun 2005, Greg Steffensen wrote: > > > > 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: > > The reason Google won't be working is that your proposal text is too long > their submission form. They have stated that the application needs to be > less than 9K. You can either cut it down to less than the limit, or put > the full text up on a webpage and provide a link to that as your > submission.
I would recommend cutting it down to this structure, with 5 paragraphs max: 1. Intro and sum up all ideas 2. explain the problem 3. explain your proposed solution 4. explain your proposed timeline 5. conclude At the end include a 4-6 sentence bio with a link to your website. That is solid and will cut to the chase. jon > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library ( www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)
Done (all necessary files are now in the tgz). For some reason, the effects menu doesn't work on my Inkscape. My GTK doesn't like to add menu entries dynamically for some reason; I've had the same problem when working with Dia extensions. So I haven't been able to test this in Inkscape, but it works when invoked from the command line the way the extension docs describe. If it doesn't work, let me know. Again, the link is
https://developer.berlios.de/project/filelist.php?group_id=3863
Greg
On 6/15/05, Jon Phillips <jon@...235...> wrote:
Cool, it would be great to get your help no matter the outcome from SOC. First of all, could you put your .INX file up at that URL where you put the extension for the test interface for OCAL.
Jon
On Wed, 2005-06-15 at 15:16 -0400, Greg Steffensen wrote:
Hey, thanks a ton for the feedback. I wish I'd showed it to you earlier; as it is, I submitted too late to incorporate your suggestions. Still, for the record, if accepted, I'd implement all the features I described, except for the ones I specifically said I wasn't sure I could do. By those, I mean placing clipart in the document near the drop location of a drag-and-drop operation, and full Gnome HIG compliance (I intend to try to implement both of those, but don't know enough about them to say for certain that I'll be able to). I'd help to improve the OCAL backend and API if that's ok with them, but none of the client features I described depend on server changes; I'd implement everything even without OCAL access. Also, since no one seemed to have a problem with implementing it as an extension, I'd do that, unless a mentor objected later. Finally, I'd provide integrated access to local clipart in addition to OCAL (this would be independent of the local caching feature I described).
Also, just so you know, the first title in my app was supposed to be a joke :). Thanks again,
Greg
On 6/15/05, Jon Phillips <jon@...235...> wrote: On Wed, 2005-06-15 at 15:54 +1000, Michael Wybrow wrote:
On Tue, 14 Jun 2005, Greg Steffensen wrote:
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:
The reason Google won't be working is that your proposal
text is too long
their submission form. They have stated that the
application needs to be
less than 9K. You can either cut it down to less than the
limit, or put
the full text up on a webpage and provide a link to that as
your
submission.
I would recommend cutting it down to this structure, with 5 paragraphs max:
- Intro and sum up all ideas
- explain the problem
- explain your proposed solution
- explain your proposed timeline
- conclude
At the end include a 4-6 sentence bio with a link to your website.
That is solid and will cut to the chase.
jon
SF.Net http://SF.Net email is sponsored by: Discover Easy Linux
Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward
articles,
informative Webcasts and more! Get everything you need to
get up to
speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Jon Phillips
USA PH 510.499.0894 jon@...235... http://www.rejon.org
Inkscape (http://inkscape.org) Open Clip Art Library ( www.openclipart.org http://www.openclipart.org
)
CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)
-- Jon Phillips
USA PH 510.499.0894 jon@...235... http://www.rejon.org
Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org http://www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)
Greg Steffensen wrote:
Done (all necessary files are now in the tgz). For some reason, the effects menu doesn't work on my Inkscape. My GTK doesn't like to add menu entries dynamically for some reason; I've had the same problem when working with Dia extensions. So I haven't been able to test this in Inkscape, but it works when invoked from the command line the way the extension docs describe. If it doesn't work, let me know. Again, the link is
https://developer.berlios.de/project/filelist.php?group_id=3863
Just a few picky comments on the inx file:
<inkscape-extension> <name>OCAL Helper</name> <!-- changed id for consistency with other inx files, a matter of taste :) --> <id>org.openclipart.filter.helper</id> <dependency type="executable" location="extensions">ocal.py</dependency> <!-- avoiding absolute paths --> <dependency type="executable" location="path">python</dependency> <effect> <object-type>all</object-type> </effect> <script> <!-- adding interpreter property helps script to be called properly on all supported platforms --> <command reldir="extensions" interpreter="python">ocal.py</command> </script> </inkscape-extension>
When I run this as an effect from my home directory Inkscape crashes. Something must be wrong with finding extensions in the home directory. And something must be wrong with the how inkscape handles scripts that fail to give output. (Well, at least something must have been wrong when I compiled yesterday.)
Starting program: /usr/local/bin/inkscape [Thread debugging using libthread_db enabled] [New Thread -1225103968 (LWP 6491)] No preferences for Effect python: can't open file '/usr/local/share/inkscape/extensions/ocal.py' Extension::Script: Unknown error for pclose : Success
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225103968 (LWP 6491)] 0x0838da91 in Inkscape::Extension::Implementation::Script::effect (this=0x84fd7a8, module=0x48, doc=0x86194d0) at extension/implementation/script.cpp:627 627 copy_doc(doc->doc->rroot, mydoc->rroot); (gdb) bt #0 0x0838da91 in Inkscape::Extension::Implementation::Script::effect (this=0x84fd7a8, module=0x48, doc=0x86194d0) at extension/implementation/script.cpp:627 #1 0x0838c1d0 in Inkscape::Extension::Effect::effect (this=0x85184e0, doc=0x86194d0) at extension/effect.cpp:87 #2 0x0838c26c in Inkscape::Extension::Effect::EffectVerb::perform (action=0x48, data=0x85184e0, pdata=0x0) at extension/effect.cpp:120 #3 0x082c6aff in sp_action_perform (action=0x85a6b10, data=0x0) at helper/action.cpp:135 #4 0xb74532a6 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #5 0xb7441736 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #6 0xb7452dcf in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #7 0xb7451e9c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #8 0xb7452126 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #9 0xb7b8d697 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #10 0xb7aad052 in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #11 0xb7aac5e5 in _gtk_menu_shell_activate () from /usr/lib/libgtk-x11-2.0.so.0 #12 0xb7aa5376 in gtk_menu_reorder_child () from /usr/lib/libgtk-x11-2.0.so.0 #13 0xb7a9e02e in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #14 0xb74419c9 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #15 0xb7441736 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #16 0xb7452855 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #17 0xb7451c8c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #18 0xb7452126 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #19 0xb7b8d4c7 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0 #20 0xb7a9cb42 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #21 0xb7a9b996 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #22 0xb793a8b5 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #23 0xb73d55c2 in g_main_depth () from /usr/lib/libglib-2.0.so.0 #24 0xb73d6638 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #25 0xb73d6970 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #26 0xb73d6f13 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #27 0xb7a9b243 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #28 0xb7eb47e9 in Gtk::Main::run_impl () from /usr/lib/libgtkmm-2.4.so.1 #29 0xb7eb44f4 in Gtk::Main::run () from /usr/lib/libgtkmm-2.4.so.1 #30 0x08116786 in sp_main_gui (argc=1, argv=0xbffff914) at main.cpp:545 #31 0x081ecb48 in Inkscape::NSApplication::Application::run (this=0xbffff850) at application/application.cpp:134 #32 0x08116370 in main (argc=1, argv=0xbffff914) at main.cpp:418
But even when I run the program straight from the command line I can't find a query that gives results from ocal. So, while I can't test this out, I think it is a great idea. Thanks.
Aaron Spike
On Wed, 2005-06-15 at 18:53 -0500, aaron@...749... wrote:
Greg Steffensen wrote:
Done (all necessary files are now in the tgz). For some reason, the effects menu doesn't work on my Inkscape. My GTK doesn't like to add menu entries dynamically for some reason; I've had the same problem when working with Dia extensions. So I haven't been able to test this in Inkscape, but it works when invoked from the command line the way the extension docs describe. If it doesn't work, let me know. Again, the link is
https://developer.berlios.de/project/filelist.php?group_id=3863
Just a few picky comments on the inx file:
<inkscape-extension> <name>OCAL Helper</name> <!-- changed id for consistency with other inx files, a matter of taste :) --> <id>org.openclipart.filter.helper</id> <dependency type="executable" location="extensions">ocal.py</dependency> <!-- avoiding absolute paths --> <dependency type="executable" location="path">python</dependency> <effect> <object-type>all</object-type> </effect> <script> <!-- adding interpreter property helps script to be called properly on all supported platforms --> <command reldir="extensions" interpreter="python">ocal.py</command> </script> </inkscape-extension>
Cool...Aaron...Greg, maybe once this is working a little better, we could move this work into CVS for others to work on as well...Sound good?
When I run this as an effect from my home directory Inkscape crashes. Something must be wrong with finding extensions in the home directory. And something must be wrong with the how inkscape handles scripts that fail to give output. (Well, at least something must have been wrong when I compiled yesterday.)
Yeah, I filed this as a bug yesterday. You probaby have some good input for that bug. It is in the bug tracker (sf.net is down right now ;()
Starting program: /usr/local/bin/inkscape [Thread debugging using libthread_db enabled] [New Thread -1225103968 (LWP 6491)] No preferences for Effect python: can't open file '/usr/local/share/inkscape/extensions/ocal.py' Extension::Script: Unknown error for pclose : Success
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225103968 (LWP 6491)] 0x0838da91 in Inkscape::Extension::Implementation::Script::effect (this=0x84fd7a8, module=0x48, doc=0x86194d0) at extension/implementation/script.cpp:627 627 copy_doc(doc->doc->rroot, mydoc->rroot); (gdb) bt #0 0x0838da91 in Inkscape::Extension::Implementation::Script::effect (this=0x84fd7a8, module=0x48, doc=0x86194d0) at extension/implementation/script.cpp:627 #1 0x0838c1d0 in Inkscape::Extension::Effect::effect (this=0x85184e0, doc=0x86194d0) at extension/effect.cpp:87 #2 0x0838c26c in Inkscape::Extension::Effect::EffectVerb::perform (action=0x48, data=0x85184e0, pdata=0x0) at extension/effect.cpp:120 #3 0x082c6aff in sp_action_perform (action=0x85a6b10, data=0x0) at helper/action.cpp:135 #4 0xb74532a6 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #5 0xb7441736 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #6 0xb7452dcf in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #7 0xb7451e9c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #8 0xb7452126 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #9 0xb7b8d697 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #10 0xb7aad052 in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #11 0xb7aac5e5 in _gtk_menu_shell_activate () from /usr/lib/libgtk-x11-2.0.so.0 #12 0xb7aa5376 in gtk_menu_reorder_child () from /usr/lib/libgtk-x11-2.0.so.0 #13 0xb7a9e02e in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #14 0xb74419c9 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #15 0xb7441736 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #16 0xb7452855 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #17 0xb7451c8c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #18 0xb7452126 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #19 0xb7b8d4c7 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0 #20 0xb7a9cb42 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #21 0xb7a9b996 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #22 0xb793a8b5 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #23 0xb73d55c2 in g_main_depth () from /usr/lib/libglib-2.0.so.0 #24 0xb73d6638 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #25 0xb73d6970 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #26 0xb73d6f13 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #27 0xb7a9b243 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #28 0xb7eb47e9 in Gtk::Main::run_impl () from /usr/lib/libgtkmm-2.4.so.1 #29 0xb7eb44f4 in Gtk::Main::run () from /usr/lib/libgtkmm-2.4.so.1 #30 0x08116786 in sp_main_gui (argc=1, argv=0xbffff914) at main.cpp:545 #31 0x081ecb48 in Inkscape::NSApplication::Application::run (this=0xbffff850) at application/application.cpp:134 #32 0x08116370 in main (argc=1, argv=0xbffff914) at main.cpp:418
But even when I run the program straight from the command line I can't find a query that gives results from ocal. So, while I can't test this out, I think it is a great idea. Thanks.
Yeah, I hit a wall too...it is a great idea that needs implementation :)
Jon
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Aaron- for searches that actually produce results, try "food", "symbol" or "animal". And when you run it from within Inkscape, when does it crash? Immediately?
Greg
Greg Steffensen wrote:
Aaron- for searches that actually produce results, try "food", "symbol" or "animal". And when you run it from within Inkscape, when does it crash? Immediately?
Awesome. When a search returns results, the script is really cool. I think we need to work on the searchability of OCAL. Should someone (me?) write an xmlrpc server for searching OCAL?
As far as crashing Inkscape, I experienced crashes for the same reason in two different circumstances. Inkscape seems to be crashing when an extensions returns a null document. First I experienced a crash when Inkscape couldn't find ocal.py, which I had stored in ~/.inkscape/extensions, because it was looking in share/inkscape/extensions. And second I experienced a crash when I clicked the close button for the OCAL Helper window. I think the crash indicates a problem with Inkscape and not your script. Though in the second circumstance your script could provide the input document unmodified on stdout. Since it is callable from the command line it might also be useful to make your script return the selected clipart document alone if a container document isn't specified.
Aaron Spike
On Wed, 2005-06-15 at 22:00 -0500, aaron@...749... wrote:
Greg Steffensen wrote:
Aaron- for searches that actually produce results, try "food", "symbol" or "animal". And when you run it from within Inkscape, when does it crash? Immediately?
Awesome. When a search returns results, the script is really cool. I think we need to work on the searchability of OCAL. Should someone (me?) write an xmlrpc server for searching OCAL?
Please talk more with the ocal devs about this. Right now we are working on DMS as a solution for what you are trying to do, and what you, Aaron, are commenting on. See this doc for where you could help out with this development (help wanted!):
http://openclipart.org/cgi-bin/wiki.pl?DocumentManagementSystem
As far as crashing Inkscape, I experienced crashes for the same reason in two different circumstances. Inkscape seems to be crashing when an extensions returns a null document. First I experienced a crash when Inkscape couldn't find ocal.py, which I had stored in ~/.inkscape/extensions, because it was looking in share/inkscape/extensions. And second I experienced a crash when I clicked the close button for the OCAL Helper window. I think the crash indicates a problem with Inkscape and not your script.
Yes, I think that Inkscape is crashing when a script returns a non-zero status. See the Inkscape bug...unfortunately sf.net seems to be down, but the bug is on the top of the stack about extensions and crashing...filed by me, rejon/kidproto.
Jon
Though in the second circumstance your script could provide the input document unmodified on stdout. Since it is callable from the command line it might also be useful to make your script return the selected clipart document alone if a container document isn't specified.
Aaron Spike
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, Jun 15, 2005 at 10:00:46PM -0500, aaron@...749... wrote:
Greg Steffensen wrote:
Aaron- for searches that actually produce results, try "food", "symbol" or "animal". And when you run it from within Inkscape, when does it crash? Immediately?
Awesome. When a search returns results, the script is really cool. I think we need to work on the searchability of OCAL. Should someone (me?) write an xmlrpc server for searching OCAL?
I've been working on the searchability a bit via dms, and would be happy to work with you on this. There's probably a few ways of doing this, let me know what your general ideas are.
As far as crashing Inkscape, I experienced crashes for the same reason in two different circumstances. Inkscape seems to be crashing when an extensions returns a null document. First I experienced a crash when Inkscape couldn't find ocal.py, which I had stored in ~/.inkscape/extensions, because it was looking in share/inkscape/extensions. And second I experienced a crash when I clicked the close button for the OCAL Helper window. I think the crash indicates a problem with Inkscape and not your script. Though in the second circumstance your script could provide the input document unmodified on stdout. Since it is callable from the command line it might also be useful to make your script return the selected clipart document alone if a container document isn't specified.
Hmm, send in bug reports for these to Inkscape, with steps to recreate. Inkscape shouldn't crash in these situations.
Bryce
Greg Steffensen wrote:
And when you run it from within Inkscape, when does it crash? Immediately?
Yes, immediately. Well, most of the time. And I was sitting on the couch this morning wondering why (because I've seen it work exactly one time). And it hit me that the difference is current working directory.
I think it would be less likely to fail if you did something like the following to find the glade file:
cwd = os.path.abspath(os.path.dirname((sys.argv[0]))) self.xml = gtk.glade.XML(os.path.join(cwd, 'ocal.glade'))
I've only been learning python for a month or two so I realize that there is probably a better way.
Does pyglade work on windows?
Aaron Spike
participants (5)
-
unknown＠example.com -
Bryce Harrington -
Greg Steffensen -
Jon Phillips -
Michael Wybrow