Thank you for taking the time to give us feedback on this project.
On 7/19/07, Ted Gould <ted@...11...> wrote:
BTW, what is "Glimmer Labs"?
We're students at Grinnell College, and our advisor's mentor recommended naming his research lab. He is a bit of an acronym freak, so, after at least five minutes thought, came up with "The Grinnell Laboratory for Interactive Multi-Media Experimentation and Research", aka "Glimmer'.
What problem were you trying to solve by adding the 'update' flag to the document object? I'm concerned that this is working around some synchronization issue that has broader implications in the codebase. Perhaps we have a different way of solving that problem.
The reason we added the update flag was for editing large numbers of objects (1000+) without updating the document each time, making it much faster. We found this to be useful because scripting allows one to do interesting things with large numbers of objects (such as morph) and updating the document every time something is drawn on the screen can slow down the function an immense amount.
I notice that you've included some source code called "tinyscheme". Is there are reason to use that over guile's bindings? I'm curious because it would be nice if we didn't have maintain code for a scheme interpreter in our codebase. Linking to one that is already maintained is a bonus.
We considered multiple implementations of Scheme, including Guile. However it made sense to us to try to parallel the other big open-source graphics program (aka "The Gimp"), and The Gimp is using TinyScheme. We will consider Guile, however.
I'm a little bit concerned over the interface between C++ and Scheme. I think it might be a little too high level as there is a lot of code duplicated between the Inkscape code base and the function implemented for the interface. I still think the functions are useful, but perhaps a better place to put them is in Scheme.
We have implemented the inkscape-call-verb function which works extremely well, although verbs do not extend to node manipulation and creation. We also experimented with creating a rectangle in the manner you suggested.
(define (rectangle2 desktop layer x y w h) (let ((node (node-new desktop layer "svg:rect"))) (node-modify desktop node "style" (desktop-get-css 0)) (node-modify desktop node "x" x) (node-modify desktop node "y" y) (node-modify desktop node "width" w) (node-modify desktop node "height" h)))
(rectangle2 (get-desktop) "layer1" "10" "10" "100" "100")
This works with your idea to add new functionality without the scheme interface being updated, although along with mental's criticism, this implementation still exposes a lot of the internal C++ API directly concerning creating and modifying nodes. I guess this is an idea to explore more with Bob Jamison
A very requested feature :)
Lastly, (if you've made it this far) while I think a scheme console is cool I'm not sure how useful it is to most users. (Though, AutoCAD people seem to really like it). I think it would be really cool if you'd implement a subclass of Inkscape::Extension::Implementation that would use scheme.
We definitely would like to implement that feature, but we feel at the same time, that a interactive console can be useful to most users, and "every" user will find times in which it is faster or more natural to use a console. It also provides an easier entry into scripting than does "create a file, load it, test it."
Thanks again,
David D'Angelo and Soren Berg