Re: [Inkscape-devel] Inkscape scripting API (Draft)
-On the service file:
I think, Aaron, that what would be more useful is to have the service.in file modified to point to whichever Inkscape is currently being compiled (easy to implement.) Then it will work with in place installations. This would still require the use of sudo in the make install step to move the service file to dbus's service folder (I think making separate service folders would be more trouble than it's worth. The end result is that the Inkscape service file would always point to the last Inkscape version installed.
Ted is right that it is not a crucial feature. I implemented it mostly because it was so easy. Although, it does mean that the example code will always run, weather or not Inkscape is active, which is one less potential error message for new adopters.
On starting a session bus:
If the user has DBus installed they probably have a session bus running. I could start one if it's not or just assume they are not going to use DBus and not do any DBus stuff. Either one would work, and I don't think it makes a huge difference.
On the Windows version:
We have resisted for a long time the temptation to treat non-Unix boxes as limited-capability ports. An --ENORMOUS-- amount of work has been expended to prevent that from happening. Please let's not surrender now.
I think that the difference here is that DBus is not part of Inkscape. If a windows user has DBus installed I _absolutely_ want to support that. If they don't however, I can't really install it for them. At this point, Windows DBus is still in development so it's not very likely that windows users will have it. As soon as it is available, We'll make sure Inkscape supports it.
If someone is running Inkscape in a cygwin or MinGW environment where DBus is available we should support that as well.
Let me know if you think there is a problem with that assessment of the current situation.
On recent Progress:
I'm still working on getting returning list structures working, but I have a new idea that might work. Packaging is still in progress but I think I have a better idea of what I'm doing now. Tomorrow I'll post a list of functions that are broken and a list of functions that need minor changes.
Thank you all for your interest,
-Soren
Hi again, all...
Since we already have two main() files, the normal main.cpp and the one with WinMain() in it, maybe we can consider putting Dbus sensing/startup/shutdown there.
bob
On 7/19/2009 6:11 PM, Glimmer Labs wrote:
-On the service file:
I think, Aaron, that what would be more useful is to have the service.in file modified to point to whichever Inkscape is currently being compiled (easy to implement.) Then it will work with in place installations. This would still require the use of sudo in the make install step to move the service file to dbus's service folder (I think making separate service folders would be more trouble than it's worth. The end result is that the Inkscape service file would always point to the last Inkscape version installed.
Ted is right that it is not a crucial feature. I implemented it mostly because it was so easy. Although, it does mean that the example code will always run, weather or not Inkscape is active, which is one less potential error message for new adopters.
On starting a session bus:
If the user has DBus installed they probably have a session bus running. I could start one if it's not or just assume they are not going to use DBus and not do any DBus stuff. Either one would work, and I don't think it makes a huge difference.
On the Windows version:
We have resisted for a long time the temptation to treat non-Unix boxes as limited-capability ports. An --ENORMOUS-- amount of work has been expended to prevent that from happening. Please let's not surrender now.
I think that the difference here is that DBus is not part of Inkscape. If a windows user has DBus installed I _absolutely_ want to support that. If they don't however, I can't really install it for them. At this point, Windows DBus is still in development so it's not very likely that windows users will have it. As soon as it is available, We'll make sure Inkscape supports it.
If someone is running Inkscape in a cygwin or MinGW environment where DBus is available we should support that as well.
Let me know if you think there is a problem with that assessment of the current situation.
On recent Progress:
I'm still working on getting returning list structures working, but I have a new idea that might work. Packaging is still in progress but I think I have a better idea of what I'm doing now. Tomorrow I'll post a list of functions that are broken and a list of functions that need minor changes.
Thank you all for your interest,
-Soren
Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jul 19, 2009, at 6:38 PM, Bob Jamison <ishmalius@...400...> wrote:
Since we already have two main() files, the normal main.cpp and the one with WinMain() in it, maybe we can consider putting Dbus sensing/startup/shutdown there.
Dbus isn't really useful if we start it on our own as it is only really useful if two people know about it. (that way they can talk to each other). So I think the sensing code should be generic for all OSes, and if it's not there just assume that the user doesn't want to use DBus.
--Ted
Ted Gould wrote:
On Jul 19, 2009, at 6:38 PM, Bob Jamison <ishmalius@...400...> wrote:
Since we already have two main() files, the normal main.cpp and the one with WinMain() in it, maybe we can consider putting Dbus sensing/startup/shutdown there.
Dbus isn't really useful if we start it on our own as it is only really useful if two people know about it. (that way they can talk to each other). So I think the sensing code should be generic for all OSes, and if it's not there just assume that the user doesn't want to use DBus.
What if our shipped extensions start to make use of dbus communication? A number of extensions use the --query-all command line parameter and shell out inkscape. I can only imagine that this would be more efficient using dbus to connect to a single instance of inkscape that has already parsed the SVG. Perhaps something like the commandline's query functionality should be added to the API.
Aaron Spike
Plus on OSes where it's not a system process someone needs to start it... Besides if everyone takes that attitude it'll never get picked up on other platforms.
Sent from my iPhone
On Jul 20, 2009, at 12:32 PM, Aaron Spike <aaron@...749...> wrote:
Ted Gould wrote:
On Jul 19, 2009, at 6:38 PM, Bob Jamison <ishmalius@...400...> wrote:
Since we already have two main() files, the normal main.cpp and the one with WinMain() in it, maybe we can consider putting Dbus sensing/startup/shutdown there.
Dbus isn't really useful if we start it on our own as it is only really useful if two people know about it. (that way they can talk to each other). So I think the sensing code should be generic for all OSes, and if it's not there just assume that the user doesn't want to use DBus.
What if our shipped extensions start to make use of dbus communication? A number of extensions use the --query-all command line parameter and shell out inkscape. I can only imagine that this would be more efficient using dbus to connect to a single instance of inkscape that has already parsed the SVG. Perhaps something like the commandline's query functionality should be added to the API.
Aaron Spike
Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Wow, lots of people have opinions about this. A lot of good points too, especially regarding extensions.
It may be a moot point, however.
As it turns out, attempting to connect to the session bus AUTOMATICALLY starts one if one is not running already (aka the DBUS_SESSION_BUS_ADDRESS environment variable is not set.) This is explicitly stated as an internal feature of libdbus and dbus-launch (the shell script that launches sessions) is not meant to be used in applications.
We may or may not have to do some tweaking for the Windows version, but I say we cross that bridge when we come to it.
Whew, one heavily requested feature taken care of with half an hour of research and no coding. Not bad for a Monday morning.
On Mon, Jul 20, 2009 at 4:32 AM, Aaron Spike<aaron@...749...> wrote:
Perhaps something like the commandline's query functionality should be added to the API.
That is defiantly on the agenda. Much of the functionality is already there (query-x, query-width, verb, select) or easily implemented (query-all.)
The question is whether to try to work it into the scripting interface, or have a separate interface designed to mimic the command line as much as possible. Both have their advantages.
For people interested in trying out the API here is a list of functions that are currently broken:
get_node_coordinates (need to parse path for x,y coordinates of nodes.) selection_box (recently added, need to pull apart selection tool.) move_to_layer (can cut, but doesn't paste in the new layer, may need to expose cut_impl.) layer_get_all (might need to parse the XML tree to find this.)
Functions that don't behave ideally:
text (is not selectable/editable after creation, does not create a node.) transform (just sets, should merge.)
If any other functions crash Inkscape or do not return let me know, because it may be an issue I am not aware of.
Note: Error reporting has not been implemented. If there is an error caught by the API code it simply returns false (for now.) This will cause an error that looks like this in the script that called the offending function: dbus.exceptions.DBusException: org.freedesktop.DBus.GLib.ErrorError: Method invoked for <function-name> returned FALSE but did not set error
Eventually functions will return nice GErrors.
-Soren
On Mon, 2009-07-20 at 06:32 -0500, Aaron Spike wrote:
Ted Gould wrote:
On Jul 19, 2009, at 6:38 PM, Bob Jamison <ishmalius@...400...> wrote:
Since we already have two main() files, the normal main.cpp and the one with WinMain() in it, maybe we can consider putting Dbus sensing/startup/shutdown there.
Dbus isn't really useful if we start it on our own as it is only really useful if two people know about it. (that way they can talk to each other). So I think the sensing code should be generic for all OSes, and if it's not there just assume that the user doesn't want to use DBus.
What if our shipped extensions start to make use of dbus communication? A number of extensions use the --query-all command line parameter and shell out inkscape. I can only imagine that this would be more efficient using dbus to connect to a single instance of inkscape that has already parsed the SVG. Perhaps something like the commandline's query functionality should be added to the API.
Hmm, I guess that makes sense. I think that we probably would need a way to know if the extension need DBus so that if it's not installed at all we can make sure not to show those. The dependencies in extensions are getting more and more complex :(
I guess I'm still in favor of, on win32, starting DBus in a batch file wrapper or something. Everything gets passed by environment variables which we just hand down to extensions, so we wouldn't need special code to add environment variables if it was started outside of Inkscape.
--Ted
Good news, I have error reporting working!
I created 4 categories of errors.
OBJECT: The most common, when the user tries to manipulate an object that doesn't exist. VERB: If the user directly or indirectly calls a verb and it fails. Not sure if this can even happen since I've never seen it, but since a lot of functions rely on verbs it seemed like a safe choice. SELECTION: A problem with the selection. Particularly if a function requires that a certain number of items are selected. OTHER: A default error for things like the user passing in null strings for parameters, etc.
The only thing I'm not sure about is whether to throw an error if the user calls a selection function like selection_move or selection_rotate and nothing is selected. Inkscape gives a small notification in these cases but otherwise does not complain and I have emulated this by not throwing unrecoverable errors but I would like to indicate this condition somehow.
Any ideas?
-Soren
Interesting (accidental) effect:
Purely by accident I disabled the paste-in-place behavior of the selection function while doing some refactoring. Next time I moved my cursor across the screen while pasting an object repeatedly (to test speed) I found the objects following my cursor, making a line similar to drawing in the GIMP.
One convenience function for turning RGB into style strings and some fun with modulo and this is what popped out:
http://www.cs.grinnell.edu/~bergsore/colorblend.jpg
It only took about 5 lines of code on the client side.
-Soren
Pretty cool! Great accidence :)
2009/7/23, Glimmer Labs <glimmer07@...400...>:
Interesting (accidental) effect:
Purely by accident I disabled the paste-in-place behavior of the selection function while doing some refactoring. Next time I moved my cursor across the screen while pasting an object repeatedly (to test speed) I found the objects following my cursor, making a line similar to drawing in the GIMP.
One convenience function for turning RGB into style strings and some fun with modulo and this is what popped out:
http://www.cs.grinnell.edu/~bergsore/colorblend.jpg
It only took about 5 lines of code on the client side.
-Soren
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
It's already working for a while, just copy (CTRL+C) and let paste (CTRL+V) pushed while moving cursor. That's the difference between paste and paste in place :)
I used this to create a smoke effect.
2009/7/23 Glimmer Labs <glimmer07@...400...>
Interesting (accidental) effect:
Purely by accident I disabled the paste-in-place behavior of the selection function while doing some refactoring. Next time I moved my cursor across the screen while pasting an object repeatedly (to test speed) I found the objects following my cursor, making a line similar to drawing in the GIMP.
One convenience function for turning RGB into style strings and some fun with modulo and this is what popped out:
http://www.cs.grinnell.edu/~bergsore/colorblend.jpghttp://www.cs.grinnell.edu/%7Ebergsore/colorblend.jpg
It only took about 5 lines of code on the client side.
-Soren
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (7)
-
Aaron Spike -
Bob Jamison -
Glimmer Labs -
John Cliff -
Oleg Koptev -
Ted Gould -
Yann Papouin