inkscape-devel

Here is the first draft of a Dbus based Inkscape scripting API:
http://www.cs.grinnell.edu/~bergsore/inkscapeDbusRef.html
(Many thanks to the ConsoleKit team for the scripts and build system I
used to generate this documentation.)
I would welcome any comments or criticisms, the interface is very much
still up in the air so any suggestions, from small changes to major
issues, would be welcome.
I would particularly like to hear if people think that this would
potentially support the ways in which they use Inkscape, or whether
there are use cases this doesn't address. If there are lots of uses
that this interface does not support, additional interfaces geared
towards different users could be added. (In fact there was originally
one more interface than there is now, see document_new() for details.)
If you like the current API (in general) feel free to suggest
additional functions or functionality.
Finally, how would you like to see this extended? Dbus has proven to
be quite responsive and robust for this application. How would you
build off the basic platform of the Inkscape application interface?
I will keep the posted link updated as I make changes based on peoples feedback.
-Soren

On Wed, 2009-07-08 at 20:16 -0700, Glimmer Labs wrote:
> Here is the first draft of a Dbus based Inkscape scripting API:
The draft looks good, thanks for going through this work, I'm happy to
see it getting done.
> Finally, how would you like to see this extended? Dbus has proven to
> be quite responsive and robust for this application. How would you
> build off the basic platform of the Inkscape application interface?
I would like to see hooks for groups as objects. I have a bar code
plugin which would benefit a lot from being able to handle resize
events, text editing events and so on, even so much as being able to
edit the object with ui from the plugin if required.
Best Regards, Martin Owens

Martin Owens wrote:
> On Wed, 2009-07-08 at 20:16 -0700, Glimmer Labs wrote:
>
>> Here is the first draft of a Dbus based Inkscape scripting API:
>>
>
> The draft looks good, thanks for going through this work, I'm happy to
> see it getting done.
>
+1! Thank you for this great effort!
It fulfills my long-lasting dream of having Scriptographer-like
functionality in Inkscape! I've looked through the draft and all
features i could possibly desire are already there. Amazing stuff :)
Does this also mean that these actions would be available to plugins?
That would be a(nother) godsend.
Pardon if it sounds hasty, but when can we expect a first version of
this interface? I'd love to get my hands on it as soon as it's minimally
usable. Again, many thanks for being on this :)

First off, I forgot to mention in my first e-mail that this is a very
conservative API. Most of the functions are already written and
tested, and of the rest only a few will take a decent amount of
coding. The others just need to call a verb or some pre-existing
Inkscape function.
I tried not to put anything in this draft that I wasn't sure could be
implemented.
Signals/Events:
That being said I have been thinking about signals for a while and did
not put them in the first draft for two reasons. One, they complicate
things a little. Having signals or asynchronous functions requires
more knowledge of dbus on the client side and adds complexity. I
wanted to keep the first draft simple.
Two, I'm not sure how much work it would be to add them. Sure I could
add a hack in sp_document_done, but it is not enough to know there was
a keyboard event, you also want to know what key was pressed (for
example.) To get the data of an Inkscape event I would need to create
EventListeners and register them with EventTargets and parse values
and decide which to send and so on for each signal I wanted to expose.
Maybe someone who knows the event system will tell me that there is a
way to expose all the Inkscape events at once without having to do a
lot of coding for each separate signal I want to send, but I doubt it.
I'll keep looking into it though, it's definitely a possibility and
I'm sure it will get done at some point if there is demand for it.
Perhaps I'll create a "Proposed" interface to act as a sort of API wishlist.

Glimmer Labs wrote:
> Here is the first draft of a Dbus based Inkscape scripting API:
>
> http://www.cs.grinnell.edu/~bergsore/inkscapeDbusRef.html
>
<snip />
>
> I will keep the posted link updated as I make changes based on peoples feedback.
>
> -Soren
Soren,
This is really very exciting for me. I have always wanted
language-neutral scripting access to live Inkscape internals. Your Dbus
work is the best imaginable compliment to our current simple but
powerful stdin/stdout based extension mechanism. I could only spare a
few moments to look over your API this morning, but what I see appears
to be the answer to a number of requests, including a recent request for
a scripting API that simplifies drawing and doesn't require in-depth
knowledge of XML and SVG. My only immediate question is how one deals
with and manipulates existing objects in a document, but my lack of
understanding is almost certainly because of the lack of time I've spent
reviewing the API. Before I can comment more I will need to get my hands
dirty and work with the API. I apologize if I've missed it, but where
can I checkout your branch?
lib2geom offers a lot of power for advanced users, have you given any
thought to how a script author might combine 2geom and your Dbus API?
Whether it be by convenience routines that bring data from Inkscape to
py2geom or by exposing 2geom in Inkscape through your API, any work you
do to enable this and make it convenient will surely pay dividends.
I can't wait to test this!
Aaron Spike

Thanks for the great responses all! I hadn't anticipated people would
be so eager to try it out (though I should have, it's a lot of fun to
play around with even at this stage.) I'll get a svn patch ready and
talk to Ted about getting a branch set up.
Extension integration:
Ted and I have talked about supporting extensions. The general idea
is to keep all of the advantages of the current extension system and
simply provide some alternatives to the potentially inefficient
stdin/stdout communication. Extensions already live in a separate
process, so this should be a good solution. Live previews in
particular would benefit from extensions not having to pass the entire
document to make small changes.
I am currently investigating how this could be done while requiring
minimal changes to existing extensions. Anyone familiar with
extensions and what kind of functionality they would need, don't
hesitate to speak up.
Lib2geom:
I hadn't looked at this before but I definitely will now. It does
seem like a great way to give a ton of flexibility for advanced users.
I have no idea whether it will be easy or hard but I'll give it a
shot and let you know what I find.
Working with previous objects (ones you did not create):
Basically you select objects in a layer or document and get the id's
from the selection. I've also added a selection_box to make this
easier. A functional programmer could map a filter function onto
selection_get() and set the result as the new selection. Then you
could write a function to get whatever you needed:
Select_blue_objects() Select_larger_than (50) Select_by_alpha (<, .5).
The possibilities are endless (of course you could do this
imperatively, but where's the fun in that?)
Keep those suggestions coming,
-Soren

Glimmer Labs wrote:
> Working with previous objects (ones you did not create):
>
> Basically you select objects in a layer or document and get the id's
> from the selection. I've also added a selection_box to make this
> easier. A functional programmer could map a filter function onto
> selection_get() and set the result as the new selection. Then you
> could write a function to get whatever you needed:
> Select_blue_objects() Select_larger_than (50) Select_by_alpha (<, .5).
> The possibilities are endless (of course you could do this
> imperatively, but where's the fun in that?)
>
This is exactly what I wanted to hear. Now does this behavior mandate
that every element have an id attribute. I think Inkscape does this by
default now. But it is not required by SVG and Jon Cruz has mentioned
many times in the past that he would like to change our behavior. Are we
talking id attributes or is there a unique id per element inside of
Inkscape? How do we access elements that are placed outside of the
visible SVG body and can't take part in a selection in Inkscape?
Nested transformations have been a bit of a problem in our current
extensions because we are processing the raw XML and no one had put in
the effort to write a tool that knows about these nested transforms. Its
been so long since I worked with it that I don't remember exactly what
the problems where. Are there circumstances when nested transformations
will need to be taken into account to use your API or will it likely be
transparent to the user because we are using Inkscape?
Aaron Spike

There is now a SVN branch for the dbus scripting work:
https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/gsoc2009_api
The build system should do everything automatically if you have a
reasonably recent DBus installed (Ubuntu users should already have
this.)
If your Inkscape executable is not in the standard place
(/usr/local/bin/inkscape) you might have to modify
src/extension/dbus/org.inkscape.service.in for Inkscape to start
automatically when requested. This will be set automatically soon,
but for now is hardcoded.
Almost all functions are implemented but a couple are still stubs. A
few are under active development and will crash Inkscape, especially
ones that return lists. Most of the functions are stable, however.
See /src/extension/dbus/document-interface.cpp for details.
Let me know if you have any problems making or running the test script
given in the documentation.
Thanks for your interest,
-Soren

I'm sorry that I've been gone for a few weeks.
Can someone point me to the discussion about Dbus running on non-Unix boxes?
This is not a "downstream" thing, of course, but must be addressed at
the top level.
Thanks, and sorry for responding late. I've been away.
bob(ishmal)

On Tue, 2009-07-14 at 21:05 -0500, Bob Jamison wrote:
> Can someone point me to the discussion about Dbus running on non-Unix boxes?
> This is not a "downstream" thing, of course, but must be addressed at
> the top level.
I'm not sure of authoritative documentation on this. But I know that
the KDE folks are trying to get the environment running on win32. I
believe these are their instructions for getting it built:
http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/Building_DBus
It seems that there is a DBus win32 project.
--Ted

On 7/14/2009 9:34 PM, Ted Gould wrote:
I was bouncing my poor ideas off of Peter (a forgiving soul, to be
sure), and
my thought on the subject would be to have a launcher app that would:
1) Sense if a Dbus framework is already running
2) If not, start a user-level dbus daemon
3) Run Inkscape, use your scripting and extensions
4) When closing Inkscape, if you started your own daemon, close it, too.
This is similar to Mozilla running on Unix. It has one executable to set up
the environment before the .bin is launched. When you quit Mozilla, they
both
close.
bob (ishmal)
> On Tue, 2009-07-14 at 21:05 -0500, Bob Jamison wrote:
>> Can someone point me to the discussion about Dbus running on non-Unix boxes?
>> This is not a "downstream" thing, of course, but must be addressed at
>> the top level.
> I'm not sure of authoritative documentation on this. But I know that
> the KDE folks are trying to get the environment running on win32. I
> believe these are their instructions for getting it built:
>
>
> http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/Building_DBus
>
> It seems that there is a DBus win32 project.
>
> --Ted
>

UPDATE: If you have checked out the branch please update. A
important file was inadvertently left out.
I'm working on a PPA to make it easier for people to try it out but
I've never done any packaging so it might take awhile for me to get it
set up.
On Tue, Jul 14, 2009 at 7:50 PM, Bob Jamison<ishmalius@...> wrote:
> On 7/14/2009 9:34 PM, Ted Gould wrote:
> I was bouncing my poor ideas off of Peter (a forgiving soul, to be
> sure), and
> my thought on the subject would be to have a launcher app that would:
>
> 1) Sense if a Dbus framework is already running
> 2) If not, start a user-level dbus daemon
> 3) Run Inkscape, use your scripting and extensions
> 4) When closing Inkscape, if you started your own daemon, close it, too.
>
> bob (ishmal)
This could be done but I don't know how often it would be used. Most
systems with DBus installed (i.e. any modern Gnome) will have a
session daemon running for each session. It could be useful for
people who install DBus just to try out this API, though, and I'd
certainly want to support those users, so I'll check it out.
Also I'll have to make sure that a user level DBus daemon could
provide the default session bus. Otherwise users would have to look
for the interface on two separate buses (The session bus, or our own
private bus if that's not running.)
>> On Tue, 2009-07-14 at 21:05 -0500, Bob Jamison wrote:
>>> Can someone point me to the discussion about Dbus running on non-Unix boxes?
>>> This is not a "downstream" thing, of course, but must be addressed at
>>> the top level.
>> I'm not sure of authoritative documentation on this. But I know that
>> the KDE folks are trying to get the environment running on win32. I
>> believe these are their instructions for getting it built:
>>
>>
>> http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/Building_DBus
>>
>> It seems that there is a DBus win32 project.
>>
>> --Ted
>>
There is a separate branch of the DBus project called winDBus,
eventually it plans to merge back into the main project and make DBus
multi-platform.
There are some independent efforts as well and some projects
(http://www.slurdge.org/deluge-on-windows) already use DBus on
windows.
I looked at the windows version of DBus when I researched my proposal
for this project. My impression was that it wasn't quite stable but
that it was being actively worked on.
My plan was to have it be Unix only at first and add windows support
when windows DBus has been hammered out a bit more. It may always
take a little effort to get DBus running on Windows, so I doubt that
this API will ever be the default on that platform, but it should work
in native Windows eventually.
The link Ted gave suggests that DBus on windows might be possible now
for people running a msvc or minGW environment.

On Thu, 2009-07-16 at 09:59 -0700, Glimmer Labs wrote:
> On Tue, Jul 14, 2009 at 7:50 PM, Bob Jamison<ishmalius@...> wrote:
> > On 7/14/2009 9:34 PM, Ted Gould wrote:
> > I was bouncing my poor ideas off of Peter (a forgiving soul, to be
> > sure), and
> > my thought on the subject would be to have a launcher app that would:
> >
> > 1) Sense if a Dbus framework is already running
> > 2) If not, start a user-level dbus daemon
> > 3) Run Inkscape, use your scripting and extensions
> > 4) When closing Inkscape, if you started your own daemon, close it, too.
>
> This could be done but I don't know how often it would be used. Most
> systems with DBus installed (i.e. any modern Gnome) will have a
> session daemon running for each session. It could be useful for
> people who install DBus just to try out this API, though, and I'd
> certainly want to support those users, so I'll check it out.
I think that he is meaning only for Windows. At least I hope so.
Please Bob correct me if I'm wrong there.
> Also I'll have to make sure that a user level DBus daemon could
> provide the default session bus. Otherwise users would have to look
> for the interface on two separate buses (The session bus, or our own
> private bus if that's not running.)
I think the only application for having a private bus is for testing.
There has been some discussion for security issues, but I think that
it's not really supported.
> My plan was to have it be Unix only at first and add windows support
> when windows DBus has been hammered out a bit more. It may always
> take a little effort to get DBus running on Windows, so I doubt that
> this API will ever be the default on that platform, but it should work
> in native Windows eventually.
I think that there's no reason though to not help people who want to get
it on Windows :) Though, we haven't made it a requirement of the GSoC
project because it was a little nebulous. I'm not sure how other
windows apps would find the DBus that's running. Probably the best
thing is to make it so that if the code can't connect to a bus, it just
silently moves on.
--Ted

On 7/18/2009 10:23 PM, Ted Gould wrote:
> I think that he is meaning only for Windows. At least I hope so.
> Please Bob correct me if I'm wrong there.
>
Well, yes and no. Of course I am thinking first of Windows and OSX, and
how they should remain first-class citizens of the Inkscape environment,
and
not poor stepchildren.
-But- it will certainly happen often where Linux people will have enough GTK
stuff to run Inkscape, but will -NOT- be running Gnome. Either a non-Gnome,
or a non-recent Gnome, environment will lack dbus. A KDE environment
may likely not have dbus running.
>> Also I'll have to make sure that a user level DBus daemon could
>> provide the default session bus. Otherwise users would have to look
>> for the interface on two separate buses (The session bus, or our own
>> private bus if that's not running.)
I would be surprised if a dbus daemon would start up correctly if
another were already
running. If a root dbus daemon is running, then of course you don't
need another one.
We only would want to run one if it's not already there. It's like if
you have an electric
generator for your home lighting in case of a storm. Normally you would
just use
the power mains.
>> My plan was to have it be Unix only at first and add windows support
>> when windows DBus has been hammered out a bit more. It may always
>> take a little effort to get DBus running on Windows, so I doubt that
>> this API will ever be the default on that platform, but it should work
>> in native Windows eventually.
>
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.
The problem doesn't really look that hard, though. We've seen worse.
Remember the codepages? :-)
bob (ishmal)

On Sun, 2009-07-19 at 01:24 -0500, Bob Jamison wrote:
> On 7/18/2009 10:23 PM, Ted Gould wrote:
> > I think that he is meaning only for Windows. At least I hope so.
> > Please Bob correct me if I'm wrong there.
> >
> Well, yes and no. Of course I am thinking first of Windows and OSX, and
> how they should remain first-class citizens of the Inkscape environment,
> and
> not poor stepchildren.
Well, yes, but, we can't expect them to be exactly the same all the
time. If nothing else, the number of developers contributing on win32
is smaller than the number contributing on win32. Just by that ratio I
would always expect win32 to lag a little bit with new features. Not a
'dis to the people doing the work; it's just a numbers game.
> -But- it will certainly happen often where Linux people will have enough GTK
> stuff to run Inkscape, but will -NOT- be running Gnome. Either a non-Gnome,
> or a non-recent Gnome, environment will lack dbus. A KDE environment
> may likely not have dbus running.
The Linux desktop today won't really run without DBus. Infact, most
distro's won't boot without DBus. It's really become a critical service
that we can count on withing the Linux Desktop.
> >> Also I'll have to make sure that a user level DBus daemon could
> >> provide the default session bus. Otherwise users would have to look
> >> for the interface on two separate buses (The session bus, or our own
> >> private bus if that's not running.)
> I would be surprised if a dbus daemon would start up correctly if
> another were already
> running. If a root dbus daemon is running, then of course you don't
> need another one.
> We only would want to run one if it's not already there. It's like if
> you have an electric
> generator for your home lighting in case of a storm. Normally you would
> just use
> the power mains.
On a typical desktop linux system there are two running. A system bus
and a session bus. But there can be as many session buses as there are
users logged in. It's also possible to have more than that. For
instance we create custom buses for our test harnesses to ensure there
isn't any interference on the bus for the tests executing.
In most cases there is very little reason to run more than on session
bus. And I think that we should check for the session bus, and if it
doesn't exist, assume the user doesn't want to use DBus.
> >> My plan was to have it be Unix only at first and add windows support
> >> when windows DBus has been hammered out a bit more. It may always
> >> take a little effort to get DBus running on Windows, so I doubt that
> >> this API will ever be the default on that platform, but it should work
> >> in native Windows eventually.
> >
> 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.
Heh, remember the Alamo! Oh, wait, probably not a good reference ;)
--Ted

-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@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

On Jul 19, 2009, at 6:38 PM, Bob Jamison <ishmalius@...> 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

Hi Soren,
excuse me , I lagged behind your work for some weeks.
Has you successfully done a PPA?
I would like to help, too.
sincerely, Mat.
Glimmer Labs 提到:
> UPDATE: If you have checked out the branch please update. A
> important file was inadvertently left out.
>
> I'm working on a PPA to make it easier for people to try it out but
> I've never done any packaging so it might take awhile for me to get it
> set up.
>
> On Tue, Jul 14, 2009 at 7:50 PM, Bob Jamison<ishmalius@...> wrote:
>
>> On 7/14/2009 9:34 PM, Ted Gould wrote:
>> I was bouncing my poor ideas off of Peter (a forgiving soul, to be
>> sure), and
>> my thought on the subject would be to have a launcher app that would:
>>
>> 1) Sense if a Dbus framework is already running
>> 2) If not, start a user-level dbus daemon
>> 3) Run Inkscape, use your scripting and extensions
>> 4) When closing Inkscape, if you started your own daemon, close it, too.
>>
>> bob (ishmal)
>>
>
> This could be done but I don't know how often it would be used. Most
> systems with DBus installed (i.e. any modern Gnome) will have a
> session daemon running for each session. It could be useful for
> people who install DBus just to try out this API, though, and I'd
> certainly want to support those users, so I'll check it out.
>
> Also I'll have to make sure that a user level DBus daemon could
> provide the default session bus. Otherwise users would have to look
> for the interface on two separate buses (The session bus, or our own
> private bus if that's not running.)
>
>
>
>>> On Tue, 2009-07-14 at 21:05 -0500, Bob Jamison wrote:
>>>
>>>> Can someone point me to the discussion about Dbus running on non-Unix boxes?
>>>> This is not a "downstream" thing, of course, but must be addressed at
>>>> the top level.
>>>>
>>> I'm not sure of authoritative documentation on this. But I know that
>>> the KDE folks are trying to get the environment running on win32. I
>>> believe these are their instructions for getting it built:
>>>
>>>
>>> http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/Building_DBus
>>>
>>> It seems that there is a DBus win32 project.
>>>
>>> --Ted
>>>
>>>
>
> There is a separate branch of the DBus project called winDBus,
> eventually it plans to merge back into the main project and make DBus
> multi-platform.
>
> There are some independent efforts as well and some projects
> (http://www.slurdge.org/deluge-on-windows) already use DBus on
> windows.
>
> I looked at the windows version of DBus when I researched my proposal
> for this project. My impression was that it wasn't quite stable but
> that it was being actively worked on.
>
> My plan was to have it be Unix only at first and add windows support
> when windows DBus has been hammered out a bit more. It may always
> take a little effort to get DBus running on Windows, so I doubt that
> this API will ever be the default on that platform, but it should work
> in native Windows eventually.
>
> The link Ted gave suggests that DBus on windows might be possible now
> for people running a msvc or minGW environment.
>
> ------------------------------------------------------------------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>

> This is exactly what I wanted to hear. Now does this behavior mandate
> that every element have an id attribute. I think Inkscape does this by
> default now. But it is not required by SVG and Jon Cruz has mentioned
> many times in the past that he would like to change our behavior. Are we
> talking id attributes or is there a unique id per element inside of
> Inkscape?
It is using the attributes.
My reasoning was that if someone is working in a scripting console
they will see all the return values and might just use them directly
if they are human readable. Plus it's a lot easier to debug when
functions return ("rect2353", "rect3454", "path3645") rather than
(0x344535, 0x387574, 0x457684). I think that's worth the performance
hit of looking up objects by their id attributes.
I wasn't aware that that wasn't part of the SVG spec. All of my
knowledge about this sort of thing comes from opening up the XML
editor and changing values to see what they do. If the id attributes
get dropped I'll have to find another way to represent objects,
hopefully one that isn't too messy.
> How do we access elements that are placed outside of the
> visible SVG body and can't take part in a selection in Inkscape?
The proposed spec has get_parent() and get_children() functions that
could be used. I left them out because I thought they might be
confusing to users who don't know about the XML tree. But if there
are things that advanced users might really need them for (like
finding unselectable nodes) then I could put them in.
> Nested transformations have been a bit of a problem in our current
> extensions because we are processing the raw XML and no one had put in
> the effort to write a tool that knows about these nested transforms. Its
> been so long since I worked with it that I don't remember exactly what
> the problems where. Are there circumstances when nested transformations
> will need to be taken into account to use your API or will it likely be
> transparent to the user because we are using Inkscape?
I just went back and tested this. In the documentation I warned about
certain operations with transformations applied but I hadn't actually
checked yet. Turns out Inkscape's sp_move_selection (Which all of my
move functions relied on, manipulating and restoring the selection if
necessary) actually fails silently if there is a transformation
applied. After some digging though I was able to find a lower-level
function that compensates for transformations (Although users will
have to be warned that it may affect the transform attribute.)
So basically the answer is, no it's not a magic bullet that
automatically solves the problem. But there are ways to deal with it,
and if I'm careful, hopefully users won't have to be.

On Jul 10, 2009, at 11:19 AM, Glimmer Labs wrote:
>> This is exactly what I wanted to hear. Now does this behavior mandate
>> that every element have an id attribute. I think Inkscape does
>> this by
>> default now. But it is not required by SVG and Jon Cruz has mentioned
>> many times in the past that he would like to change our behavior.
>> Are we
>> talking id attributes or is there a unique id per element inside of
>> Inkscape?
>
> I wasn't aware that that wasn't part of the SVG spec. All of my
> knowledge about this sort of thing comes from opening up the XML
> editor and changing values to see what they do. If the id attributes
> get dropped I'll have to find another way to represent objects,
> hopefully one that isn't too messy.
Yes, one main thing is that we need to kill id attributes except when
absolutely required. Among other things, it really clutters the XML,
and complicates things for technical users.
Another possible approach is XPath.

On Fri, 2009-07-10 at 16:07 -0700, Jon A. Cruz wrote:
> On Jul 10, 2009, at 11:19 AM, Glimmer Labs wrote:
> > > This is exactly what I wanted to hear. Now does this behavior
> > > mandate
> > >
> > > that every element have an id attribute. I think Inkscape does
> > > this by
> > >
> > > default now. But it is not required by SVG and Jon Cruz has
> > > mentioned
> > >
> > > many times in the past that he would like to change our behavior.
> > > Are we
> > >
> > > talking id attributes or is there a unique id per element inside
> > > of
> > >
> > > Inkscape?
> >
> >
> > I wasn't aware that that wasn't part of the SVG spec. All of my
> >
> > knowledge about this sort of thing comes from opening up the XML
> >
> > editor and changing values to see what they do. If the id
> > attributes
> >
> > get dropped I'll have to find another way to represent objects,
> >
> > hopefully one that isn't too messy.
>
>
> Yes, one main thing is that we need to kill id attributes except when
> absolutely required. Among other things, it really clutters the XML,
> and complicates things for technical users.
Though, we will always have a Unique ID for nodes. Whether that be a
memory address or something generated. We just need to in the API
documentation specify that it may not be the same as the ID attribute in
the XML document. There is no reason to make it more complex as the
scripting environment just needs a handle to track elements and that one
is handy right now.
--Ted

Glimmer Labs wrote:
> There is now a SVN branch for the dbus scripting work:
>
> https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/branches/gsoc2009_api
>
> The build system should do everything automatically if you have a
> reasonably recent DBus installed (Ubuntu users should already have
> this.)
I believe ubuntu users will need the libdbus-glib-1-dev package installed.
> If your Inkscape executable is not in the standard place
> (/usr/local/bin/inkscape) you might have to modify
> src/extension/dbus/org.inkscape.service.in for Inkscape to start
> automatically when requested. This will be set automatically soon,
> but for now is hardcoded.
In addition to having the installation process edit the exec path in the
service file, we should also discuss where best to place the service
file. The most usual case for having inkscape installed in a
non-standard place is to have more than one inkscape installed. I
suppose our options are: 1) to continue to add the file to
/usr/share/dbus-1/services and give alternate names. 2) add the file to
$PREFIX/share/dbus-1/services and (let the user) add a <servicedir />
directive to the dbus configuration. I suppose both options require us
to rename the service anyway. I don't know what is appropriate. (I have
similar questions with py2geom installation.) Does DBus allow for two
identically named services? Does DBus provide consumers with the ability
to enumerate and search for services, perhaps asking which inkscapes are
available?
Aaron Spike
aaron@...:~/src/inkscape_dbus$ make install
Making install in src
make[1]: Entering directory `/home/aaron/src/inkscape_dbus/src'
make install-am
make[2]: Entering directory `/home/aaron/src/inkscape_dbus/src'
make[3]: Entering directory `/home/aaron/src/inkscape_dbus/src'
test -z "/home/aaron/opt/inkscape_dbus/bin" || /bin/mkdir -p
"/home/aaron/opt/inkscape_dbus/bin"
/usr/bin/install -c 'inkscape'
'/home/aaron/opt/inkscape_dbus/bin/inkscape'
/usr/bin/install -c 'inkview' '/home/aaron/opt/inkscape_dbus/bin/inkview'
test -z ""/usr/share/dbus-1/services"" || /bin/mkdir -p
""/usr/share/dbus-1/services""
/usr/bin/install -c -m 644 'extension/dbus/org.inkscape.service'
'/usr/share/dbus-1/services/org.inkscape.service'
/usr/bin/install: cannot create regular file
`/usr/share/dbus-1/services/org.inkscape.service': Permission denied
make[3]: *** [install-serviceDATA] Error 1
make[3]: Leaving directory `/home/aaron/src/inkscape_dbus/src'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/aaron/src/inkscape_dbus/src'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/aaron/src/inkscape_dbus/src'
make: *** [install-recursive] Error 1

On Sat, 2009-07-18 at 19:40 -0500, Aaron Spike wrote:
> Glimmer Labs wrote:
> > If your Inkscape executable is not in the standard place
> > (/usr/local/bin/inkscape) you might have to modify
> > src/extension/dbus/org.inkscape.service.in for Inkscape to start
> > automatically when requested. This will be set automatically soon,
> > but for now is hardcoded.
>
> In addition to having the installation process edit the exec path in the
> service file, we should also discuss where best to place the service
> file. The most usual case for having inkscape installed in a
> non-standard place is to have more than one inkscape installed. I
> suppose our options are: 1) to continue to add the file to
> /usr/share/dbus-1/services and give alternate names. 2) add the file to
> $PREFIX/share/dbus-1/services and (let the user) add a <servicedir />
> directive to the dbus configuration. I suppose both options require us
> to rename the service anyway. I don't know what is appropriate. (I have
> similar questions with py2geom installation.) Does DBus allow for two
> identically named services? Does DBus provide consumers with the ability
> to enumerate and search for services, perhaps asking which inkscapes are
> available?
I believe that DBus activation only allows for one service of each name.
Making additional names isn't that difficult though, we could definitely
make that part of the build. What I did with the inkscape-devel nightly
package when that was running is that I changed all the names for the
icons and everything to be a different name. That was nice, but kinda a
pain.
Though, I'm not sure how many developers will be using DBus activation
actively. Honestly, it's kinda a trick feature that's nice to enable,
but I'm not sure of any use cases right now.
--Ted