Hi,
I have to produce a "plugin" for Inkscape. Python extension functionnalities are not enough for what I want to do so I came to try the DBus Api.
With this one, I can communicate from my plugin to Inkscape but not in the other way. The only implemented signal is "ObjectMoved" but I need to know when Inkscape modifies a node, adds an attribute or things like that.
I look after the dbus extension code and it seems that the signals that I want are described in proposed-interface.xml and are not yet implemented.
Is there any way to achieve what I want to do? Is there further development forecast for dbus extension? Is this possible to propose eventually patch?
Thanks for the reply
On Mon, 2013-04-29 at 18:46 +0200, cabieces julien wrote:
Is there any way to achieve what I want to do? Is there further development forecast for dbus extension? Is this possible to propose eventually patch?
Looking at the move signal code and various comments. It's clear the signals work was not completed. What we have it seems is a test rather than a hack which punts the dbus call from select-conect.cpp to a dbus signal
This is called 'dbus_send_ping' and not 'dbus_object_moved' which would be I think typical of a permanent feature.
Signals are also commented in the proposed interface as not existing and the document interface xml doesn't even mention the single signal we do appear to have.
Over all I think the dbus signal work would need to be picked up and completed properly. At least there's a good starting point for anyone who wants to get involved.
Best Regards, Martin Owens
2013/4/29 Martin Owens <doctormo@...400...>:
Over all I think the dbus signal work would need to be picked up and completed properly. At least there's a good starting point for anyone who wants to get involved.
I was thinking about this recently and I think the best way to provide the relevant functionality is to simply embed a Python interpreter in Inkscape and provide bindings through Boost.Python, Swig, or some other method. In keeping with the 'worse is better' philosphy, this approach has a chance to actually end up being usefully implemented in a reasonable amount of time.
The only desirable feature of the DBus-based solution is that you can in principle use any language to implement an extension that uses the DBus API. At the same time it has many disadvantages: poor compatibility with Windows, poor prospects for future cross-platform compatibility (there are plans to move DBus into the kernel), higher implementation complexity and much higher overhead. Even allowing arbitrary languages is not a clear-cut advantage: if someone wrote a great extension in a language that no-one on the core team knows and proposed it for inclusion into Inkscape, we would have a choice between rejecting useful functionality and alienating a potential contributor or accepting something we can't maintain.
Just my 2 cents, not looking to start a holy war.
Regards, Krzysztof
Even allowing arbitrary languages is not a clear-cut advantage
I tend to agree, I think one of the primary functions of the extension system that Inkscape has is not so much its functionality as the fact that it is an excellent teaching tool for those timid souls that want to get involved incrementally without necessarily jumping in at the deep end. I would vote for anything that increases the functionality of the Python interface.
my 2 cents, Alvin Penner
-- View this message in context: http://inkscape.13.x6.nabble.com/DBus-api-signals-tp4966764p4966771.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
FWIW - I'd love either of these but the Python wrapping would be my choice. Despite losing some language generalisation, I'd be able to get access to a lot more functions. E.g. I have a jigsaw plugin that creates the lines but I can't do the boolean ops to make each piece separate. So its fine for a lasercutter but not for moveable jigsaw pieces.
How about hinting to GSOC applicants...?
My 2 cents...
On 4/30/2013 8:15 AM, alvinpenner wrote:
Even allowing arbitrary languages is not a clear-cut advantage
I tend to agree, I think one of the primary functions of the extension system that Inkscape has is not so much its functionality as the fact that it is an excellent teaching tool for those timid souls that want to get involved incrementally without necessarily jumping in at the deep end. I would vote for anything that increases the functionality of the Python interface.
my 2 cents, Alvin Penner
-- View this message in context: http://inkscape.13.x6.nabble.com/DBus-api-signals-tp4966764p4966771.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
For python 2.7 reference is here: http://docs.python.org/2/extending/embedding.html For Python 3.3 reference is here: http://docs.python.org/3/extending/embedding.html
If someone wants to embed python and create template to expose C functions. Then I am happy to do a lot of the legwork of copying and creating the many many functions we might want to expose.
Mark...
On 4/30/2013 8:38 AM, Mark Schafer wrote:
FWIW - I'd love either of these but the Python wrapping would be my choice. Despite losing some language generalisation, I'd be able to get access to a lot more functions. E.g. I have a jigsaw plugin that creates the lines but I can't do the boolean ops to make each piece separate. So its fine for a lasercutter but not for moveable jigsaw pieces.
How about hinting to GSOC applicants...?
My 2 cents...
On 4/30/2013 8:15 AM, alvinpenner wrote:
Even allowing arbitrary languages is not a clear-cut advantage
I tend to agree, I think one of the primary functions of the extension system that Inkscape has is not so much its functionality as the fact that it is an excellent teaching tool for those timid souls that want to get involved incrementally without necessarily jumping in at the deep end. I would vote for anything that increases the functionality of the Python interface.
my 2 cents, Alvin Penner
-- View this message in context: http://inkscape.13.x6.nabble.com/DBus-api-signals-tp4966764p4966771.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2013-04-29 at 19:54 +0000, Krzysztof Kosiński wrote:
I think the best way to provide the relevant functionality is to
simply embed a Python interpreter
Thanks for the great response Krzysztof, Are the GObject structures incapable of supporting gir? I know it gets tricky sometimes but that could be an interesting GSoC too.
Martin,
So, for sum up, dbus api is not really mature and maybe not appropiate for what I want to do.
Developing plugin with python will be great, but I have a few questions : - Would it be possible to add some specific GUI integrated inside inkscape? - When it would be available? I guess it's quite a hard work
Is it possible to simply develop C++/Gtk plugin inside inkscape?
Thank you for all you answers.
2013/4/30 Martin Owens <doctormo@...400...>
On Mon, 2013-04-29 at 19:54 +0000, Krzysztof Kosiński wrote:
I think the best way to provide the relevant functionality is to
simply embed a Python interpreter
Thanks for the great response Krzysztof, Are the GObject structures incapable of supporting gir? I know it gets tricky sometimes but that could be an interesting GSoC too.
Martin,
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2013-04-30 at 16:23 +0200, cabieces julien wrote:
Is it possible to simply develop C++/Gtk plugin inside inkscape?
Those are src/extension, see the extensions directory. Not sure how they're loaded and if they end up being separate when built. But certainly enough examples to get you going if you know C++.
Martin,
2013/4/30 cabieces julien <cabieces.julien@...400...>:
So, for sum up, dbus api is not really mature and maybe not appropiate for what I want to do.
Developing plugin with python will be great, but I have a few questions :
- Would it be possible to add some specific GUI integrated inside inkscape?
- When it would be available? I guess it's quite a hard work
Adding the Python API would be a long-term project, but in principle every aspect of Inkscape could be accessed with it.
Is it possible to simply develop C++/Gtk plugin inside inkscape?
You can develop a 'plugin' in C++ (subclass one of the extension classes and register it at program start), but it would have to be compiled into Inkscape. At the moment there is no support for the dynamic loading of plugins.
Regards, Krzysztof
participants (5)
-
alvinpenner -
cabieces julien -
Krzysztof Kosiński -
Mark Schafer -
Martin Owens